CC Switch Provider switching solves a practical problem: when one computer uses official services, third-party APIs, and local models, manually changing several client configurations is easy to get wrong. Start with one working Provider, then add local interfaces and backup paths gradually.
Establish a single Provider first
In CC Switch, select the target tool such as Claude Code or Codex, add one Provider, and configure only one Base URL, API key, and model. Save it, fully restart the terminal and client, and make one simple request to confirm the response comes from the new Provider.
Do not enable proxies, sync, several aliases, and fallback at the same time before this succeeds. Too many variables make diagnosis meaningless.
Connect a local OpenAI-compatible API
Whether Ollama, LM Studio, vLLM, and similar services can connect depends on whether they expose an interface compatible with your client and whether the Provider configuration supports a custom Base URL and model name. Check:
- The service listens on an address the current computer can reach.
- The model name matches the name actually exposed by the service.
- The local service needs a key or accepts only local requests.
- Context, concurrency, and VRAM are sufficient for real work.
For choosing and connecting a local API, see using local model APIs with Codex; for LM Studio details, see LM Studio’s OpenAI-compatible API.
Practical multi-Provider strategy
- Daily coding: prioritize a stable Provider with predictable cost.
- Long tasks or important review: manually switch to a stronger model instead of relying on hidden automatic replacement.
- Local models: use them for privacy-sensitive, offline, or low-risk fixed steps.
- Failures: check Provider health and quota before switching; do not keep retrying and consuming limits.
If several upstream priorities and fallback rules should be exposed through one endpoint, combine CC Switch with 9Router: CC Switch manages clients, while 9Router manages request routing.
Summary
The key is not how many addresses you can enter, but whether every switch can be verified. Keep one configuration verifiable, restart clients, match model names, and only then expand to local models and multiple Providers.
What a Provider entry should contain
Give every Provider a clear entry with its purpose, endpoint, model naming rule, authentication method, and verification date. Names such as “backup” or “new API” are not enough; weeks later you will not know whether it supports code review, tool calls, or still has quota.
| Field | Purpose |
|---|---|
| Display name | Distinguish official, team, local, and test Providers |
| Base URL | Record the root address of the compatible API |
| Model name | Prevent confusion between client aliases and service names |
| Key source | Record only location or account, not a repository secret |
| Intended work | Daily development, long tasks, offline testing, and so on |
What to validate before and after a switch
Before switching, record the current Provider and model, and keep a test task that does not modify files. Afterwards, verify that output comes from the expected model, tool calls still work, project permissions remain correct, and failures show a clear error. If the new Provider is incompatible, you can immediately return to a known-good setup.
For local OpenAI-compatible services, confirm the listen address as well as the Base URL. If it is only for the same machine, bind to a loopback address where possible instead of exposing it to the LAN. Consider authentication and firewall policy separately before granting other devices access.
Model-name and capability mismatch risks
API compatibility does not mean equal capabilities. A service may accept chat requests but not support tool calls, images, long contexts, or the streaming behavior required by a client. Test the target workflow; do not move all work merely because a service says “OpenAI compatible.”
When output becomes unusually short, tool-call format fails, or context overflows quickly, check model capability, service version, and context limit instead of only changing the key. For local vLLM memory and KV-cache issues, see vLLM KV Cache troubleshooting.
Cost and observability
Provider switching also needs a cost boundary. Record which Provider each task class uses by default, whether failures retry automatically, and how long call logs are kept. For local models, include runtime, power use, and human maintenance when making decisions; comparing API price alone is incomplete.
FAQ: Why is the old model still used after switching?
Common causes are an old terminal that remains open, a project environment variable override, an unchanged model alias, or a cached session. Start a new session, restart the client, and check request logs.
FAQ: Can I import every API key?
Import only accounts you need and trust. Management tools and sync folders are valuable targets; verify encryption, access control, and revocation before enabling synchronization.