先把结论放在前面Codex 完全可以不依赖官方默认模型把请求转发到 DeepSeek、通义千问这类国产大模型上而且实际操作只需要改一个配置文件。我过去一周把主力模型从 OpenAI 默认模型切到了 DeepSeek 和通义用来做日常写码、改 bug、补测试省下来的费用不是百分比而是数量级。这篇文章不打算讲太多理论概念重点讲怎么落地从选模型、改 config.toml、跑通第一个任务到处理那串很多人都会撞上的 “local proxy failed while handling codex endpoint /responses” 报错一次性说清楚。适合手里已经有国产模型 API Key、但不想再为 Codex 的默认计费掏钱的朋友也适合刚装好 Codex 还不知道怎么配第三方供应商的新手。1. 为什么要把 Codex 接到国产模型上1.1 先搞清楚 Codex 到底是什么Codex 是 OpenAI 出的一个终端 AI 编程代理不是传统的代码补全插件。它的工作方式是这样的你给它一个任务描述它自己读项目文件、定位相关代码、做修改、跑测试甚至执行命令行工具整个流程像一个远程程序员在帮你干活。使用体验上它比 Copilot 这类“你写一行我补一行”的工具更接近“你把需求说清楚我自己看代码自己改”属于 Agent 形态的编程工具。Codex 本身只是一个外壳真正干活的是它背后调用的模型。官方版本默认绑定 OpenAI 自家的模型问题是这套计费逻辑对国内开发者很不友好充值麻烦、按美元计费、单次 Agent 会话如果任务复杂跑下来消耗的 token 量相当惊人。我自己之前跑一个稍大的重构任务一个下午烧掉的额度折合人民币够吃两顿饭。很多人因此直接把 Codex 卸了其实挺可惜的。Codex 的架构里有个很关键的设计模型供应商是可以替换的。只要对方提供 OpenAI 兼容的 APICodex 就能把请求发过去。国内主流模型厂商基本上都做了 OpenAI 兼容层所以“Codex 配国产模型”不是魔改而是官方支持的用法只是知道的人不多。1.2 国产模型怎么选五家主流供应商横评既然要换选哪家就是个现实问题。我按实际用下来的体验把市面上能通过 OpenAI 兼容接口接进 Codex 的国产模型分成几类直接给你参照。供应商推荐模型API Base URL适合场景主要注意点DeepSeekdeepseek-chat / deepseek-reasonerhttps://api.deepseek.com/v1日常写码、代码理解、重构建议便宜性价比之王reasoner 适合复杂推理但慢阿里云百炼qwen-plus / qwen3-coderhttps://dashscope.aliyuncs.com/compatible-mode/v1中长上下文任务、中文场景上下文窗口大工具调用稳定智谱glm-4-plus / glm-4-flashhttps://open.bigmodel.cn/api/paas/v4/轻量任务、快速原型flash 免费档位适合测试复杂任务不够稳Moonshot Kimimoonshot-v1-32k / 128khttps://api.moonshot.cn/v1长文档分析、大仓库理解上下文大但写代码细节有时不如 DeepSeek火山方舟豆包doubao-seed 系列https://ark.cn-beijing.volces.com/api/v3需要走火山生态的用户需要创建推理接入点配置稍繁琐选型的核心逻辑不是“谁便宜选谁”而是看两点第一模型必须支持工具调用function calling因为 Codex 要靠这个能力来读取本地文件、执行命令第二上下文窗口要够大Codex 一次任务会把多个文件的内容塞进上下文只有 4K、8K 上下文的模型基本没法用。从我的实测来看DeepSeek 目前是综合体验最稳的。deepseek-chat 的代码能力放在国产模型里是第一梯队价格又低到可以忽略计费焦虑。如果你主要做中文项目、写业务代码直接闭眼选它。阿里 qwen-plus 我也用过一段时间优势是上下文给得大方遇到那种“把整个模块给我读一遍再改”的大活不容易截断。Kimi 的长上下文更强但写码场景的响应速度和修改准确度比 DeepSeek 略逊。1.3 接入前必须想清楚的三件事第一你要接受一个现实换模型后Codex 的能力下限取决于模型本身而不是 Codex 这个工具。Codex 的调度框架很强但模型如果指令遵循能力一般它可能改错文件或者理解偏需求。所以别指望“Codex 廉价模型 免费版官方 Codex”合理预期是“80% 的日常场景能覆盖复杂架构设计还得回到强模型”。第二要分清聊天补全协议和 Responses 协议的区别这是绝大多数报错的根源后面专门讲。简单说就是 Codex 默认说话的方式很多国产模型还没完全接住。第三API Key 别乱填、别写进配置文件。我在后面会给你一套安全的注入方式理论上 Key 泄露的损失可比省下的模型费大多了。2. 接入前的关键认知OpenAI 兼容 API 与两种请求协议2.1 /v1/responses 与 /v1/chat/completions 有什么区别很多人在对接时卡住报错信息五花八门什么 “404 Not Found”、“local proxy failed while handling codex endpoint /responses”本质都是同一个问题Codex 发出的请求路径目标模型服务的接口不认。OpenAI 目前有两套 API 协议。老的叫 Chat Completions路径是/v1/chat/completions几乎所有兼容 OpenAI 接口的第三方厂商都实现了这个。新的叫 Responses API路径是/v1/responses它是 OpenAI 为了 Agent 场景重新设计的一套接口把多轮对话、工具调用、推理过程都合并到一个更统一的响应结构里。Codex 作为 OpenAI 亲儿子新版默认走的是/v1/responses。问题就在这国内模型厂商的兼容层绝大多数只实现了老的/v1/chat/completionsResponses API 要么没做要么做得不完整。你拿 Codex 默认配置去请求国产模型请求到了/v1/responses对方根本不知道这是什么自然报错。打个比方你用普通话跟只会方言的人打电话电话打通了但对面听不懂你在说什么——不是网络问题是语言不通。解决办法不是去找信号更好的地方而是让 Codex 改成说对方听得懂的话也就是把请求协议从 responses 切回 chat completions。Codex 在自定义供应商配置里提供了一个字段叫wire_api设成chat就是告诉 Codex“跟这个供应商说话的时候请用老协议。”2.2 config.toml 到底配什么Codex 自定义供应商的完整字段解读Codex 的配置文件在~/.codex/config.toml自定义模型供应商的语法如下model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat逐行给你说人话。model是默认模型名model_provider指向下面定义的那套供应商配置。[model_providers.deepseek]的表头定义了这个供应商的名字你可以叫它任意名字只要和model_provider对上就行。base_url是 API 的根地址一定要包含/v1之类的路径前缀不同厂商的路径规则我后面列个对照表。env_key告诉 Codex “去哪个环境变量里找 API Key”这样配置文件里就不会出现明文密钥。wire_api是前面说的协议开关填chat走老协议不填默认走 Responses 协议国产模型基本都得填 chat。除了这几个基础字段高阶玩法里还可以往 provider 里加超时控制和重试次数[model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat timeout 120 request_max_retries 3timeout设大一点很重要国产模型在推理复杂问题时响应时间可能比较长默认超时时间容易误杀慢请求。这几行配置就是从“能跑”到“跑得稳”的差距。2.3 API Key 的注入姿势不把密钥写死在配置里接第三方 API 就必须用自己的 Key。常见错误是直接把 Key 填到config.toml里我见过有教程真这么写这是把密钥往火坑里推。配置文件可能被同步到网盘、上传到 GitHub、或者被截图发群里一旦泄露对方能拿着你的 Key 无限刷费。正确姿势是用环境变量。以 DeepSeek 为例在终端里执行export DEEPSEEK_API_KEYsk-你的key然后在config.toml里通过env_key DEEPSEEK_API_KEY引用。Codex 启动时会自动从环境变量里取值发请求配置文件和日志里都不会出现 Key。如果同时配了好几家供应商每家设不同的环境变量名互不干扰。这里有个小细节有坑官方 provider 默认读的是OPENAI_API_KEY但自定义 provider 用自定义名字就行不需要去污染全局的 OpenAI 变量。你要是在同一个终端里既有官方 Key 又有第三方 Key建议按厂商拆开免得切换 model_provider 时 Key 串了。3. 实战五步把 Codex 接到 DeepSeek3.1 第一步装好 Codex CLI 并确认版本如果你已经装了 Codex可以跳过这步。没装的话最省事的方式是通过 npm 全局安装npm install -g openai/codexmacOS 上也可以用 Homebrewbrew install codexWindows 用户建议装 WSL2然后在 Linux 环境里跑 npm 安装体验会顺畅很多。装完执行codex --version确认版本号正常。注意 Codex 版本迭代很快新版本对自定义供应商的支持比旧版完善如果版本过老建议先升级再排查兼容问题。首次运行codex会引导登录这一步很多人会卡住。如果你绑定的是第三方供应商不需要登录官方账号去拿授权直接配好下面的 config.toml然后按终端提示选择跳过登录流程即可。不同版本界面文字略有差异但核心逻辑一样它能用自定义 provider 就不强求官方登录态。3.2 第二步拿到 API Key 和接口地址去 DeepSeek 开放平台注册并创建 API Key创建成功后平台会给你一串以sk-开头的字符串。同时你需要记下这份配置API Base URLhttps://api.deepseek.com/v1Chat 模型名deepseek-chatReasoner 模型名deepseek-reasoner把 Key 写入环境变量。我用的是 zsh所以编辑~/.zshrc加入一行export DEEPSEEK_API_KEYsk-xxxxxx然后source ~/.zshrc让配置生效。用 bash 的朋友对应改~/.bashrc道理一样。3.3 第三步改写 config.toml完整配置样板现在打开~/.codex/config.toml把我上面给过的配置整段写入。我直接贴一份我当前在用的完整版本你复制改改就能用model deepseek-chat model_provider deepseek [model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com/v1 env_key DEEPSEEK_API_KEY wire_api chat timeout 120 request_max_retries 3写完保存。这里有个细节如果你之前已经配置过官方登录账号config.toml 里可能还有别的配置块别删掉那些内容只需要把最顶层的model和model_provider指到 DeepSeek 即可。Codex 的优先级是命令行参数里的--model选项 配置文件里的model字段。想临时切换模型可以在运行时用codex --model deepseek-chat不用改文件。3.4 第四步先跑一个最小对话验证配置完不要直接上复杂任务先用最简单的方式确认链路通了。在项目目录下执行codex exec 简单介绍一下这个项目不超过50字如果配置正确Codex 会读取当前项目文件并调用 DeepSeek 生成回答。正常返回说明整条链路已经打通。如果看到401或authentication相关报错多半是环境变量没生效重新检查echo $DEEPSEEK_API_KEY能不能打印出 Key。链路通了之后再试一个有实际操作的任务比如让 Codex 帮你加个函数、修一个明确的 bug。我第一次跑通后直接让它帮我重构一个模块DeepSeek 的表现超出预期代码风格和修改逻辑都比较靠谱。需要留意的是第一轮任务可能比较慢因为模型要先把项目结构读一遍几百行的上下文都在走输入 token别因为响应慢就以为卡死了。3.5 第五步把推理模型也接进去DeepSeek 除了便宜的deepseek-chat还有个推理模型deepseek-reasoner。它的推理过程会显式生成思考链适合处理算法题、逻辑推理、复杂 bug 定位。使用方式同样在 config.toml 里加一套供应商配置或者直接运行时指定codex exec --model deepseek-reasoner 分析这段代码为什么内存泄漏给出修复方案实际用下来reasoner 的模式明显更“较真”它会先分析各种可能原因再动手改但响应时间也更长、token 消耗更大。建议把 chat 设为默认reasoner 留给疑难杂症这样既控制成本又不耽误深度排查。跑通之后我再补一句如果 ceres 因为未知原因没有按预期调用工具可以打开调试日志看细节。命令行加--debug参数会输出完整请求日志能清楚看到 Codex 发了什么协议、走到了哪个 URL、目标模型返回了什么。这是排查一切对接问题的第一把钥匙。4. 一表通用通义千问 / 智谱 / Kimi / 豆包的接入参数4.1 各家 API 参数对照表一个人手里往往不止一家模型 API。我经常根据任务类型换着用所以把主流国产模型的接入参数整理了一份对照表。直接照着填 config.toml 就行供应商Base URLChat 模型名上下文备注DeepSeekhttps://api.deepseek.com/v1deepseek-chat64K性价比首选阿里云百炼https://dashscope.aliyuncs.com/compatible-mode/v1qwen-plus/qwen3-coder128K上下文大户长任务友好智谱https://open.bigmodel.cn/api/paas/v4/glm-4-plus128K有免费档测试额度Moonshot Kimihttps://api.moonshot.cn/v1moonshot-v1-32k32K/128K长文本分析强火山方舟豆包https://ark.cn-beijing.volces.com/api/v3需填推理接入点 ID视接入点而定要先创建接入点4.2 不同模型的接入注意点阿里云百炼稍微特殊一点。它的 OpenAI 兼容地址用的是 DashScope 的 compatible-mode 路径模型名也比较多样化。如果你想要一个专门写代码的模型可以试qwen3-coder如果只是通用对话和轻量修改qwen-plus就够。百炼平台还支持把 Key 配在环境变量里官方推荐变量名是DASHSCOPE_API_KEY但你在 Codex 里可以自定义成任何名字通过env_key指过去就行。智谱要注意它的兼容地址路径是/api/paas/v4/末尾带斜杠别漏了。glm-4-plus是付费模型但智谱也有免费档的glm-4-flash适合先跑通流程再升级。免费档的稳定性一般做简单任务还好长时间跑 Agent 任务建议还是用付费型号。Kimi 那边需要注意模型名的上下文版本。moonshot-v1-32k和moonshot-v1-128k是两套不一样的东西上下文上限差 4 倍。Codex 会把项目文件都塞进上下文如果你要处理大仓库直接选 128K 版本别为了省那点钱选 32K最后截断了还得重跑浪费时间。豆包火山方舟是最繁琐的。它不是直接填模型名而是要在控制台创建一个“推理接入点”会生成一个endpoint-xxx的 ID你得把这个 ID 填到模型名位置。如果你是火山生态的重度用户可以折腾否则我建议先用前三家体验差距不大但省心很多。5. 用 CC Switch 做多模型切换别再手改配置了5.1 CC Switch 是干什么的和 Codex 怎么配合CC Switch 是一个开源的 API 供应商管理工具最初是给桌面端聊天客户端做“一键切换模型厂商”用的。它的思路很简单你在界面上把多家厂商的 API Key 全部填进去然后启动一个本地代理服务所有请求发到一个固定的本地地址由 CC Switch 根据你的选择转发到真实厂商。这个思路放到 Codex 上正好合适。原本的痛点是每次想换模型都要打开~/.codex/config.toml改 model_provider、改 base_url、改 env_key来回折腾。有了 CC Switch 之后Codex 的 config.toml 里只需要指向本地代理地址你在 CC Switch 界面上点一下切换按钮就完成了厂商切换Codex 那边完全不用动。实际价值还体现在团队协作场景多个开发者共享一套 Codex 配置但每个人手里有不同的 API KeyCC Switch 里各自填自己的 Key 就行config.toml 可以保持一致。这在多人协作时能省掉很多沟通成本。5.2 配置步骤半小时搭一个多模型入口第一步安装 CC Switch。它在 GitHub 上发布了各平台的安装包macOS 和 Windows 都有现成的下载安装即可。第二步在 CC Switch 里添加供应商。进入设置添加一个 DeepSeek 供应商名字随意填上你的 API Key 和官方 API 地址https://api.deepseek.com/v1。再添加一个阿里云百炼供应商填https://dashscope.aliyuncs.com/compatible-mode/v1以及对应的 Key。第三步启用 CC Switch 的本地服务模式。正常情况下它会在127.0.0.1某个端口上开一个本地 API 服务端口号会在界面上显示比如http://127.0.0.1:15600/v1。这个地址就是给 Codex 用的。第四步修改 Codex 的 config.toml把 base_url 指向本地代理model deepseek-chat model_provider local-proxy [model_providers.local-proxy] name CC Switch Local base_url http://127.0.0.1:15600/v1 env_key DEEPSEEK_API_KEY wire_api chat注意这里env_key其实就是个占位性质的东西因为本地代理不校验 Key 是否真实真正的 Key 校验在 CC Switch 转发时发生。你可以填任意非空环境变量名或者干脆在 CC Switch 里配置成不需要 Key。但wire_api chat这一段不能省原因在下一节。第五步验证。在 CC Switch 界面切到 DeepSeek然后在终端跑一个codex exec小任务确认能正常返回。再把界面切到阿里百炼同样的任务再来一次确认切换生效。到这一步你就有了一个图形化切换的多模型 Codex 环境。5.3 高频报错实录local proxy failed while handling codex endpoint /responses这串报错我是在配置过程中真实撞上的完整信息类似 “cc switch local proxy failed while handling codex endpoint /responses. provide...”。第一次看到这个错的人大概率以为本地代理挂了或者网络不通但真相不在那一层。拆解这串报错local proxy failed说的是本地代理在处理请求时遇到了上游错误while handling codex endpoint /responses是关键词说明 Codex 发出的请求打到了/responses这个路径。结合前面讲的协议知识你就明白了Codex 在用 Responses 协议请求本地代理CC Switch 把这个请求转发给上游厂商时上游厂商不支持/responses接口于是返回来一个错误CC Switch 只能原样抛给 Codex。换句话说这是协议不匹配和网络、代理本身都没关系。解决方案是把 Codex 侧请求强制改成/chat/completions也就是 config.toml 里那个wire_api chat字段。加上之后Codex 发给本地代理的就是/chat/completions本地代理再转发给上游路径完全匹配问题消失。我把这个排查过程单独拎出来写是因为它是“Codex 第三方模型 本地代理”场景下最高频的坑。以后再看到任何包含 “endpoint /responses” 的报错第一反应不应该是我网络怎么了而应该是我协议是不是没对齐。6. 实战中的坑与排查清单6.1 高频报错速查表报错特征真正的坑解决办法404/endpoint /responses not found请求协议不被上游支持在 provider 配置里加wire_api chat401 authentication failedAPI Key 没注入或填错检查环境变量名、Key 前缀、是否多空格model_not_found模型名写错或没创建推理接入点对照厂商文档逐字核对模型名timeout/request timed out模型推理慢默认超时不够调大timeout比如 120 秒context length exceeded项目文件太多超出模型上下文换更大上下文模型或拆分任务让 Codex 局部读取local proxy failed while handling ...协议不匹配常见于本地代理场景确认 Codex 端wire_api chat并确认代理正常转发6.2 三个小技巧帮你省钱又省心第一个技巧给推理模型单独设置更小的model_reasoning_effort。现在很多推理模型支持调节思考强度Codex 的 provider 配置里也能指定推理强度级别。当你只是让 Codex 做个简单排列、改个变量名时没必要让模型深度思考半天把强度调低一档token 消耗和响应时间都能降下来。具体字段名在不同版本里略有差异可以在配置里查一下model_reasoning_effort相关说明。第二个技巧注意查看每次任务的 token 消耗。Codex 默认不会主动汇报 token 数但通过调试日志能拿到。在命令后面加--debug跑一次日志里会有 token usage 记录。了解每个任务大概吃多少 token你才能判断当前模型的选择是否合理。我实测过一个标准功能开发任务大致为一个中大型项目中新增一个模块整个 Agent 会话约消耗 200 万输入 token 和 20 万输出 token。这个量级不是 ChatGPT 聊几句能比的所以模型单价哪怕差几块钱折算到单次任务都是很大的差距。第三个技巧为复杂任务拆分 prompt。Codex 在 Agent 模式下一次会尽量理解全局但项目特别大时它会把大量上下文塞给模型既花钱又容易出现理解偏差。这时候你可以明确告诉它“不要扫描整个仓库只看 src/foo 目录相关文件”或者“先读 README 和 package.json不要打开其他文件”。通过 prompt 控制 Codex 的扫描范围是降低 token 消耗最直接的方式效果比换模型还明显。6.3 一周实测成本差了一个数量级我连续一周主力用 DeepSeek 跑 Codex任务内容包括给一个 Node 项目加接口、修测试、重构两个模块、写几段 SQL 脚本。每天大概跑 3 到 4 个小时的 Agent 会话。最后统计一周的账单全部模型的 API 费用折算人民币总共不到三十块钱。同样的任务量如果跑官方默认模型按美元计费我只能说至少是几十倍以上的差距而且还不一定更聪明。这不是说 DeepSeek 能完全平替官方模型。复杂架构设计、跨系统的深层推理官方模型确实更强。但日常“改代码、写测试、查 bug”这些占了编程工作 80% 的场景DeepSeek 的完成度已经足够好。把主力日常切到国产模型把真正高难度的任务留下用强模型这才是性价比最高的使用姿势。我个人的体会是Codex 接国产模型这件事最难的不是安装也不是写配置而是搞清楚协议层发生了什么。以后再遇到各种怪异的报错先问自己三个问题请求走到了哪个 URL、用的什么协议、目标厂商支持什么协议。把这条主线抓住剩下的事都是查表填参数而已。最后再分享一个小技巧多套配置可以用CODEX_HOME环境变量指向不同目录一个目录放日常便宜模型一个目录放强推理模型想用哪套就切哪套比反复编辑一个文件省心得多。