把 Codex 接到 DeepSeek、Mimo 这类第三方模型上最近问的人实在太多了。Codex 本身是 OpenAI 出的命令行编程助手默认绑定官方模型但第三方模型的性价比和国产模型的本地化能力确实香所以大家纷纷开始折腾怎么“换芯”。这篇就把我从零配置到跑通再到被各种报错折磨的完整过程写清楚顺便把踩过的坑、查过的资料、最后怎么解决的一并整理出来。适合两类人一是刚开始用 Codex、想省点 API 费用的朋友二是已经在用官方模型、想多一个模型可选的老手。不保证每个版本都一模一样但思路和排查路径是通用的。1. 为什么要把 Codex 接到第三方模型以及方案选型的底层逻辑1.1 Codex 默认模型和第三方模型的本质区别Codex CLI 本质上是一个“壳”它负责把你终端里的自然语言指令组装成标准 API 请求然后发给模型服务端再把模型的回复解析成可执行命令或者代码补全。默认情况下它只会往 OpenAI 的官方接口发请求用gpt-5、o3之类闭源模型。但 Codex CLI 的配置文件里预留了model_provider这个扩展点允许你自定义一个兼容的 API 端点。这就是“接入第三方模型”的根基。第三方模型如 DeepSeek 走的是 OpenAI 兼容接口也就是说很多请求格式可以直接复用。Mimo 呢是另外一家提供模型服务的厂商也有自己的 API但兼容性上会有一些差异。实际配置时你并不是在改 Codex 的代码而是告诉它“你别默认去 openai.com 了去这个地址找模型”然后把对应的模型名、密钥、请求协议配好。1.2 接入前先想清楚三个问题很多新手一上来就找配置文件改完发现疯狂报错然后来回折腾。我在接入前先想了三件事强烈建议你也先想清楚。第一是成本。官方模型的按量价格不低尤其你每天要跑上百个任务的时候。DeepSeek 的 API 定价比官方低一个量级Mimo 也有自己的定价体系。但便宜不代表没成本你得看自己的并发量和 token 消耗粗略估算一下。我自己的经验是如果只是写脚本、改 bug、补测试DeepSeek 完全够用月度费用能省一大截。第二是能力。Codex 的任务往往需要很强的代码生成和多轮工具调用能力。官方模型在指令遵循和复杂上下文理解上确实强但 DeepSeek 在代码类任务上的表现也很能打尤其deepseek-chat和deepseek-reasoner各有侧重。Mimo 的优势我后面细说但你要先明确自己的主要使用场景而不是盲目更替模型。第三是兼容性。Codex 默认使用responses这种较新的 API 协议而很多第三方模型只实现了chat/completions协议。这就需要在配置里强制指定wire_api chat或做一层转换否则会一直报 404 或者请求格式错误。兼容性这块是配置里最大的坑也是后面所有报错的根源。1.3 主流的接入方式改配置还是用代理工具接入方式目前主流有三种。第一种是直接改 Codex 的config.toml在model_providers里新增一个 provider然后指定base_url、env_key、wire_api。这种方式最干净没有额外进程也是官方推荐的扩展方式。改完之后你在启动 Codex 时用--model和--model-provider参数指定就行。第二种是用cc-switch这类图形化或命令行切换工具。它本质上是帮你维护多份配置文件在多个 provider 之间快速切换。好处是省得手改配置坏处是多了一层代理逻辑如果你不太清楚它的转发机制就会遇到文章标题里那个cc switch local proxy failed的报错。这个我后面专门讲。第三种是自建一个兼容代理层比如把 OpenAI 请求转换成第三方模型的请求再转发。这种适合企业级统一管理个人用有点杀鸡用牛刀。我的建议很直接个人电脑上老老实实用第一种。先把原生配置跑通再去尝试工具否则报错你都不知道是 Codex 的问题、模型的问题还是代理工具的问题。2. 接入 DeepSeek / Mimo 的完整配置步骤2.1 准备工作安装 Codex CLI、获取 API Key这一步没什么难度但很多人会卡在“Codex 官方下载后Windows 安装未完成”这类问题。如果你在 Windows 上安装建议直接用 npm 全局安装npm install -g openai/codex如果你还没有 Node.js 环境优先装 LTS 版本再把 npm 的全局 bin 目录加到 PATH 里。安装完成后先登录一次官方账号让 Codex 把默认的基础配置生成好后面我们就只改配置不动认证逻辑。然后去 DeepSeek 开放平台注册账号创建一个 API Key通常长这样sk-...。Mimo 同理去它的开发者后台拿到 Key。建议把 Key 存到系统环境变量里而不是直接写进配置文件比如 macOS/Linux 就编辑~/.zshrc或~/.bashrcexport DEEPSEEK_API_KEYsk-你的key export MIMO_API_KEYsk-你的mimo-keyWindows 上通过“系统属性 - 环境变量”添加同名环境变量。为什么强调环境变量因为配置文件有可能会被同步到网盘或者直接推到 GitHub硬编码 Key 容易泄露而且通过env_key读取环境变量是 Codex 推荐的做法。2.2 修改配置文件config.toml 的关键字段Codex 的配置文件位于~/.codex/config.tomlmacOS/Linux或%USERPROFILE%\.codex\config.tomlWindows。首次登录后会自动生成不需要从零写。我们要做的是追加自定义 provider 的配置块。以 DeepSeek 为例最简配置如下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默认使用的模型名DeepSeek 常用deepseek-chat通用对话和deepseek-reasoner推理增强。model_provider告诉 Codex 使用哪个 provider 块值要和下面[model_providers.xxx]里的xxx一致。base_url第三方 API 的根地址注意不要带/chat/completions这种具体路径Codex 会自动拼接。env_keyCodex 从环境变量里读取 API Key 的名称。wire_api请求协议DeepSeek 目前兼容的是chat也就是/chat/completions。配好后在终端里启动codex --model deepseek-chat --model-provider deepseek第一次请求会显示发给了https://api.deepseek.com/v1这就说明配置生效了。2.3 DeepSeek 的模型与参数推荐deepseek-chat是通用模型适合大多数代码任务响应速度快价格很便宜。deepseek-reasoner会在输出前先生成一段推理过程效果上更接近带思维链的强模型适合那种逻辑复杂、需要设计方案的编程任务但响应时间会明显变长。如果你希望 Codex 里默认使用 reasoner可以把配置改成model deepseek-reasoner我看不少人担心 DeepSeek 会不会把 Codex 的“自动执行命令”能力搞坏。试下来的结论是deepseek-chat在指令遵循上做得不错只要 Codex 的 system prompt 里把“不要解释直接给命令”这类约束写清楚它基本能正确返回 tool call。但偶尔也会出现代码补全时忘记返回结构化格式的情况所以我建议把 temperature 调低不过 Codex 配置中 temperature 并不支持直接对第三方 provider 暴露所以实际只能通过模型自身的默认参数控制。如果你是 API 直连方式可以在请求里加但配置 Codex 时一般不需要动。2.4 Mimo 的接入特别说明Mimo 的接入方式和 DeepSeek 类似但有个非常容易踩的点它的 API 兼容层只实现了chat/completions而且目前对图片输入支持不完整这也是为什么网上有人说“Mimo 模型不能传图片”。如果你在 Codex 里直接用多模态提图大概率会报错或忽略图片内容。所以如果你主要需要视觉理解能力Mimo 暂时不是好选择。Mimo 的 config.toml 参考[model_providers.mimo] name Mimo base_url https://api.mimo.ai/v1 env_key MIMO_API_KEY wire_api chat然后在启动时用codex --model mimo-7b --model-provider mimo具体模型名要以 Mimo 官方文档为准我这边用过的是它面向代码场景的 7B 模型在轻量任务上响应很快但面对长上下文多文件重构时能力还是不如 DeepSeek 的 V3 系列。所以我的建议是Mimo 适合做快速问答、脚本片段生成、格式转换这类轻任务DeepSeek 适合做项目级代码生成和错误排查官方模型则继续留给复杂架构设计。3. 实操过程中最常见的报错与排查思路3.1 cc switch local proxy failed while handling codex endpoint /responses 的解决这是我在网上被问得最多的一个报错也是标题里那个热门词。它发生在你用cc-switch这类工具切换到第三方模型后运行时出现cc switch local proxy failed while handling codex endpoint /responses紧接着 Codex 直接退出。根本原因是什么cc-switch在切换配置时并不是只改config.toml它还会启动一个本地代理服务Codex 的请求会被转发到这个代理再由代理转发到真正的第三方 API。如果代理服务没有启动或者代理监听的端口被占用或者 Codex 仍然以/responses的协议请求而代理不认这个协议就会出现上面的报错。我的排查路径先看ps aux | grep cc-switch确认代理进程是否活着。如果没起来手动启动它。查看config.toml里的base_url如果里面写着http://127.0.0.1:xxxx说明走的是本地代理这时候需要确认代理进程日志。如果代理正常但报错里仍然出现/responses说明wire_api没有切换到chat。cc-switch 有时候会保留原来的wire_api设置这是兼容性 bug。解决办法是手动进配置文件把wire_api改成chat。我自己遇到过一次最后发现是端口冲突代理启在了127.0.0.1:8899但 Codex 配置里还指向 8900。直接把配置改回与代理端口一致问题就消失了。如果你不想跟代理较劲干脆卸掉 cc-switch回归原生配置方式一劳永逸。3.2 401 / 403 鉴权失败这个问题比代理错误还普遍。报错信息通常是401 Unauthorized或403 Forbidden切换模型后马上冒出来。原因不外乎三种API Key 没有正确写入环境变量或者环境变量名和配置里的env_key不一致。比如配置文件里写的是DEEPSEEK_API_KEY但环境变量里叫DEEPSEEK_KEY自然鉴权失败。Key 本身过期或额度不足。很多平台的新用户有免费额度但额度用完后继续调 API 就会 403。请求头里 Authorization 格式问题。Codex 通常自动生成Bearer key但如果某些第三方要求key不带 Bearer也可能失败。不过这种情况很少优先检查前两个。我的排查口诀是“先环境后配置先手动后自动”。先在终端里echo $DEEPSEEK_API_KEY看看能不能打印出完整的 key然后写一个 curl 命令直接调用第三方接口curl https://api.deepseek.com/v1/models -H Authorization: Bearer $DEEPSEEK_API_KEY如果 curl 能返回模型列表说明 API Key 没问题那问题就出在 Codex 侧的配置。如果 curl 也 401就去平台后台查 key 状态。3.3 响应格式不兼容、tool call 解析异常当你成功连上 DeepSeek但 Codex 在生成回复后一直转圈或者提示“tool call parsing failed”这就不是网络问题了而是协议响应格式不兼容。Codex 的 tool call 机制要求模型返回标准的工具调用结构OpenAI 的/responses协议和/chat/completions协议在工具调用字段的格式上有区别。第三方模型通常都兼容/chat/completions但其中一些模型在返回tool_calls时可能会省略id或者把arguments传成字符串而不是 JSON 对象Codex 解析不到就会失败。这类问题很难通过 Codex 配置彻底解决因为它牵扯到模型输出格式。我能给的建议是优先选用模型商家的“OpenAI 兼容”模式而不是原生模式。DeepSeek 的兼容层做得比较完整一般不会出现 tool call 解析问题。如果问题反复出现可以让模型不用 tool call直接用纯文本输出代码再由 Codex 自己解析。但这个改动比较大不太推荐属于退路。换个模型名试试。DeepSeek 的deepseek-chat和deepseek-reasoner在 tool call 稳定性上表现不同有时候 chat 能过reasoner 就翻车。3.4 请求超时与并发限制第三方模型的响应速度和并发能力参差不齐。Mimo 的轻量模型响应快但并发能力可能有限DeepSeek 在高峰期也可能出现排队。你可能会看到request timed out或rate limit exceeded。处理思路是分级调节如果单次请求超时把模型切到响应更快的版本比如deepseek-chat而不是deepseek-reasoner。如果频繁限流可以考虑在 Codex 设置里把并发数调小哪怕每次只能串行跑也比报错强。Codex CLI 本身会管理并发但部分自定义 provider 无法识别限流配置所以更实际的做法是错峰使用。如果你是重度用户建议在config.toml里设置 http 请求的默认超时时间。不过 Codex 版本里这个字段不是所有版本都开放如果没有就换个思路用timeout命令包一层比如timeout 120 codex超时后自动终止任务。3.5 常见问题速查表我把上面所有问题整理成一张速查表方便你照着排查报错关键信息大概率原因快速解决动作cc switch local proxy failedcc-switch 代理未启动或端口不对改用原生配置或检查代理进程、端口401 UnauthorizedAPI Key 错误或未读取到核对环境变量名用 curl 验证 Key403 ForbiddenKey 无权限或额度耗尽去平台后台检查 key 状态和配额404 Not Foundbase_url 填错确认地址是否包含/v1或正确版本路径tool call parsing failed模型返回格式与 Codex 不兼容换兼容性更好的模型版本request timed out模型响应慢或网络问题换轻量模型、降低任务复杂度rate limit exceeded触发并发限制控制任务频率或使用离线时段这张表不是万能药但覆盖了我自己遇到过的 90% 的问题。剩下的 10% 多半是 Codex 版本更新带来的配置项变更这时候去官方 changelog 里搜关键词比重新发帖问人要快得多。4. 进阶玩法与调优建议4.1 让第三方模型在 Codex 里更好用调整系统提示词第三方模型对指令的理解能力不如官方强模型所以如果你发现 Codex 的回复风格“跑偏”可以在配置里加入自定义指令。比如在~/.codex/prompt目录下放一个agent.md把常用的约束写进去让 Codex 每次请求时都带上。我自己的agent.md长这样- 你是一个严谨的终端编程助手。 - 当你需要执行命令时直接输出命令不要附带解释除非我明确要求。 - 如果任务描述不够清晰先提问澄清不要猜。 - 处理代码时优先考虑可维护性变量名和函数名要语义化。 - 如果请求的内容涉及文件修改先列出改动点再执行。这个文件的作用是把它附加到系统级提示词里对第三方模型尤其重要。因为 DeepSeek 这类模型对 system prompt 的遵循度不如官方模型稳定你越是用明确的规则约束它它越不容易自由发挥。4.2 多模型切换的实际体验与场景选择我配置了三个 provider 混着用Codex 官方模型、DeepSeek、Mimo。实际操作下来切换模型确实能提升效率但前提是你知道每种模型的脾气。DeepSeek 的强项是代码补全和代码解释。比如“这段代码哪里可能溢出”“帮我写一个 python 脚本来合并日志文件”这类任务它做得又快又好错误率低而且 token 便宜可以放开用。Mimo 的强项是快速响应和轻量对话。我在做 git 操作、改配置文件、查基础语法时更倾向用它。它的代码能力确实不如 DeepSeek但优势是够快适合“刚刚有一个想法赶快验证一下”的场景。注意它不能传图片所以涉及截图、UI 还原、读图诊断这类任务必须切回 DeepSeek 或官方模型。官方模型我保留给两类场景一是“这个坑我查了半天查不出来”的疑难 bug二是需求本身都很模糊需要模型自己判断并推进的复杂任务。第三方模型在这类场景下容易一本正经地瞎说而官方模型会更容易说“我不知道”或者“需要更多信息”。4.3 多 provider 配置模板分享我目前的config.toml里保留了完整的 provider 定义方便随时切换。你可以直接参考# 默认使用 DeepSeek 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_providers.mimo] name Mimo base_url https://api.mimo.ai/v1 env_key MIMO_API_KEY wire_api chat # 官方 provider 保留不动可以随时切回 # [model_providers.openai] # name OpenAI # base_url https://api.openai.com/v1 # env_key OPENAI_API_KEY # wire_api responses切换时不用改文件直接用参数选择codex --model deepseek-chat --model-provider deepseek codex --model mimo-7b --model-provider mimo codex --model gpt-5 --model-provider openai如果你嫌麻烦可以写个简单的 shell alias把常用组合存起来。但我不太推荐再上一套代理工具原因前面说过了多一个中间层就多一份报错概率。4.4 从长期稳定性看 Codex 接入第三方模型的边界必须泼一盆冷水Codex 本身是为官方模型设计的第三方模型接入注定不是官方支持的一等公民。你会发现某些版本更新后原来能跑的配置突然报错了某些高端功能比如语义记忆、多模态输入、agent 模式下的深度规划第三方模型大概率支持不到位。所以我的心态是把接入第三方模型当成“省钱扩展方案”而不是“平替方案”。重要交付物、复杂架构设计、需要稳定复现的操作我会切回官方模型跑一遍日常的 CRUD、脚本修改、log 分析全部丢给 DeepSeek。Mimo 就当个快枪手用绝不安排重活。另外版本控制一定要做好。每次改config.toml之前先备份一份文件名像config.toml.bak这样。别嫌麻烦我有一次调 Mimo 参数把默认的官方 provider 不小心覆盖了结果想切回官方查了半天才发现配置没了那叫一个酸爽。最后再分享一个实操中总结的小习惯接入第三方模型其实是“戴着手套做手术”你能做到精准、快但不如光手灵活。我的习惯是新模型接到手先跑一遍“冒烟测试”大概 5 到 6 个固定问题——让模型写一个递归函数、解释一段回调嵌套、改进一个正则表达式、总结一个长函数的作用、生成一段 SQL。这几个问题基本能覆盖代码任务的常见形态。跑完就知道这个模型在 Codex 里的实际体验再决定要不要长期用。每次切模型都花不了三分钟但能帮你省下无数个被错误工具调用折磨的深夜。配置这条路没什么秘诀多试、多备份、认真读报错第三方模型也能做到很顺手。