CC Switch 的 Provider 切换适合解决一个现实问题：同一台电脑上同时使用官方服务、第三方 API 和本地模型时，手动修改多个客户端配置很容易遗漏。正确的流程是先跑通一个 Provider，再逐步增加本地接口和备用方案。
先建立单一 Provider
在 CC Switch 中选择目标工具，例如 Claude Code 或 Codex，添加一个 Provider 后只配置一组 Base URL、API key 和模型。保存后完全重启终端与客户端，发起一次简单任务确认它确实从新 Provider 返回。
这一步成功之前，不要同时开启代理、同步、多个模型别名和 fallback；变量太多会使排错失去方向。
接入本地 OpenAI-compatible API
Ollama、LM Studio、vLLM 等服务能否接入，取决于它们是否提供与你的客户端兼容的接口，以及 Provider 配置是否允许自定义 Base URL 和模型名。检查时要关注：
- 服务是否监听在当前电脑可访问的地址；
- 模型名是否与服务实际暴露的名称一致；
- 本地服务是否要求 key，或仅接受本机请求；
- 上下文、并发和显存是否足够支撑真实任务。
本地 API 的选择与接入可结合 本地大模型 API 给 Codex 使用教程；LM Studio 的接口细节可看 LM Studio OpenAI 兼容接口。
多 Provider 切换的实用策略
- 日常编码：优先稳定、成本可预期的 Provider。
- 长任务或关键审查：手动切换到更强的模型，不依赖隐式自动替换。
- 本地模型：用于隐私敏感、离线或低风险的固定步骤。
- 故障时：先看 Provider 健康状态和配额，再切换，不要连续重试消耗额度。
若需要把多个上游的优先级和 fallback 统一到一个 endpoint，可把 CC Switch 与 9Router组合使用：CC Switch 管理客户端，9Router 管理请求路由。
总结
Provider 切换的关键不是“能填多少地址”，而是每次切换都能确认生效。保持单一可验证配置、重启客户端、核对模型名，再扩展到本地模型和多 Provider，最不容易出错。
Provider 条目应该包含什么
为每一个 Provider 建立清晰条目，至少标明用途、endpoint、模型名称规则、认证方式和验证日期。不要只用“备用”“新 API”这样的名称；几周后你无法判断它是否适合代码审查、是否支持工具调用，或是否仍有额度。
| 字段 | 作用 |
|---|---|
| 显示名称 | 区分官方、团队、本地与测试 Provider |
| Base URL | 记录兼容接口的根地址 |
| 模型名 | 避免客户端别名与服务端名称混淆 |
| 密钥来源 | 仅记录存放位置或账号，不写入仓库 |
| 适用任务 | 日常开发、长任务、离线测试等 |
切换前后都要验证什么
切换前记录当前 Provider 和模型，并保存一条不会修改文件的测试任务。切换后检查：返回内容是否来自预期模型、工具调用是否仍可用、项目目录是否仍有正确权限、请求失败时是否能读到清楚错误。这样当新 Provider 不兼容时，可以立即回到已知正常配置。
对于本地 OpenAI-compatible 服务，除 Base URL 外还要确认它监听的网络地址。只想在本机使用时，应优先绑定本机回环地址，避免无意暴露给局域网；需要其他设备访问时，再单独考虑认证和防火墙。
模型名和能力不匹配的风险
接口兼容不代表能力完全相同。有的服务能接受聊天请求，却不支持工具调用、图像、长上下文或客户端所需的流式返回。先用目标工作流测试，而不是看到“OpenAI compatible”就把所有任务迁过去。
当模型输出变得异常短、工具调用格式错误或上下文很快溢出时，检查模型能力、服务版本和上下文上限；不要只更换 API key。若本地推理出现显存或 KV cache 问题，可结合 vLLM KV Cache 内存排查处理。
费用与可观测性
Provider 切换也应保留成本边界。记录每类任务默认使用哪个 Provider、失败是否自动重试、以及调用日志保留多久。对本地模型，应把运行时间、功耗和人工维护也算进决策；这比只比较 API 单价更接近真实成本。
FAQ：Provider 切换后为什么还是旧模型？
常见原因是旧终端尚未退出、项目级环境变量覆盖、模型别名未更新，或客户端缓存了会话。建立新会话、重启客户端并查看请求日志，通常能定位。
FAQ：能把所有 API key 都导入吗？
只导入实际需要且你信任的账户。管理工具和同步目录都是高价值目标；开启同步前先确认加密、访问权限和撤销方法。