Codex终于能完美使用国产大模型了！

CC Switch v3.16.0发布啦！作者原话："谨以纪念此版本开发期间死去的 5 个 Claude Max 订阅。" 其中多少无奈与心酸，加班与熬夜！

重大更新：

通过CC Switch，Codex能完美接入国产大模型了，deepseek、glm、minimax、kimi全能能用了！工具也能正常调用了，之前虽然也有一些中转方案，但都没有这个完美！

当然也不是没有门槛的，首先得完成登录，进入到codex内，得用gpt账号登录，我测试用apikey登录是不行的。

CC switch需要开启路由，来接管codex的请求，其他内容正常配置即可。

两套协议，一堵墙

Codex CLI 用的是 OpenAI Responses API，请求路径是 /v1/responses，请求体和返回结构都是围绕 Responses 设计的。流式事件类型、 reasoning 内容格式、工具调用表达方式——整套语义体系。

DeepSeek、Kimi、MiniMax 这些供应商开放的是 OpenAI Chat Completions 兼容接口，路径 /v1/chat/completions。请求体不一样（比如没有 previous_response_id），流式 SSE 事件的字段名不同， reasoning 内容在 Chat 格式里通常藏在 choices[0].delta.reasoning_content，而 Responses 格式里是单独的 output 类型。

直接填进去会怎样？

模型列表对不上。请求 404。或者更隐蔽一点——请求能发出去，流式响应回来 Codex 解析不了，界面卡住不动。之前有人用手动改 base URL 的方式接 DeepSeek，结果就是这些问题轮番上演。

CC Switch 的做法：本地路由做翻译

思路不复杂：让 Codex 始终连本机，以为自己在跟 OpenAI Responses API 说话。本地路由收到请求后，识别当前供应商是不是 Chat 格式，如果是，就把请求翻译成 Chat Completions 发给上游，再把上游的响应翻译回 Responses 格式还给 Codex。

这条链路拆成四步：

第一步，接管。 CC Switch 把 Codex 的 live 配置指向 http://127.0.0.1:15721/v1，并强制 wire_api = "responses"。Codex 以为自己连的是 OpenAI。

第二步，识别。 Provider 配置里的 meta.apiFormat = "openai_chat" 告诉路由：这个供应商的真实接口是 Chat Completions，需要做协议转换。

第三步，改写。 路由把 /responses 或 /v1/responses 改写到 /chat/completions，同时把 Responses 请求体（含 input、previous_response_id、tools 等字段）映射成 Chat 的请求体（messages、tool_choice 等）。

第四步，回写。 上游返回 Chat 格式的 JSON 或 SSE 流，路由再把它重建回 Responses 的 JSON/SSE 结构。 reasoning 内容、工具调用状态、流式 token 统计——每条都得映射到正确的位置。

这个"翻译"不好做。Chat 和 Responses 对工具调用的表达方式完全不同，跨轮 tool call 如果不映射，上下文就断裂。CC Switch 为此维护了一个有界历史缓存，专门在工具输出前恢复对应的工具调用。v3.16.0 里光是协议转换相关就写了将近 3000 行代码。

听起来抽象？打个比方：Codex 说的是英语（Responses），国产模型说的是汉语（Chat）。CC Switch 的本地路由就是那个同声传译，而且是双向的，还得保证专业术语（工具调用、推理内容）不译错。

配置前的准备

需要三样东西：

• 已安装并能正常启动的 CC Switch（v3.16.0 或更新版本）
• 已安装 Codex CLI，并且至少运行过一次——目的是让 ~/.codex/config.toml 的目录结构存在
• 一个 Chat Completions 供应商的 API Key，DeepSeek 或同类都行

关于登录方式多说一句：进入 Codex 内需要先用 GPT 账号完成登录，用 API Key 直接登录是不行的。这是 Codex CLI 本身的限制，不是 CC Switch 的问题。

DeepSeek 的 OpenAI 兼容 base URL 是 https://api.deepseek.com，Chat API 路径是 /chat/completions。CC Switch 的 DeepSeek 预设已经把这些信息内置好了，优先用预设，不需要手动拼接口路径。

第一步：添加 Codex 供应商

打开 CC Switch，切到顶部的 Codex 标签，点击右上角的加号。

