CC Switch Providers Explained

I paused here the first time a team called provider switching “just changing a dropdown.” That is not what CC Switch providers are doing, at least not once Claude Code, Codex, OAuth, gateways, and local models enter the same workspace.

The short version: a provider is not only a model name. It is a routing decision, an auth path, a protocol shape, a logging surface, and a rollback problem. This piece is for teams already using coding agents and trying to avoid turning model freedom into quiet infrastructure debt.

What CC Switch Means by Provider

In CC Switch, a provider is a saved configuration for one upstream route. It can point to an official API, a cloud platform, an OpenAI-compatible gateway, a relay, an OAuth-backed account, or a local endpoint. The CC Switch Add Provider manual separates app-specific providers from universal providers, which matters because Claude Code, Codex, Gemini, OpenCode, OpenClaw, Hermes, Claude Desktop, and now Grok Build do not all read configuration the same way.

As of the v3.18.0 release notes, Grok Build became the eighth managed app, and the release also repeated the warning about unofficial sites, reverse proxy risk, and third-party routing responsibility. That tells me where the mature reading starts: provider switching is operational control, not decoration.

Provider manager, local routing, model mapping, and supported apps

The provider manager stores the endpoint, API key or auth mode, model IDs, notes, and app target. Direct mode writes or restores the target app’s native configuration. Local routing puts CC Switch in the middle, usually through a local proxy address, then forwards the request to the selected upstream.

Model mapping is the part people underestimate. Claude-side tools may expose Sonnet, Opus, and Haiku roles, while the real upstream model might be GPT, Kimi, DeepSeek, Grok, or a local model. Codex has its own shape: config files, model providers, wire_api, and a strong preference for Responses-style behavior. A Codex provider is not the same object as a Claude provider with a different label.

Why provider labels can hide different upstream architectures

“OpenAI-compatible” is a useful phrase. It is not a guarantee. One endpoint may support /v1/responses; another only supports Chat Completions; another may claim compatibility but break on tools, streaming, image inputs, or reasoning fields.

This is where labels hide architecture. “GPT” can mean OpenAI’s hosted API, Azure OpenAI, Amazon Bedrock with separate platform controls, a gateway reselling access, or a ChatGPT OAuth-backed path. OpenAI’s own note on Responses API support on Amazon Bedrock is a good reminder: compatible shape does not mean the same operator, region, quota, or support owner.

Provider Types to Compare

I compare CC Switch providers by ownership first. Model name comes second. Boring. Also the only way this stays sane.

Official APIs, cloud platforms, gateways, relays, OAuth, and local models

Official APIs are the cleanest line. Anthropic API and OpenAI API routes have first-party docs, first-party billing, and clearer support ownership. Claude Code also documents environment variables like ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN in its official env var reference, including behavior changes when routing through non-first-party hosts.

Cloud platforms are not just official APIs with another logo. Azure, Bedrock, and Vertex-style routes move access, IAM, region, quota, and audit controls into the cloud provider’s account boundary.

Gateways and relays sit between your tool and the model source. An AI model gateway can be useful for cost control, failover, or model variety. It also creates another place where prompts, code context, metadata, and errors may be visible.

OAuth routes are their own category. CC Switch supports paths like Codex OAuth reverse proxy and newer xAI OAuth flows. These are convenient when they work. They also carry account, terms, and availability risk. The v3.18.0 notes say that plainly. Good. Better than pretending.

Local models are different again. The Ollama Codex integration docs show how Codex can work with local or cloud Ollama profiles. Local model routing reduces some external data exposure, but it does not magically preserve Claude or GPT behavior. Context length, tool calls, latency, and model quality still need testing.

Stability, cost, compatibility, and data-risk differences

Provider type	Stability question	Cost question	Compatibility question	Data-risk question
Official API	Is the vendor API healthy?	Are token prices and cache rules understood?	Does the app support the native protocol?	What does the first-party retention policy say?
Cloud platform	Is the region and quota ready?	Are cloud markups or commitments involved?	Does the platform expose the same features?	Who is processor: model vendor or cloud provider?
Gateway / relay	Can it fail closed?	Is billing based on real upstream model use?	Does it preserve tools, streaming, and reasoning fields?	What does the gateway log or store?
OAuth route	Will auth keep working?	Does it consume subscription quota?	Is the flow reverse engineered or officially supported?	What account risk exists?
Local model	Can the workstation handle it?	What is hardware cost?	Does the local model support coding-agent patterns?	What still leaves the machine?

