1. Codex 只认 Responses上游只给 Chat Completions 怎么办Codex 这类客户端在较新的版本里默认走 Responses 协议请求体里是instructions、input、store这些字段返回的是response.output_text.delta这类 SSE 事件。但现实情况是很多兼容 OpenAI 的服务端只实现了/v1/chat/completions也就是 Chat Completions 协议字段是messages、max_tokens返回chatcmpl-*和choices[].delta.content。两边字段对不上Codex 直接报错你连模型都调不起来。我遇到的具体现象是这样的Codex 启动后发请求日志里出现reading choices或者Unexpected response format有时候干脆 404因为客户端请求的是/v1/responses而上游根本没有这个路由。这不是 Key 的问题也不是网络的问题纯粹是协议层不匹配。解决思路有两条。第一条是换客户端把 Codex 降级到只发 Chat Completions 的版本但这样会丢掉 Responses 带来的会话管理和工具调用能力。第二条是在本地起一个轻量代理专门做协议转换对外暴露/v1/responses对内把请求翻译成/v1/chat/completions转发给上游再把上游的 Chat 响应翻译回 Responses 格式。第二条路更干净客户端和上游都不用改。这篇要做的就是第二条路。我会用一个独立的协议代理服务把 Codex 的auth.json指向 TaoToken 的统一通道让 Codex 稳定走通 Responses 协议。整个链路是Codex → 本地代理Responses 转 Chat→ TaoToken APIChat Completions→ 模型。代理只做协议翻译不碰计费、不碰用户管理启动一个进程就能跑。适合谁看已经在用 Codex 或者准备用 Codex但上游只提供 Chat Completions 端点的开发者想把多个模型统一到一个 Key 通道又不想改客户端代码的人以及在做渐进式迁移、部分服务已经升级到 Responses 的团队。下面从环境准备开始一步步把配置跑通。2. TaoToken 前置准备Key、Base URL 与模型 ID 三件套在动代理之前先把上游这一侧准备好。TaoToken 提供的是兼容 OpenAI 格式的 Chat Completions 端点所以代理的上游地址就填它的 API 地址。你需要拿到三样东西Base URL、API Key、Model ID。这三件套在后面的代理配置和 Codex 配置里都会用到缺一个都跑不通。Base URL 是https://taotoken.net/api注意这里不带任何查询参数就是纯 API 根路径。代理会把/v1/chat/completions拼在它后面所以你在代理配置里填的UPSTREAM_BASE_URL应该是https://taotoken.net/api/v1这样代理转发时路径才对得上。如果你填成https://taotoken.net/api代理可能会拼出/api/v1/chat/completions具体取决于代理的路径处理逻辑建议按代理文档的默认约定来通常是带/v1的。API Key 在控制台的 API Keys 页面创建。地址是https://taotoken.net/console/api-keys登录后点创建复制出来的字符串就是你的 Key。这个 Key 只显示一次建议先存到密码管理器或者本地环境变量文件里。代理侧会用这个 Key 作为UPSTREAM_API_KEYCodex 侧不直接接触它这样 Key 只在代理进程里出现客户端配置里看不到明文。Model ID 取决于你要调哪个模型。TaoToken 的模型列表可以在模型对话页面查看地址是https://taotoken.net/models。常见的比如gpt-4o-mini、claude-3-5-sonnet这类具体以你账号下可用的为准。Codex 的auth.json里会填这个 Model ID代理转发时也会带上它。如果你不确定用哪个先用一个便宜的小模型把链路跑通再换成主力模型。这里有个容易踩的坑TaoToken 的 Key 是统一通道的 Key不是某个模型专属的。你可以在一个 Key 下切换不同模型只要在请求里改model字段就行。代理和 Codex 都支持在配置里指定模型所以你可以给 Codex 配一个默认模型需要时再改。另外如果你打算长期用 Codex 做编码任务可以考虑 Coding Plan地址是https://taotoken.net/coding-plan它针对编码场景做了额度优化比按量计费更适合高频使用。准备好这三件套后先别急着配 Codex先用 curl 直接打一次 TaoToken 的 Chat Completions 端点确认 Key 和网络都正常。命令如下curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: Say hello in one sentence.}] }如果返回里有choices[0].message.content说明上游通了。如果返回 401检查 Key 有没有复制完整如果返回 404检查 Base URL 是不是多了或少了/v1。这一步通了再往下配代理。3. 可复制配置代理启动参数与 Codex auth.json 字段改法代理服务本身是独立的不依赖数据库和用户系统启动方式有三种交互式启动器、模块启动、uvicorn 启动。本地开发推荐交互式启动器第一次运行会让你输入上游地址和 API Key自动保存到~/.responses-chat-proxy/config.json下次直接复用。但如果你要把它写成可复制的配置建议用环境变量或者配置文件的方式这样换机器也能一键拉起。先看代理侧的环境变量配置。你可以写一个.env文件内容如下UPSTREAM_BASE_URLhttps://taotoken.net/api/v1 UPSTREAM_API_KEYsk-你的TaoTokenKey PROXY_API_KEYlocal-proxy-token HOST127.0.0.1 PORT8000 REQUEST_TIMEOUT_SECONDS120 STREAM_TIMEOUT_SECONDS300 VERIFY_SSLtrue LOG_LEVELinfo这里UPSTREAM_BASE_URL填 TaoToken 的 API 地址加/v1UPSTREAM_API_KEY填你在控制台创建的 Key。PROXY_API_KEY是代理侧的鉴权 Token留空就关闭鉴权本地开发可以留空但如果你想让 Codex 通过代理鉴权、不直接暴露上游 Key就设一个值比如local-proxy-token。HOST用127.0.0.1只监听本地避免局域网其他机器访问。PORT默认 8000如果被占用就换一个。启动代理的命令# 方式一交互式启动器 responses-chat-proxy # 方式二模块启动 python -m responses_chat_proxy # 方式三uvicorn uvicorn responses_chat_proxy.main:app --host 127.0.0.1 --port 8000启动后你会看到类似Uvicorn running on http://127.0.0.1:8000的日志。这时候代理已经在监听/v1/responses等待 Codex 的请求。接下来改 Codex 的auth.json。Codex 的配置文件通常在~/.codex/auth.json不同版本路径可能略有差异你可以用codex config path或者查看文档确认。这个文件里原本可能存的是 OpenAI 的 Key 和 Base URL我们要把它改成指向本地代理。一个典型的auth.json结构如下{ OPENAI_API_KEY: local-proxy-token, OPENAI_BASE_URL: http://127.0.0.1:8000/v1, model: gpt-4o-mini }这里三个字段要对应上OPENAI_API_KEY填代理的PROXY_API_KEY如果你代理侧没设鉴权这里可以填任意非空字符串比如dummy但有些 Codex 版本会校验非空所以别留空。OPENAI_BASE_URL填http://127.0.0.1:8000/v1注意结尾的/v1Codex 会在这个基础上拼/responses。model填你要用的 Model ID比如gpt-4o-mini这个值会透传给代理代理再转发给 TaoToken。如果你用的是 Codex 的 TOML 配置有些版本用config.toml写法类似[openai] api_key local-proxy-token base_url http://127.0.0.1:8000/v1 model gpt-4o-mini改完保存重启 Codex。这时候 Codex 发请求的路径是http://127.0.0.1:8000/v1/responses代理收到后翻译成https://taotoken.net/api/v1/chat/completions带上你的 TaoToken Key 转发出去。整条链路里Codex 只看到本地代理TaoToken Key 只在代理进程里客户端配置里没有明文。如果你同时用 Cline 或者 Claude Code 这类工具它们的配置逻辑类似都是把 Base URL 指向代理Key 填代理的鉴权 Token。Cline 的 MCP 配置里baseUrl填http://127.0.0.1:8000/v1apiKey填local-proxy-tokenmodel填 Model ID。Claude Code 的settings.json里env段填ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY但注意 Claude Code 走的是 Anthropic 协议不是 Responses所以这个代理不适用于它除非代理也支持 Anthropic 转换。这里只聚焦 Codex 的 Responses 场景。4. 验证请求一次真实的 Responses 调用与成功结果配置改完后别直接开 Codex 跑大任务先用 curl 打一次代理的/v1/responses确认协议转换正常。这一步能帮你快速定位是代理的问题还是 Codex 的问题。非流式请求curl http://127.0.0.1:8000/v1/responses \ -H Content-Type: application/json \ -H Authorization: Bearer local-proxy-token \ -d { model: gpt-4o-mini, instructions: You are concise., input: Say hello in one sentence. }如果代理侧没设PROXY_API_KEYAuthorization头可以省略。返回应该是一个 Responses 格式的 JSON里面有id字段形如resp-*还有output数组里面是output_text类型的内容。如果你看到的是chatcmpl-*和choices说明代理没做转换检查代理版本和配置。流式请求curl -N http://127.0.0.1:8000/v1/responses \ -H Content-Type: application/json \ -H Authorization: Bearer local-proxy-token \ -d { model: gpt-4o-mini, input: Count to three., stream: true }流式返回应该是一串 SSE 事件依次出现response.created、response.output_text.delta、response.completed。每个delta事件里带一小段文本拼起来就是完整回答。如果你看到的是data: {choices:[{delta:{content:...}}]}说明代理没转换流式事件需要检查代理的适配器是否启用了流式转换。代理侧的日志会显示转发的上游请求和响应状态。正常情况你会看到类似POST /v1/responses 200和POST https://taotoken.net/api/v1/chat/completions 200的日志。如果上游返回 401检查UPSTREAM_API_KEY是不是填对了如果返回 404检查UPSTREAM_BASE_URL是不是多了或少了/v1。curl 通了之后再启动 Codex。Codex 启动时会读auth.json然后发一个初始化请求。你可以在 Codex 里输入一个简单问题比如「用一句话解释什么是递归」看它能不能正常返回。如果 Codex 报错先看代理日志确认请求有没有到代理如果到了代理但上游报错看上游返回的状态码和错误信息。实测下来最常见的成功结果是Codex 正常输出回答代理日志里两条 200TaoToken 控制台的用量统计里能看到这次调用。如果你在控制台看不到用量可能是 Key 不对或者请求没到上游回头检查代理配置。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节把可能遇到的报错集中列一下对照着排查。401 Unauthorized分两种情况。如果代理日志显示上游返回 401说明UPSTREAM_API_KEY不对去 TaoToken 控制台重新复制 Key注意别带空格。如果 Codex 报 401说明代理侧鉴权没通过检查auth.json里的OPENAI_API_KEY是不是和代理的PROXY_API_KEY一致。如果你代理侧没设PROXY_API_KEY但 Codex 发了Authorization头有些代理实现会忽略有些会拒绝建议要么两边都设要么两边都不设。local proxy failedCodex 报这个错通常是代理没启动或者OPENAI_BASE_URL填错了。先确认代理进程在跑curl http://127.0.0.1:8000/v1/responses能不能通。如果代理在跑但 Codex 连不上检查auth.json里的地址是不是http://127.0.0.1:8000/v1别填成https本地代理通常没配 TLS。另外如果你把HOST设成了0.0.0.0Codex 用127.0.0.1也能连但如果你设成了某个具体网卡地址就要填那个地址。reading choices这个报错说明 Codex 收到了 Chat Completions 格式的响应但它在按 Responses 格式解析找不到choices之外的字段。根因是代理没做转换或者转换没生效。检查代理版本确认它支持 Responses 转换检查请求路径是不是/v1/responses如果 Codex 发到了/v1/chat/completions代理可能直接透传了。另外有些代理需要显式开启转换开关看下配置里有没有相关选项。OAuth 相关报错Codex 某些版本会用 OAuth 流程auth.json里可能存的是 token 而不是 API Key。如果你看到 OAuth 报错说明 Codex 在尝试走 OAuth 而不是 API Key 模式。解决办法是在 Codex 配置里显式指定用 API Key或者把auth.json里的字段改成OPENAI_API_KEY而不是 OAuth token。具体字段名看 Codex 版本文档不同版本可能有差异。流式请求卡住如果非流式正常但流式卡住检查STREAM_TIMEOUT_SECONDS是不是太短默认 300 秒一般够用。另外检查代理的流式转换有没有开启有些代理默认只支持非流式。如果上游返回的 SSE 格式和代理预期的不一致也可能卡住看代理日志里有没有解析错误。模型不存在如果上游返回model not found检查auth.json里的model字段和代理配置里的默认模型是不是 TaoToken 支持的。TaoToken 的模型列表在模型对话页面能查到别填一个不存在的名字。另外有些模型需要特定权限如果你账号下没有也会报这个错。排查的顺序建议是先 curl 代理再 curl 上游最后跑 Codex。这样能快速定位是代理的问题、上游的问题还是 Codex 的问题。代理日志和 Codex 日志都要看两边对照着看更容易找到根因。6. 把 Codex 稳定接到 TaoToken 的长期做法链路跑通之后接下来要考虑的是稳定性。本地代理进程如果挂了Codex 就用不了所以建议把代理做成开机自启或者用进程管理工具守护。Windows 上可以用任务计划程序macOS 和 Linux 上可以用 launchd 或 systemd。代理本身很轻内存占用不大常驻没问题。Key 的管理上建议把 TaoToken Key 只放在代理的环境变量里不要写进 Codex 的auth.json。这样即使 Codex 配置泄露上游 Key 也不会暴露。代理侧的PROXY_API_KEY可以定期轮换Codex 那边同步改一下就行。如果你有多台机器每台机器起一个本地代理各自配各自的PROXY_API_KEY上游 Key 可以共用也可以按机器分 Key方便在控制台看用量。模型切换上Codex 的auth.json里配一个默认模型需要换模型时改这个字段重启 Codex。代理侧不用改因为它只是透传model字段。如果你想让不同任务用不同模型可以在 Codex 里配多个 profile或者用环境变量覆盖。TaoToken 的统一 Key 通道支持多模型所以切换成本很低。长期用 Codex 做编码的话可以关注一下 Coding Plan地址是https://taotoken.net/coding-plan它针对编码场景做了优化适合高频调用。如果你只是偶尔用按量计费就够了。另外接入文档在https://taotoken.net/doc里面有更详细的参数说明和示例遇到不确定的字段可以去查。最后代理的日志建议保留一段时间方便排查问题。如果代理支持日志级别配置生产环境用info调试时用debug。日志里会记录请求路径、上游状态码、耗时这些信息对定位问题很有用。如果你发现某个模型经常超时可以调大REQUEST_TIMEOUT_SECONDS和STREAM_TIMEOUT_SECONDS但别调太大否则卡住的请求会占着连接。整套配置下来Codex 走的是 Responses 协议上游走的是 Chat Completions中间靠代理翻译。你不需要改 Codex 源码也不需要上游支持 Responses两边各用各的格式互不干扰。这套方案也适用于其他只支持 Chat Completions 的客户端只要把 Base URL 指向代理就行。