Codex CLI 接 DeepSeek 报404或/responses does not exist，先别急着怀疑 Key。排障时我通常直接打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content= 拿一把 TaoToken 的 API Key，再把它填进 CC Switch 的自定义供应商，靠本地路由把/responses改写为/chat/completions，Codex 就能正常发请求了。下面按这套路径把每一步拆开讲。
1. 先拆报错：Codex CLI 的 404 是怎么被「协议断层」逼出来的
1.1 一条 404 背后是 Responses 与 Chat Completions 两套协议
Codex CLI 默认跟后端模型说话时，用的是 OpenAI 定义的 Responses API，请求路径落在/responses。而 DeepSeek、Kimi、MiniMax、SiliconFlow 这些第三方模型服务商，对外几乎统一提供 Chat Completions 接口，路径是/chat/completions。两者不是换个 URL 就行的差别，请求体的字段结构、流式传输时的 SSE 事件命名、以及工具调用消息的组织方式都不同。Codex 用 Responses 的语义把请求发出去，上游用 Chat 的语义去读，自然读不懂。
所以 Codex 接 DeepSeek 时报404或/responses does not exist，绝大多数时候和 API Key 无关，也和余额无关。它只是被发到了一个不存在于上游服务器的路径上。DeepSeek 官方文档里给出的 OpenAI 兼容地址是https://api.deepseek.com，这个地址能正确处理/chat/completions，但处理不了/responses。Codex 不管这些，它只会按自己的协议往后拼路径。于是请求到了之后，上游服务端看一眼路径，直接回一个 404。
1.2 手动改 Codex 配置，为什么越改越乱
不少人在看见 404 之后，会尝试把 DeepSeek 的 base URL 直接写进~/.codex/config.toml，甚至把/chat/completions也拼进去，试图让 Codex 一次性打到 Chat 接口。这样做的结果是 Codex 依旧会在 base URL 后面追加它自己的协议路径，最终请求变成/chat/completions/responses这类奇怪组合，报错更加不可读。还有人在config.toml里强行调整wire_api字段，想让 Codex 改说 Chat 协议，但 Codex CLI 对 Responses 的依赖不是靠一个字段就能彻底切换的，改完经常出现模型列表加载异常、对话流中途断开。
正确思路是不要手动去跟 Codex 的协议硬拗，让专门的路由层在中间做协议转换。CC Switch 的本地路由会拦截 Codex 发出的/responses请求，把它重写为/chat/completions，再转发到上游接口；上游返回后，路由再把 Chat 格式的响应翻译回 Responses 格式，交给 Codex。只要这层转换正常工作，404 就不会出现。而 TaoToken 在这条链路里扮演的是上游统一 API 通道的角色，帮你把 DeepSeek 等模型的调用收口到同一个接口上。
2. 排障前的准备：在 TaoToken 拿 Key，并确认两个前置条件
2.1 注册、创建 API Key、记住模型广场
动手配置 CC Switch 之前，先访问 TaoToken，注册账号后进入控制台，创建一个 API Key。创建完成后，Key 只会完整展示一次，立刻复制下来，后面统一用YOUR_API_KEY这个占位符指代它。Codex 后续每一次对话产生的 Token 消耗，都会记在这把 Key 上，查账时也以这把 Key 为准。
TaoToken 的定位是统一 API 通道，把多家模型服务商的接口收拢到同一个 base URL。这样你不需要在 CC Switch 里为 DeepSeek、Kimi 分别维护满屏的服务器地址，而是用同一个接口地址去路由。创建好 Key 之后，顺手打开模型广场，确认你要用的 DeepSeek 模型 ID 以当时列表为准。不同时期可选的模型名会调整，直接照搬旧教程里写死的模型 ID，很容易在请求阶段再次翻车。
2.2 检查 CC Switch 版本和 Codex 配置目录
开始配置之前，先检查两件事。第一，CC Switch 的版本要足够新，本地路由的接管逻辑在 3.16.0 之后才稳定，版本太旧时建议先升级。第二，Codex CLI 至少要启动过一次，哪怕只是在终端里进去敲了一句/help。因为首次启动才会生成~/.codex/config.toml所需的目录骨架。CC Switch 接管 Codex 配置时要写入 live 配置，如果这个目录根本不存在，接管操作会找不到落点。
注意这里不需要你去手动创建config.toml，更不需要预先写好任何内容。只要让 Codex 自己生成过目录结构即可。确认这两项就绪后，进入下一步。
3. 把 TaoToken 填进 CC Switch：核心排障配置
3.1 新建自定义供应商，字段不要填错
打开 CC Switch，切到顶部「Codex」标签页，点击右上角加号新建供应商。这里要选「自定义供应商」，而不是直接选 DeepSeek 预设。因为我们要接入的是 TaoToken 的 Key，预设里封装的是 DeepSeek 官方接口信息，选预设就会绕开 TaoToken，Token 消耗也没法记到这把 Key 上。
自定义供应商表单里需要注意这几个字段：
- API Key：填
YOUR_API_KEY，也就是刚才在 TaoToken 控制台创建的那一把。 - Base URL：填
https://taotoken.net/api，末尾不要加/v1。 - API 格式：选择
OpenAI Chat Completions（需开启路由）。 - 默认模型 / 可选模型：以 TaoToken 模型广场当时列表为准，不要凭记忆编造模型名。
保存之前，务必打开「需要本地路由映射」开关。这个开关告诉 CC Switch：上游是一个 Chat 格式接口，不能直连，必须等路由层改写请求后再转发。如果不开启，Codex 的请求会直接照原样打到上游，404 依旧存在。
3.2 启动本地路由，确认 Codex 的 live 配置指向本地地址
保存供应商后，进入 CC Switch 的「路由」设置页，展开「本地路由」区域，打开总开关。本地代理服务会在127.0.0.1:15721上启动，然后在「路由启用」里把 Codex 开关打开。这一步的作用，是把 Codex 的 live 配置接管过来，让它请求本地代理，而不是直接请求一组遥远又陌生的远程接口。
接管之后，~/.codex/config.toml里会写入类似下面的内容，排障时重点核对这两行：
# 由 CC Switch 接管后自动生成，排障时核对这两行即可 base_url = "http://127.0.0.1:15721/v1" wire_api = "responses"这里有件事必须解释清楚：wire_api = "responses"出现是正常的，它表示 Codex 仍然用 Responses 协议的语义在本地说话。真正的协议转换在本地路由层发生：路由拦截/responses或/v1/responses路径，把它映射为/chat/completions，同时把 Responses 格式的请求体改写成 Chat Completions 格式，再转发到 https://taotoken.net/api。TaoToken 收到的是它能识别、能处理的 Chat 请求；返回结果时，路由再把响应整理成 Codex 认识的样子。全程不需要你去改config.toml里的路径映射。
4. 重启 Codex，验证 /model 与 404 是否消失
4.1 重启终端，让模型目录重新加载
配置完成并启用供应商后，把当前 Codex 终端会话彻底退出，再重新打开。重启不是走形式，两步逻辑都依赖它：一是 Codex 进程可能已经缓存了旧的config.toml内容，不重启就会继续用旧配置发请求；二是modelcatalogjson生成后，/model菜单必须等进程重启才能加载新的模型目录。
重启后进入 Codex，先输入/model，确认列表里出现了 TaoToken 供应商对应的 DeepSeek 模型。如果这里能看到模型，说明 CC Switch 接管成功，Codex 已经认识本地路由这个入口，同时也说明 TaoToken 侧的模型列表同步正常。如果看不到模型，先不要发对话，回到 CC Switch 检查供应商是否处于启用状态、本地路由的 Codex 开关是否还开着。
4.2 发一条真实对话，确认 404 消失且 Token 上账
模型列表正常后，直接发一句测试消息，简单问一下「刚才的协议转换路径是怎样的」这类无需访问外部的普通问题。能正常返回内容，且不再出现404或/responses 不存在的报错，就说明整条链路已经走通：Codex → 本地路由 → https://taotoken.net/api → DeepSeek 模型。这一过程中，Codex 始终只跟本地路由通信，TaoToken 收到的则是标准 Chat 格式请求，中间的关键转换由 CC Switch 完成。
走通之后，打开 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_content= 进控制台看用量。刚才那条测试消息消耗的 Token，应该已经记在这把 Key 名下。能查到这次调用，说明 Key、Base URL、模型 ID 三件事全部对上了；查不到，则说明某个环节的请求没有真正经过 TaoToken。
5. 再度排查：如果 /responses 报错依然存在，只剩这几处可查
5.1 Base URL 是否多写了 /v1，路由是否真的在跑
按上述流程操作完，如果 Codex 仍然报/responses does not exist，第一件事是回 CC Switch 检查自定义供应商里的 Base URL。TaoToken 的接口地址是https://taotoken.net/api，末尾不要加/v1。一旦填成https://taotoken.net/api/v1，本地路由在转发时就会拼出错误的路径，TaoToken 收到不合法的地址，返回的还是 404。这个错在保存时不会被拦下来，只有真正发请求时才会暴露。
第二件事是确认本地路由进程确实在运行。打开 CC Switch 的「路由」页，看总开关是否为开启状态，Codex 开关是否也处于开启状态。如果你只是在供应商列表里启用了供应商，却忘记启动路由，Codex 的 live 配置就不会指向127.0.0.1:15721，请求会直接打到不存在的远程路径，表现和本文标题里的报错一模一样。
5.2 查看 ~/.codex/config.toml 的 live 配置
还有一种场景：Codex 的配置文件曾经被手动改过，里面残留了 DeepSeek 官方或其他远程厂商地址。打开~/.codex/config.toml，看model_provider对应那一节里的base_url是不是http://127.0.0.1:15721/v1。如果指向的是形如https://api.deepseek.com的远程地址，说明当前并没有经过 CC Switch 的自定义供应商接管，或者接管后又被旧配置覆盖了。
要强调的是，不要手动把https://taotoken.net/api直接写进config.toml来“修复”这个问题。Codex 会在这个地址后面拼/responses，TaoToken 接口收到的就是规范之外的特殊请求，照样可能返回 404。正确做法是回到 CC Switch 重新启用供应商和 Codex 路由，让 CC Switch 重新生成 live 配置。手动编辑去和 CC Switch 抢控制权，只会让每次重启后的状态更加不可控。顺带也解释一个常见困惑：本地路由地址127.0.0.1:15721/v1允许带/v1，因为这是 CC Switch 自己起的本地代理；TaoToken 的远程接口地址不带/v1，两者尾缀规则互不影响。
6. 跑通之后，回到 TaoToken 控制台对账并选下一步
6.1 用同一把 Key 在官方模型对话里做交叉验证
Codex 能正常对话后，还可以做一次交叉验证：打开 TaoToken 模型对话，用同一把YOUR_API_KEY发一条相同的问题。Codex 侧成功、模型对话页也成功，说明协议改写、Key 鉴权、模型 ID 三个环节都没有问题。如果只有 Codex 成功，模型对话页反而失败，问题大概率出在 Key 本身：可能复制时多了空格，也可能创建后没有完整保存。
这时可以直接去 TaoToken 控制台的 API Keys 页 重新创建一把 Key，替换YOUR_API_KEY再试一次。干净的 Key 应当是一串连续的字母数字组合，前面没有引号，末尾也没有多余换行。
6.2 按用量决定 Coding Plan，顺手看看 Claude Code 接入文档
测试通过后，建议打开 Coding Plan 看一眼套餐是否覆盖 Codex CLI 的日常消耗。偶尔在终端里查几个问题，按量计费更灵活；整天开着 Codex 写代码，套餐通常更划算。具体数字以控制台显示为准，这里不做估算。
如果你同时也在用 Claude Code，TaoToken 专门准备了 Claude Code 接入文档。Claude Code 走的是环境变量配置，和 Codex 的config.toml完全不同，不要把这篇文章里的127.0.0.1:15721直接搬过去。接好之后，模型对话页同样是一个快速的验证入口，遇到接口层面的疑问，先在模型对话里发一条消息，能很快判断问题是在 TaoToken 侧还是在自己的客户端配置上。这样处理完，Codex CLI 接 DeepSeek 的 404 基本就告别了，后面再切其他模型，也只需要在 CC Switch 里复制一个新的供应商而已。
