通过 CC Switch 本地路由让 Codex CLI 接入 DeepSeek 等第三方模型
OpenAI 为 Codex CLI 指定的后端协议是 Responses API（/responses），而国内主流模型厂商——DeepSeek、Kimi、MiniMax、SiliconFlow 等——对外统一提供的是 Chat Completions 接口（/chat/completions）。两种协议的差异贯穿整个请求-响应链路：请求体的字段结构与语义不同，流式传输中的 SSE 事件命名和数据结构也不同。如果直接把某个 Chat 格式的 base URL 写入 Codex 配置，常见的症状包括模型列表加载异常、接口返回 404 或 400，以及流式响应无法被 Codex 侧正确反序列化。
CC Switch 的本地路由正是为了解决这一协议断层而设计的。它的工作模型可以概括为：Codex 始终认为自己在与一个标准的 Responses API 端点通信，而本地路由在中间完成协议识别、请求改写和响应还原。
本地路由的转换链路
当 CC Switch 接管 Codex 配置后，完整的请求路径会经历四个阶段：
- 配置文件改写：CC Switch 将 Codex 的 live 配置指向
http://127.0.0.1:15721/v1，并强制锁定wire_api = "responses"，确保 Codex 发出的所有请求均使用 Responses 协议。 - 格式标记：Provider 配置中的
meta.apiFormat = "openai_chat"告知路由层该上游的真实接口形态是 Chat Completions。 - 请求转发与改写：路由拦截
/responses或/v1/responses路径，将其映射为/chat/completions，同时将 Responses 格式的请求体转换为 Chat Completions 格式。 - 响应回译：上游返回的 Chat 格式响应——无论是 JSON 还是 SSE 流——由路由层重新组装为 Codex 能够解析的 Responses 格式，再返回给客户端。
前置条件
开始配置之前需要确认三件事：
- CC Switch 已安装可正常运行并且CC Switch 3.16.0 及以上版本。
- Codex CLI 已安装，且至少启动过一次——这会生成
~/.codex/config.toml所需的目录骨架，否则接管操作无法写入配置。 - 手头已有 DeepSeek（或其他目标供应商）的 API Key。
补充一点：DeepSeek 官方文档标明的 OpenAI 兼容 base URL 为 https://api.deepseek.com，Chat 接口路径为 /chat/completions。CC Switch 的 DeepSeek 预设已经封装了这些信息，建议直接使用预设而非手工拼接 URL，避免路径错误。
操作步骤
在 Codex 标签下添加供应商
打开 CC Switch，切换到顶部的「Codex」标签页，点击右上角加号新建供应商。 
在预设列表中选择「DeepSeek」，选择之后往下拉然后需完成两项输入： 
- 填入你的 DeepSeek API Key。
- 保存该供应商配置。
预设已经自动填入了接口地址、默认模型、可选模型列表以及 thinking/reasoning 相关参数，并且默认开启了「需要本地路由映射」。如果需要调整默认模型或模型展示名称，可以按需修改，协议层的转换则完全交给路由处理。
启动本地路由并接管 Codex 配置
进入设置的「路由」页面 
展开「本地路由」区域，依次完成两个开关： 
- 打开路由总开关，本地代理服务随即在
127.0.0.1:15721上启动。 - 在「路由启用」中打开 Codex 选项。如果路由仅服务于 Codex，可以保持 Claude、Gemini 等开关处于关闭状态。
接管生效后，CC Switch 会将 Codex 的 live 配置改写为指向本地路由地址，并使用占位符替代真实的 API Key。实际的 DeepSeek Key 始终保存在 CC Switch 的 Provider 配置中，由本地路由在转发请求时动态注入——Codex 的 live 配置中不会暴露真实的密钥。
启用供应商并重启 Codex
回到 Codex 供应商列表，点击 DeepSeek 供应商上的「启用」。 
如果看到「需要路由」标记，说明该供应商依赖本地路由运行；此时若路由服务未启动，CC Switch 会弹出提示。
切换到新供应商后，建议重启当前的 Codex 终端会话，原因有两点：
- Codex 进程可能已经缓存了旧的
config.toml内容。 modelcatalogjson生成后，/model菜单通常需要进程重启才能加载新的模型目录。
重启后进入 Codex，使用 /model 命令确认当前模型是否来自 DeepSeek 预设（例如 DeepSeek V4 Flash）。需要注意，目前 Codex app 尚未支持多模型自由切换，它将默认使用配置中的第一个模型。
其他 Chat 格式供应商的配置规律
DeepSeek、Kimi、MiniMax、SiliconFlow 等常见 Chat 格式供应商在 CC Switch 中均已提供预设，优先选用预设即可减少手工配置出错的可能性。只有当供应商不在预设列表中时，才需要走自定义配置路径：按照供应商文档填入 API Key、base URL 和模型信息，并将「API 格式」选为「OpenAI Chat Completions（需开启路由）」。
反过来，如果某个上游本身已经原生支持 OpenAI Responses API，则无需开启「需要本地路由映射」——此时 CC Switch 可以直连 Responses 端点，不做任何协议转换。
常见问题排查
如果问他是什么模型
提示是 GPT-5 是没有问题的。因为有系统内置提示词。具体使用消耗可以到[设置] 里面使用统计看到，如下图 
Codex 端报 404 或 /responses 不存在
通常意味着 Codex 接管未生效，或者手动将上游 Chat 格式的 base URL 直接写入了 Codex 配置。检查 ~/.codex/config.toml 中的地址是否为 http://127.0.0.1:15721/v1，以及相应开关是否已开启。
DeepSeek 上游返回 404
如果使用的是内置 DeepSeek 预设，先确认供应商确实来自预设列表且 Codex 路由已开启。只有在自定义供应商场景下，才需要额外核查 base URL：它应当指向服务的根地址，而不是包含 /chat/completions 后缀的完整接口路径。
/model 中看不到 DeepSeek 模型
保存供应商配置后重启 Codex 终端。CC Switch 会生成 cc-switch-model-catalog.json 并把路径写入 modelcatalogjson，但正在运行的 Codex 进程不会热加载该目录。
此外，Codex app 目前仅使用配置中的首个模型，不提供多模型选择界面。
路由已开但请求仍走到了错误供应商
同时确认三处状态：Codex 标签下当前供应商为 DeepSeek；本地路由服务处于运行状态；「路由启用」中 Codex 开关为开启。
能否用官方 OpenAI Codex 账号走本地路由
不建议这样做。CC Switch 在本地路由接管模式下会阻止切换到官方供应商，因为通过代理访问官方 API 存在账号安全风险。本地路由的设计目标场景是第三方供应商接入、聚合调度以及协议转换。
