CC-Switch 里已经有 LiteLLM再加一条 TaoToken 通道行不行行。打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 Key回到 CC-Switch 的 Provider 管理里新增一个 OpenAI 兼容 ProviderBase URL 填 https://taotoken.net/apiAPI Key 填刚建的那把保存即可。原来的 LiteLLM Provider、litellm_config.yaml、master_key 全部保持原样一个字符都不用改。这个问题的来源很具体Provider 列表里躺着一条http://your-server:4000/v1Claude Code 走它Codex 也走它Gemini CLI 还在用它但你想加一个新来源的时候第一反应是「是不是得回去动 LiteLLM 的 yaml」。其实不用。CC-Switch 的 Provider 列表本来就是个多条目容器它管的是「哪个 CLI 工具当前指向哪条配置」多一条少一条互不干扰。你要做的只是把新通道当成列表里的第二个条目插进去然后决定哪个工具在什么场景下切过去。这篇不重复装 CC-Switch 的步骤也不重复部署 LiteLLM 的三条命令。假设你手上已经有一套能跑的 LiteLLM现在只解决一件事怎么让两条通道在一台机器上和平共处。1. 先搞清楚 LiteLLM 那条 Provider 到底管了什么1.1 master_key 和后端 Key 是两层东西很多人对 LiteLLM Provider 的字段有误解以为 CC-Switch 里填的那个 master_key 就是模型供应商的真 Key。不是。LiteLLM 的结构是两层后端各家厂商的真 Key 写在litellm_config.yaml的api_key字段里LiteLLM 代理自己对外只认一个 master_key用来验证「你是不是有权调用这个代理」。CC-Switch 里填的 Base URL 加 master_key对接的是 LiteLLM 这一层跟 DeepSeek、千问的真实 Key 完全隔开。理解这一点你就能明白为什么加一条新通道不会打扰 LiteLLM。新通道是 CC-Switch 直接连到上游不经过 LiteLLM 的转发逻辑也不进 LiteLLM 的计费账本。两条路径在 CC-Switch 的 Provider 列表里是平级的兄弟不是父子。提示只要你不去改litellm_config.yaml的model_list也不去重启 LiteLLM 进程原有链路的状态就完全不变。加 Provider 这个动作本身不会触发任何重载。1.2 两条通道并存意味着两套「模型名」这里有个容易踩的点LiteLLM 里model_name是你在 yaml 里自己起的别名比如把deepseek/deepseek-chat起名叫deepseek-v4-pro调用时写的是别名。而新加的这条通道模型 ID 由通道那边的模型广场决定跟 LiteLLM 里的别名毫无关系。同一台机器上出现两套模型命名体系本身没问题但你在 CC-Switch 里切换 Provider 的时候必须连带把模型名也切过去否则会出现「Provider 换了、模型名还是旧别名」的 404。所以真正要做的准备不是改配置而是先把两边的名字对清楚LiteLLM 侧有哪些别名、新通道侧有哪些可用 ID各自记一份。这件事做完后面所有步骤都会顺很多。2. 在 CC-Switch 的 Provider 管理里插入新条目2.1 先去官网把 Key 建出来打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册或登录之后进控制台创建一把新的 API Key。这一步建议单独建一把专用 Key不要和别的工具复用同一把原因是将来要按工具对账、要单独吊销的时候独立的 Key 会省掉很多排查时间。Key 只在创建时完整显示一次复制完先存进密码管理器别留在聊天窗口里。注意本文所有示例里的 Key 都写成YOUR_API_KEY占位符你实际填的时候替换成自己那把。任何把真 Key 贴进公开文档、贴进代码仓库、贴进截图的做法都等于把额度公开送人。拿到 Key 之后先别急着回 CC-Switch顺手在同一个站点的模型广场看一眼当前有哪些可用的模型 ID。这一步花不了两分钟但能省掉后面一次 404 排查。模型列表会随时间调整以页面当时显示为准不要照抄别人半年前博客里的名字。2.2 四个字段照着填回到 CC-Switch进入 Provider 管理新增一条OpenAI 兼容类型的 Provider。这类表单通常就是四个输入框填法如下字段填什么说明Provider 名称taotoken或TaoToken-直连自己看得懂就行别和 LiteLLM 重名Base URLhttps://taotoken.net/api末尾不要加/v1API KeyYOUR_API_KEY从 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建的那把模型 IDYOUR_MODEL_ID以官网模型广场当时列表为准Base URL 这一栏是最容易填错的地方。CC-Switch 里已有的 LiteLLM Provider 是带/v1结尾的所以很多人下意识也在新通道后面补一个/v1。不要补。协议段和路径段的拼接方式由客户端处理你只填到https://taotoken.net/api这一层剩下的事情交给工具。两栏长得不一样不是笔误是两条通道的规则本来就不同。2.3 命名和排序别让两条通道长得一样Provider 名字看起来是小事实际上是最常见的事故源。如果你把新条目也叫litellm或者也叫default在 Claude Code 和 Codex 之间来回切的时候很难一眼看出当前生效的是哪条。建议名字里带上来源标识比如local-litellm和taotoken一眼可分。列表顺序也顺手理一下。把日常高频用的那条放前面把备用通道放后面切换时点错按钮的概率会明显下降。CC-Switch 的 Provider 列表是本地状态这些调整不会同步到任何服务端纯属给自己减少视觉负担。3. 切换时 CC-Switch 到底改了哪个文件3.1 Claude Code~/.claude/settings.json的 env 段CC-Switch 对 Claude Code 的作用方式是在你切换 Provider 的那一刻把对应的环境变量写进 Claude Code 的配置里。落点是~/.claude/settings.json的env节点三个关键字段是ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODEL。切到新通道之后这个文件长这样{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: YOUR_API_KEY, ANTHROPIC_MODEL: YOUR_MODEL_ID } }ANTHROPIC_MODEL的值请对照官网模型广场当时列表填别写死了某天看到的旧名字。这份文件的作用域是当前用户改完全局生效但它只影响 Claude Code不会影响 Codex。3.2 Codex~/.codex/config.toml的 provider 段Codex 走的是 TOML字段结构和 Claude Code 完全不同。不要把ANTHROPIC_*那几个变量套到 Codex 上它根本不读。Codex 需要的是model_provider指向一个自定义 provider 块块里给出base_url和一个环境变量名model YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEYenv_key这一行只是声明「从哪个环境变量读 Key」你还需要在 shell 里导出同名变量或者让 CC-Switch 帮你写好。两份文件的结构差异是切换 Provider 之后最该确认的地方——很多人切完发现 Codex 报错回头一看是 CC-Switch 只改了 Claude Code 那份。3.3 两条通道并存时的状态配完之后你的机器上会有两套并行状态LiteLLM 那条通道对应一组旧值新通道对应上面这两份写法。CC-Switch 的价值就在这里——它不合并、不覆盖只负责把其中一套推给目标工具。你切回 LiteLLM 时这些文件会被改回旧值~/.claude/settings.json里的 Base URL 重新变成http://your-server:4000/v1。提示手改过这两个文件之后尽量不要再让 CC-Switch 去「切换」同一个工具否则你的手改内容会被它按 Provider 定义覆盖掉。要么完全交给 CC-Switch 管要么完全手管混着来最容易出玄学问题。4. 配完先打一发最小请求别急着写业务4.1 先用模型对话页确认 Key 是活的在 CC-Switch 里切到新通道之后不要马上打开 Claude Code 让它改代码。先用同一把 Key 去 TaoToken 模型对话 页面发一条最简单的消息比如「回复 pong」。这一步验证的是 Key 本身有没有建对、模型 ID 在不在可用列表里。如果这一步就失败问题 100% 在 Key 或模型名跟 CC-Switch 没关系排查范围立刻缩小一半。4.2 手写 curl 再验一次路径拼接模型对话页通了之后再用命令行打一次确认 Base URL 的拼接方式跟你以为的一致curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d {model:YOUR_MODEL_ID,messages:[{role:user,content:ping}]}这里要区分两件事配置表单里的 Base URL 只填到https://taotoken.net/api末尾不带/v1但手写 curl 的时候/v1/chat/completions这一段是接口路径的一部分要自己接上。工具替你拼和你自己拼是两种场景别把 curl 里的完整地址原样抄回表单那会拼出双份/v1。4.3 什么算通过返回体里有正常的choices数组、content字段非空就算这条通道活了。如果返回的是一段 HTML、一个网关错误页或者干脆超时说明请求根本没落到接口层优先怀疑地址写错而不是 Key 写错。5. 两条通道打架时的排障对照5.1 401先查空格和引号从网页复制 Key 的时候很容易在末尾多带一个空格或者换行。这种 Key 肉眼看起来完全正常但服务端校验必然失败返回 401。处理方式是把 Key 重新粘到纯文本编辑器里把首尾不可见字符清掉再填一次。另一种 401 来源于环境变量没生效。Codex 的env_key声明的变量名如果拼错一个字母或者根本没导出程序读到的就是空字符串表现同样像 Key 无效。这种情况下先echo一下变量确认它真有值。5.2 404 与模型 ID名字必须是当前存在的404 在两条通道并存的环境里格外常见因为模型名容易混。排查顺序是确认当前 CC-Switch 激活的是哪条 Provider再去官网模型广场看这个 ID 是否还在列表里。LiteLLM 里你自定义的别名在新通道上不可能存在反过来也一样。提示每次切换 Provider 之后顺手看一眼模型 ID 有没有跟着切是省时间而不是浪费时间。这一步三秒钟能挡掉大部分「配置没错但不通」的困惑。5.3 切回 LiteLLM 没反应重启 CLI 会话CC-Switch 改的是配置文件但已经开着的终端会话不会自动重读环境变量。你切回去之后发现行为没变不是配置没写进去而是那个进程还在用启动时读到的旧值。关掉终端重开或者在新窗口里跑问题通常就消失了。Codex 和 Claude Code 都是长驻进程这个现象更明显。6. 什么活儿走 LiteLLM什么活儿走新通道6.1 三条判断标准第一条看是否需要统一计费和限流。LiteLLM 的强项是细粒度 token 计费和 rate limit需要按项目拆分成本的时候它仍然是主入口。第二条看是否要跨机器共享。你有一台常驻服务器在跑 LiteLLM多台设备都指向它这个结构很稳不必拆。第三条看是否只想在单机上快速多一个来源。只是本地开发机想多一个可选后端加一条直连 Provider 最省事不需要为它再维护一份代理配置。6.2 推荐的并存分工比较顺手的分法是这样长期跑、需要账本和限流的任务继续走 LiteLLM临时对比、快速试验、或者 LiteLLM 那台机器暂时不可达的时候切到新通道顶一下。这样两条通道各管一段场景谁也不是谁的备份负担CC-Switch 的 Provider 列表就成了一个真正的场景选择器而不是一份重复配置的堆积。7. 收尾把 Key 和用量放回同一个地方看7.1 对完账再决定要不要长期留着配置生效之后跑几条真实请求然后回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的控制台看调用记录有没有正常记上。这一步很重要如果请求通了但账目里查不到说明你请求的路径和账号没对上往后排查会更麻烦。确认记录正常之后再决定这条通道是长期保留还是只用于临时对比。7.2 下一步入口要长期用来写代码可以先看 Coding Plan 的额度是否覆盖你的日常量需要再加一把给别的工具用的 Key直接在 控制台 API Keys 里建Claude Code 那几个环境变量跟 CC-Switch 的对应关系Claude Code 接入文档 里有逐项对照比对着看一遍下次切通道就不会再纠结该改哪份文件了。