Good enough. That is the most honest assessment I can give.

What Changes When You Switch Providers

A switch can change more than latency. It can change the behavior of the whole coding session.

Context cache, model IDs, tool behavior, rate limits, and logging

Prompt cache is the first quiet change. Claude Code’s prompt caching docs explain why a model switch can trigger a slower uncached turn. Different upstreams also account for cached tokens differently. CC Switch release notes keep mentioning cache token fixes for a reason. The numbers are easy to get wrong.

Model IDs are the second change. Claude roles, Codex model catalogs, OpenAI model IDs, and gateway aliases can all point at different real models. Seeing “Sonnet” in a menu does not prove the upstream is Anthropic. It may only be the role label that passed client validation.

Tool behavior changes too. A Claude Code provider routed through a non-first-party base URL may lose tool-search behavior unless the proxy supports the right blocks and the right environment flags. Codex tools have their own mapping issues when Chat Completions upstreams are converted back into Responses shape.

Rate limits move with the upstream. Official API limits, subscription windows, gateway quotas, local GPU limits, and cloud account quotas are not interchangeable. Logging also changes. CC Switch can add local usage visibility, but that does not replace upstream audit, retention, or vendor log review. Anthropic’s API data retention docs are the kind of source I want attached to a review packet, not remembered from a Slack thread.

Claude Code, Codex, and OpenAI-compatible routing boundaries

Claude Code speaks Anthropic-shaped configuration. Codex speaks OpenAI/Codex-shaped configuration. OpenAI-compatible routing sits between those worlds, but it does not erase the boundary.

If someone says “CC Switch API,” make them define the thing. Do they mean the local routing service, a configured upstream endpoint, or a third-party service using the same naming pattern? I’ve seen teams mix those up. So that’s where the bottleneck was.

OpenAI’s current model docs say current models are available through the Responses API. That matters because a provider that only exposes Chat Completions may need CC Switch conversion before Codex can use it cleanly. Conversion is useful. It is still conversion.

Production Checklist

Verify docs, model list, endpoint format, auth path, and rollback route

Before approving a provider for team work, I would keep this checklist short and dull:

Confirm the official CC Switch release and source. Use ccswitch.io, the GitHub repo, and GitHub Releases, not a paid site asking for credentials.
Capture the provider category: official API, cloud platform, gateway, relay, OAuth, or local.
Verify the model list from the app or the provider endpoint. If /v1/models fails, record the manual model ID source.
Record the endpoint format: Anthropic Messages, OpenAI Chat Completions, OpenAI Responses, Gemini native, or custom full URL.
Record auth ownership: API key, OAuth account, cloud IAM, subscription account, or local-only endpoint.
Test tools, streaming, long context, cache accounting, and failure behavior with a non-sensitive repo.
Export or back up the current CC Switch database before team rollout.
Test rollback: disable routing, restore official provider, restart the target CLI, and confirm the old path works.

One fewer switch. Sounds small. Adds up fast. One undocumented switch, though, can cost a day.

FAQ

Who approves new CC Switch providers for team use?

For a team, approval belongs with the owner of developer tooling plus security or data governance. If source code, customer data, production logs, or private tickets may enter prompts, a single developer’s working config is not enough evidence. The approval record needs an owner, a scope, and an expiry date.

What evidence should be kept for provider risk review?

Keep the provider docs URL, release date checked, endpoint URL, protocol format, model IDs, auth path, pricing or quota basis, data retention statement, logging behavior, test result, and rollback result. For gateways, also keep the stated upstream ownership. If the gateway will not say where the model traffic goes, mark that gap directly.

How should support handle unclear upstream provider ownership?

Support should treat it as unapproved for sensitive work. Ask for the chain: account owner, upstream model operator, cloud region, data retention, support path, and billing source. If the answer is “it just works,” stop there. That is not an ownership model. That is a shrug in API form.

Conclusion

CC Switch providers are useful because they make routing visible and switchable across coding tools. That same convenience is why teams need rules. A provider switch can change cache behavior, model identity, tool support, rate limits, logs, account risk, and data ownership in one click.

I still like the model freedom. I just do not treat it as free.

Previous posts: