1. 为什么 codex 里接第三方模型总差点意思
如果你最近在折腾 codex 的本地多模型切换，大概率会遇到一个很别扭的局面：DeepSeek、Kimi、GLM 这些模型的 API Key 填进去，模型确实能跑，但 codex 官方 App 的插件面板和手机远程控制突然就没了。原因不复杂，codex 的登录态和模型通道被写进了同一个地方，切换第三方供应商时把官方登录缓存覆盖掉了。
CC Switch 3.16.1 这次更新主要就是解决这个割裂感。它把 codex 的配置拆成两个文件来管理：~/.codex/auth.json保留官方 ChatGPT / Codex 登录缓存，~/.codex/config.toml负责当前供应商、base URL、模型和 provider-scoped token。开启“切换第三方时保留官方登录”之后，第三方 API Key 只写进 config.toml 的当前 provider 下，auth.json 不动，于是插件和手机控制还能继续用，模型请求则走第三方通道。
这篇面向需要在本地统一管理多模型通道的开发者，给出 CC Switch 3.16.1 在 codex 中接入 DeepSeek、Kimi、GLM 的 settings.json 骨架、TaoToken 统一 Key/API 通道的接入位置，以及插件与手机控制的验证动作。如果你只想快速跑通一条链路，也可以直接照着下面的配置复制。
2. TaoToken 前置：统一 Key 与 API 通道的接入位置
在讲 settings.json 骨架之前，先把 TaoToken 的接入位置说清楚。TaoToken 在这里扮演的是统一 Key 和 API 通道的角色，你可以把它理解成一个“模型请求的入口层”：codex 侧仍然按 OpenAI 兼容格式发请求，TaoToken 负责把请求分发到你指定的模型通道。
官网入口：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=
API 基地址：https://taotoken.net/api
如果你要拿 Key，去控制台的 API Keys 页面：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite
接入文档在：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite
模型对话验证页：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite
长期编码或 Agent 场景可以看 Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
ClaudeCodeAnthropic 相关入口：https://taotoken.net/claude-code-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claude_code&utm_campaign=rewrite
这里的关键点是：TaoToken 的 API 地址要填在 CC Switch 的供应商配置里，而不是直接写进 codex 的 auth.json。这样官方登录缓存不会被污染，插件和手机控制的能力也不会丢。
3. 可复制配置：settings.json 骨架与 CC Switch 供应商参数
CC Switch 3.16.1 的配置落地，核心是两份内容：一份是 CC Switch 内部的供应商配置，一份是 codex 侧的 settings.json 骨架。下面给出可直接复制的结构。
3.1 codex settings.json 骨架
{ "model_provider": "taotoken", "model": "deepseek-chat", "providers": { "taotoken": { "name": "TaoToken 统一通道", "base_url": "https://taotoken.net/api", "api_key": "sk-你的TaoTokenKey", "wire_api": "chat", "models": { "deepseek-chat": { "name": "DeepSeek", "context_window": 128000 }, "kimi-k2": { "name": "Kimi", "context_window": 128000 }, "glm-4.6": { "name": "GLM", "context_window": 128000 } } } } }这个骨架里，base_url指向 TaoToken 的 API 地址，api_key填你在控制台拿到的 Key，wire_api设为chat表示走 Chat Completions 协议。DeepSeek、Kimi、GLM 的模型名按你实际开通的通道填写，上面只是示例。
3.2 CC Switch 供应商配置对照
在 CC Switch 里添加第三方 Codex 供应商时，推荐优先用内置预设。以 DeepSeek 为例，选择预设后只需要填 API Key，预设会自动配置 base URL、默认模型、模型映射表和“需要本地路由映射”。
| 配置项 | DeepSeek | Kimi | GLM |
|---|---|---|---|
| 协议类型 | Chat Completions | Chat Completions | Chat Completions |
| 是否需要本地路由 | 是 | 是 | 是 |
| base URL 来源 | TaoToken API | TaoToken API | TaoToken API |
| API Key 位置 | 供应商配置 | 供应商配置 | 供应商配置 |
| 官方登录保留 | 开启 | 开启 | 开启 |
如果你的第三方供应商原生支持 OpenAI Responses API，可以不启用本地路由。但 DeepSeek、Kimi、GLM 这类只支持 Chat Completions 的路径，必须启用本地路由，让 CC Switch 把 codex 的 Responses 请求转换成 Chat Completions 请求。
3.3 开启“切换第三方时保留官方登录”
这一步是 3.16.1 的核心。去 CC Switch 设置里打开 codex 应用增强开关，再把路由开关添加到主页面。开启后，第三方供应商的 API 地址和 Key 写到 config.toml 的当前 provider 下，auth.json 保持官方登录缓存不变。
注意：如果你之前用旧版本切换过第三方，auth.json 可能已经被覆盖。建议先在 codex 里重新登录一次官方账号，再开启保留登录选项。
4. 验证请求：从 codex 到 TaoToken 的连通性检查
配置写完，接下来是验证。验证分三层：codex 侧能否识别当前 provider、TaoToken 侧能否收到请求、模型侧能否正常返回。
4.1 codex 侧检查
打开 codex app 或 cli，任意一个都行，它们的配置是共享的。先确认当前处于 codex 账号登录状态，然后切换供应商并打开路由开关。此时 codex 界面应该显示已登录，但模型走的是第三方通道。
你可以用一条简单命令测试：
codex --model deepseek-chat "用一句话说明当前模型通道"如果返回内容正常，说明 codex 到 CC Switch 的链路通了。
4.2 TaoToken 侧检查
在 TaoToken 的模型对话页面可以直接发一条测试请求，确认 Key 和通道可用。模型对话入口：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite
如果模型对话页面能正常返回，说明 TaoToken 侧的 Key 和通道没问题。此时如果 codex 侧不通，问题大概率在 CC Switch 的本地路由或 settings.json 的 base_url 上。
4.3 插件与手机控制验证
插件功能验证：在 codex 里安装一个 outlook 插件，能正常安装并调用，说明官方登录态保留成功。
手机控制验证：手机上打开 ChatGPT，登录相同账号，选择 codex 并连接。可以正常连接，说明 auth.json 的官方登录缓存没有被覆盖。
提示：以前使用账号登录的聊天记录不会显示，关闭 CC Switch 或者切换为 OpenAI Official 才能显示。以前使用 DeepSeek 这些 API 的聊天记录会正常显示。
5. 本篇常见错排查
5.1 切换后插件消失
最常见的原因是 auth.json 被覆盖。检查 CC Switch 是否开启了“切换第三方时保留官方登录”。如果没有开启，第三方 API Key 会写进 auth.json，官方登录缓存丢失，插件和手机控制自然不可用。
5.2 模型请求 404 或 401
先确认 base_url 是否指向https://taotoken.net/api，再确认 API Key 是否有效。如果 Key 没问题，检查 wire_api 是否设为chat。DeepSeek、Kimi、GLM 都不支持 Responses API，wire_api 设错会导致请求格式不匹配。
5.3 本地路由开关没打开
DeepSeek、Kimi、GLM 这类 Chat Completions 协议必须启用本地路由。如果没开，codex 发出的 Responses 请求会直接打到第三方 API，对方不认这个格式，就会报错。开启后，CC Switch 在中间做格式转换。
5.4 手机控制连不上
先确认 codex 侧是否处于官方账号登录状态。如果 auth.json 被覆盖，手机控制会失效。重新登录官方账号，再开启保留登录选项，然后重启 codex app。
5.5 模型名不匹配
settings.json 里的模型名要和 TaoToken 通道里实际开通的模型名一致。比如你填了deepseek-chat，但通道里只有deepseek-v4-flash，请求就会失败。去模型对话页面确认可用模型名。
6. 多模型切换的长期用法与 CTA
CC Switch 3.16.1 把 codex 的官方登录态和第三方模型通道拆开管理之后，多模型切换的体验顺了很多。你可以把 DeepSeek、Kimi、GLM 都挂在 TaoToken 统一通道下，用同一个 Key 管理，切换时只改 config.toml 的当前 provider，auth.json 不动。
如果你要长期跑编码或 Agent 任务，建议把 TaoToken 的 Coding Plan 用起来，入口在：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding_plan&utm_campaign=rewrite
接入文档和 API Keys 页面建议收藏，排障时直接对照：接入文档 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，API Keys https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api_keys&utm_campaign=rewrite
实测下来，最容易踩的坑不是模型本身，而是 auth.json 和 config.toml 的写入位置。把这两个文件的分工搞清楚，插件、手机控制、第三方模型三者可以同时存在。
