为什么非得绕这一道本地路由

先说清楚问题出在哪。新版 Codex CLI 面向的是 OpenAI Responses API，但 DeepSeek、Kimi、MiniMax、SiliconFlow 这些供应商实际暴露出来的是 OpenAI Chat Completions 形态，也就是 /chat/completions 那一套。这两种协议的请求体、流式事件、返回结构全都不一样。

我一开始也想偷懒，直接把 Chat 接口地址填进 Codex 配置里——结果就是经典三连：模型列表不对、请求 404/400、流式响应 Codex 根本解析不了。这不是配置写错了，是协议层面就对不上。

CC Switch 的思路很干脆：让 Codex 始终连本机路由，请求仍然按 Responses API 的格式发；路由在内部判断当前供应商是不是 Chat 格式，是的话就把请求改写成 Chat Completions 发给上游，拿到响应再转回 Responses 形态还给 Codex。Codex 全程被蒙在鼓里，但它开心就行。

整条链路拆开来是四步：

  • Codex 接管时，本地配置会被写成 http://127.0.0.1:15721/v1，并强制保持 wire_api = "responses"。
  • Provider 的 meta.apiFormat = "openai_chat" 告诉路由：真实上游是 Chat Completions。
  • 路由把 /responses 或 /v1/responses 改写到 /chat/completions，同时把 Responses 请求体转换成 Chat 请求体。
  • 上游返回后，路由再把 Chat 的 JSON 或 SSE 转回 Codex 能理解的 Responses JSON/SSE。

动手前先备齐三样东西

  • 已安装并能正常启动的 CC Switch。
  • 已安装 Codex CLI，而且至少跑过一次——这一步别省，目的是让 ~/.codex/config.toml 的目录结构先生成出来。
  • DeepSeek 或同类 Chat Completions 供应商的 API Key。

关于 base URL 多说一句。DeepSeek 官方文档写明 OpenAI 兼容的 base URL 是 https://api.deepseek.com（注意它没有 /v1 后缀，其他供应商常见的反而是带 /v1 的），Chat API 路径是 /chat/completions。好在 CC Switch 的 DeepSeek 预设已经按这些信息配好了，优先用预设，别自己手动拼接口路径——手拼最容易出事的就是 base 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 配置指向本机路由，并用占位符来管理认证。这里有个我挺喜欢的设计：真实的 DeepSeek Key 仍然只保存在 CC Switch 的 Provider 配置里，由本地路由在转发时才注入，不需要你把 Key 暴露给 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 直连，省掉中间的 Chat 转换。

几个常见的坑

Codex 报 404 或找不到 /responses —— 多半是没开 Codex 接管，或者你手动把上游的 Chat base URL 直接写给了 Codex。回去检查 ~/.codex/config.toml 是不是指向 http://127.0.0.1:15721/v1。

DeepSeek 上游报 404 —— 用内置预设的话，先确认当前供应商确实来自预设，而且 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 可能带来账号风险。这套路由主要是给第三方、聚合或者协议转换场景用的。

说实话，这套方案最大的价值不在于「能省钱用 DeepSeek 跑 Codex」，而在于它把协议转换这件脏活封装在了本地路由里，让你不用为了每家供应商的接口差异反复折腾配置。如果你手上有好几个 Chat 格式的国产供应商想接 Codex，建议直接上 CC Switch 的预设，别自己手拼地址——我试过手拼，最后定位问题花的时间远比省下的多。配好之后记得养成习惯：每次切供应商都重启一下 Codex 会话，能少踩一大半的坑。