选内置预设里的 DeepSeek。要填的只有 API Key，其他全部预置好了：请求地址、默认模型、模型菜单、thinking/reasoning 参数。保存即可。

预设会自动打开「需要本地路由映射」开关。你可以改默认模型或模型显示名，但协议转换这部分交给路由层，不用管。

第二步：开启本地路由并接管 Codex

进入设置 → 路由，展开「本地路由」：

1. 打开「路由总开关」，启动本地服务。默认监听 127.0.0.1:15721。

• 在「路由启用」里打开 Codex。如果只想让 Codex 走路由，Claude 和 Gemini 可以保持关闭。

接管后，CC Switch 会把 Codex 的 live 配置指向本机路由，并用占位符管理认证信息。真实的 DeepSeek Key 保存在 CC Switch 的 Provider 配置里，由本地路由在转发时注入。你的 Key 不会暴露在 Codex 的 live 配置中。

第三步：切换供应商并重启 Codex

回到 Codex 供应商列表，点击 DeepSeek 供应商的「启用」。

如果看到「需要路由」标记，说明这个供应商必须在路由运行时使用。没启动路由就点启用，CC Switch 会弹提示："需要路由服务才能正常使用"。

切换后务必重启 Codex 终端会话。 两个原因：

• Codex 进程启动时读取 config.toml，运行中不重新加载
• model_catalog_json 生成后，/model 菜单通常需要新进程才能刷新

重启后进入 Codex，用 /model 查看当前模型。如果显示的是 DeepSeek 预设里的模型（比如 DeepSeek V4 Flash），说明配置生效了。发一个小问题测试一下，看路由面板的请求数有没有增长，或者去用量日志里确认 Codex 的请求被记录。

其他供应商怎么配

DeepSeek、Kimi、MiniMax、SiliconFlow 这些常见 Chat 格式供应商在 CC Switch 里都有预设，直接用预设。

只有在预设里找不到的供应商，才需要选「自定义」。这时候按对方文档填 API Key、base URL 和模型，把 API 格式选成「OpenAI Chat Completions (需开启路由)」。

如果上游直接支持 OpenAI Responses API，就不需要开「需要本地路由映射」。CC Switch 可以直连，不做转换。

常见问题

Codex 报 404，说找不到 /responses

通常两个原因：没有开启 Codex 接管，或者手动把上游 Chat base URL 直接写进了 Codex 配置。检查 ~/.codex/config.toml 里的 api_url 是否指向 http://127.0.0.1:15721/v1。

DeepSeek 上游报 404

确认三点：当前供应商来自内置预设（不是自定义拼的）、Codex 路由开关已打开、CC Switch 本地路由服务正在运行。如果用的是自定义供应商，检查 base URL 是否是服务根地址（比如 https://api.deepseek.com），不要带 /chat/completions 后缀。

/model 看不到 DeepSeek 模型

保存供应商配置后重启 Codex。CC Switch 会生成 cc-switch-model-catalog.json 并把路径写入 model_catalog_json，但运行中的 Codex 进程不会热加载模型目录。目前 Codex app 不支持多模型选择，默认使用配置里的第一个模型。

开了路由但请求仍走错供应商

三处状态必须一致：Codex 标签下当前启用的供应商是 DeepSeek；本地路由服务在运行；路由启用里 Codex 开关已打开。任何一处对不上，请求就可能绕开路由直走默认配置。

能用官方 OpenAI Codex 账号走本地路由吗？

不建议。CC Switch 在本地路由接管模式下会阻止切到官方供应商，因为用代理访问官方 API 可能带来账号风险。路由的设计场景是第三方、聚合或协议转换，不是给官方通道套代理。

国产大模型在代码场景上的表现，过去一年进步很快。DeepSeek 的推理能力、Kimi 的长上下文、GLM 的指令跟随——这些特性放在 Codex 的交互框架里，体验跟直接用 Chat 网页版完全不同。

问题是接口协议这道门槛把大多数人挡在外面。CC Switch v3.16.0 的路由方案，本质上是在填这个"最后一公里"的坑。

填完之后呢？接下来要看的是：在 Codex 这种 agent 编程的场景下，国产模型的工具调用稳定性、长会话上下文保持、复杂项目理解——这些硬指标能不能经得起日常开发的压力测试。

这才是真正有意思的部分。