Codex接入国内低成本大模型：三行配置告别天价API账单

最近一段时间，我几乎把日常的代码修复、小需求开发都交给了 Codex 这类终端编码智能体。用多了之后，账单就成了最大的痛点——尤其是你一天要发起几十个任务的时候。于是我把 Codex 接到了国内低成本大模型上，折腾完发现：三行配置就能切换后端，费用直接降了一个数量级，工具调用和代码修改的完成度还比我预期的高。这篇文章就把我接入的完整过程、配置细节、实际跑任务的效果，以及踩过的一堆坑，全部整理出来。

如果你也正在用或准备用 Codex 这类工具，想省点 API 费用，或者想给自己找个便宜的后端来跑批量代码任务，那这篇应该对你有用。我会以当前最具代表性的低成本模型为例讲原理和步骤，不想用同一家也没关系，配置逻辑完全一样，换掉 Base URL 和模型名就行。

1. 为什么要把 Codex 接到国内模型上

1.1 Codex 是什么，它对模型后端有什么要求

Codex 是现在热度很高的终端 AI 编码代理：你给它一句自然语言指令，它会自己去读项目文件、分析代码、规划修改方案，然后调用终端命令执行任务，最后把结果反馈给你。它和那种只会生成一段代码的 AI 不一样，它会做真正的工程操作——改文件、跑测试、看报错、再改，形成一个完整的自动化循环。底层原理并不复杂，本质是一个 Agent 循环：模型不仅要会写代码，还要能理解工具返回的结果，并决定下一步调用哪个工具。

Codex 默认情况下只连官方自己的推理服务，这意味着每次使用都要按官方 API 计费。对个人开发者和中小团队来说，成本是比较明显的问题：写个脚本、修个 bug、重构一个函数，跑下来动辄几十轮模型调用，每一轮都要把上下文重新传给模型，token 消耗量比普通聊天大得多。我自己统计过几次，一次中等规模的任务，上下文 token 经常冲到几十万甚至上百万。

那能不能不用官方后端？Codex 的架构其实是开放的：它通过 OpenAI 兼容协议与模型服务通信，支持在配置文件里指定任何实现了同样协议的 API 服务。这就给了我们一个很好的切入点。你不需要魔改代码，不用自己编译，只需要改一下配置文件，把默认模型换成一个便宜模型，剩下的事情 Codex 自己会搞定。这比我一开始预想的要简单得多。

1.2 切换后能获得什么收益

把模型后端从官方模型切换成国内低成本模型之后，最直观的变化当然是费用。国内主流大模型的 API 价格，普遍比官方模型便宜一个数量级甚至更多。有些模型在缓存命中的情况下，百万 token 的输入只需要一两块钱；即便是常规输入，也远低于官方模型的单位定价。对于一天要跑几十个任务的场景，这个差价会非常可观。

除了费用，还有账号和结算上的便利：国内模型的 API 注册门槛低，主流支付渠道都能完成充值，对以国内业务为主的个人和团队来说确实省事很多。很多平台还提供免费额度，适合先用小项目验证效果。当然不同厂商的定价策略经常调整，我只说结论：哪怕按最贵的档位算，也比官方模型便宜得多。这种差距已经不是“打个折”的级别，而是直接影响你是不是舍得把 Codex 当成日常主力工具来用。

1.3 选模型时要盯住的四个能力点

不是随便接一个便宜的模型就能获得同样体验。我测试过好几家的低价模型，筛选下来有几个能力点必须关注。

第一是工具调用是否稳定。Codex 的 Agent 循环完全依赖函数调用能力，模型要能正确输出 tool_calls，并且在收到工具返回结果后继续分析。如果模型在这种场景下经常“精神分裂”，一会儿输出一段正常 JSON，一会儿又输出一段废话，整个任务就会卡住。

第二是上下文窗口长度。Agent 循环的上下文消耗远超普通聊天。一个半小时的任务积累几十轮对话，加上代码文件内容和工具输出，很容易超过 32K。目前国产主流模型的上下文基本都在 64K 以上，选的时候尽量选更长、支持自动按量计费的。

第三是并发与速率限制。Codex 一次任务里经常出现多个连续请求，如果模型服务限流很严格，任务就会被频繁打断。我实际体验是：那些同时提供标准 OpenAI 兼容模式的厂商，整体限流策略做得更完善，跑长任务更稳。

第四是 API 兼容性细节。大部分国内模型都提供 OpenAI 兼容模式，但兼容程度有差异。接入时重点看它是否支持工具调用、是否支持流式输出、是否支持系统消息。这三个支持不好，Agent 类应用基本没法跑。

我做了个粗略对比，参数以各厂商官方文档为准：

当时我最终选定的方案，就是表格里工具调用最稳定、费用最低的那一档：某主办方提供的 deepseek-chat 模型。如果不想用这一家，按照同样的配置逻辑替换其他厂商即可，后面的所有步骤都可以复用。

2. 接入前准备：API密钥与兼容端点

2.1 注册并开通 API 服务

这一步没什么技术含量，但有几个小坑值得提前说。去对应平台的开放平台注册账号，完成实名认证（大多数国内模型平台有这个要求），然后创建一个 API Key。创建的时候会把 Key 明文显示一次，务必复制保存好。我一般会建一个独立的 Key 给 Codex 用，这样万一 Key 泄露，可以单独吊销，不影响其他业务。

充值这块，我建议先充个十块二十块试试。不要一上来充太多，因为你还不确定你选的那个模型在 Agent 场景里的表现是否让你满意。等跑通一个完整任务，确认好用再追加预算。另外很多平台会把免费额度和付费额度分开，新人一般都有一些体验额度，但免费额度的速率限制通常更低，跑 Agent 任务可能比较容易触发限流，所以不要过度依赖免费额度。

2.2 找对你的“兼容端点”和模型名称

接入 Codex 最关键的两个信息：Base URL 和模型名。每个模型服务商的文档里都会写清楚这两项。Base URL 就是 API 的根地址，Codex 会在它后面拼上具体的接口路径。模型名则是你调用时要传的特定标识，例如有的叫 deepseek-chat，有的叫 qwen-plus，有的叫 glm-4-flash。注意别把“开发者平台控制台上展示的产品名”当成 API 模型名，这两者不一定一样。

常见平台的兼容信息参考如下：

如果你拿到的 Base URL 以 /v1 结尾，通常是正确的。Codex 内部对 Chat Completions 兼容接口的调用路径是 base_url + /chat/completions，所以 base_url 里不要带 /chat/completions，否则路径会变成重复拼接，最后返回 404。

2.3 把 API Key 放到环境变量里

配置里用环境变量承载 API Key 是最稳妥的，避免把密钥明文写进 config 文件。以 bash/zsh 为例，可以在 ~/.bashrc 或 ~/.zshrc 里加一行：

export DEEPSEEK_API_KEY="你的key"

然后 source 一下当前终端：

source ~/.bashrc

这样配置文件的 env_key 字段指向 DEEPSEEK_API_KEY 时，Codex 会自动从环境里取。如果你用的不是 bash/zsh，而是 fish、Windows 终端或者 WSL，原理都一样，只是设置环境变量的方式略有差异。实际跑 Codex 建议在 macOS/Linux 环境下，体验更顺。

3. 核心配置：让 Codex CLI 指向国内模型

3.1 配置文件位置与结构

Codex CLI 使用 TOML 格式的配置文件。全局配置在用户目录下的 ~/.codex/config.toml，你也可以在每个项目根目录放一个 .codex/config.toml 做项目级覆盖。底层逻辑就是：项目配置优先于全局配置，适合不同项目路由到不同模型。

我个人习惯是在全局配置里写好默认 provider，然后在个别项目里覆盖 model 字段切到更适合该项目的模型。比如某个项目代码库特别大，需要更长的上下文，那就在项目级的 .codex/config.toml 里单独指定一个长上下文模型，其他项目不用动。这个灵活度是 Codex 做得比较舒服的地方。

3.2 三行核心配置详解

下面是我实际在用的全局配置片段：

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"

逐段拆解一下：

这里有个值得说清楚的细节：Codex 原生用的是 Responses 协议，而国内模型基本不提供 Responses 接口，所以必须把 wire_api 设成 chat。如果你不设置这个字段，Codex 默认按官方协议的格式发送请求，很可能直接 400。我最初就把这个字段漏了，结果第一轮测试怎么调都不通，后来加上就好了。

3.3 验证连通性

配置改完，先跑一个简单任务验证：

codex exec "列出当前目录下的文件，并告诉我你使用的是什么模型后端"

如果一切正常，Codex 会先扫描目录，然后调用模型，最终在终端里返回结果。第一次运行时终端会提示某个模型不在已知列表，问你是否继续。这个提示是正常的，选择继续即可。Codex 的内置模型列表里不可能包含所有第三方模型，它只是提醒你“我不认识这个模型，但我会按兼容模式处理”。

我的经验是：第一次跑一个小任务，不要直接上大需求，先把链路打通。能正常返回模型答复，就说明配置没问题；如果看到 401、404、400 这类错误，直接看第 5 节的排查表。验证通过之后，你不需要再登录官方账号，因为 Codex 已经通过 provider 里的环境变量拿到了认证信息。

4. 实操复盘：让 Codex 跑真实代码任务

4.1 完整任务一：修复编码引起的中文乱码问题

我搭了一个模拟项目来演示：一个 Python 数据分析小仓库，里面有个脚本读取 CSV 文件时没有指定编码，结果在某些环境下读 GBK 编码的文件出现乱码。这个场景很常见，也适合展示 Codex 的完整闭环。

codex exec "修复 data_loader.py 在读取 GBK 编码 CSV 时中文乱码的问题，并在修复后运行现有测试确认结果" --dangerously-skip-permissions

我这个命令加上了跳过权限确认的参数，因为只是想让它自动执行终端命令。在实际项目里，我更推荐不要加这个参数，让 Codex 每执行一步都向你确认，更安全。尤其是在你还不熟悉它会执行哪些命令之前，别上来就给它完全自由的执行权。

Codex 的处理流程大致分四步：先读了 data_loader.py 和相关测试文件，然后在计划里说明要在打开文件时显式传 encoding 参数并动态探测编码，接着修改代码，最后运行测试。关键是我看到它在测试失败后会自动读入错误日志重新分析，而不是把问题抛回给我。这个自我校验循环在常规工具里很难得。它甚至会自己打开报错文件确认修改位置有没有对错行号，这已经接近一个初级工程师的做事方式了。

4.2 完整任务二：生成单元测试并执行

第二个任务是让 Codex 给一个计算器模块写单元测试：

codex exec "给 calculator.py 中的除法函数补齐边界场景的单元测试，并执行测试确保通过"

Codex 会先看 calculator.py 里有哪些函数、参数是什么、有没有依赖，然后生成 test_calculator.py，接着运行。第一次跑可能测试不通过，比如 Mock 方式不对、边界值写错，它会读 pytest 的报错并自己改。我观察到整个迭代过程大概三四轮，最终测试全部通过。

这里有个细节：Codex 会把测试文件放在项目里的什么位置、用什么命名风格，取决于它读取到的项目结构。如果你的仓库里已经有 tests 目录，它会先看已有测试文件的写法，然后尽量保持一致。这个“模仿项目风格”的能力不是模型单独决定的，而是 codex 在调用前会把相关文件塞进上下文给模型看，所以模型的风格一致性表现比单纯聊天生成代码要好很多。

对于“低成本模型会不会写代码不行”的疑虑，这算一个很好的回击：只要模型的工具调用稳定、上下文能装下项目结构，完成这类中等复杂度任务是没问题的。当然你要说它写出来的逻辑有没有隐患，那肯定需要你审查，但对于“补测试、改 bug、加功能”这类有明显验收标准的任务，效果是够用的。

4.3 完整任务三：从零实现一个小功能

我有时也会拿它处理一些“不想自己动手但简单明确”的需求，比如给某个脚本增加一个“输出 JSON 格式的报告”的子命令。这种任务和前面两个的区别在于，它涉及在现有代码里新增文件、接入入口、更新帮助信息，改动点更多。Codex 也能一次完成，只是中间会多几次“看目录结构、改入口、跑冒烟”的迭代。

这类任务我强烈建议在交互模式下跑，不要用 exec 一次性执行完。因为在交互模式里，你能看到它每一步做了什么，中途发现问题可以直接打断纠正。比如它准备新增的依赖版本不对，你直接说“不要引入新依赖，用标准库实现”，它就立刻换方案。这种“对话式纠偏”的能力是 exec 批量模式不具备的，也是 Codex 结合便宜模型使用时的最佳姿势——反正 token 便宜，多聊几轮也不心疼。

4.4 一个成本账单样例

我给自己的一次完整修复任务粗略列了笔账：中等复杂度、约 40 轮工具调用，整体 token 消耗在几十万到百万级。按我选的国内模型计价，约合人民币几块钱；同一任务如果走官方默认模型，按官方 API 价格算能到几十上百块。一天跑二三十个这样的小任务，一个月成本差异相当可观。

这也是我认为这个方案值得折腾的根本原因。以前我用官方模型的时候，每次跑长任务都忍不住盯一眼令牌消耗，生怕超预算；切到国内低成本模型之后，基本可以无压力地让它随便跑，把 Agent 的能力真正用起来。省下来的钱对个人开发者来说可能只是几杯奶茶，但对小团队来说，可能直接决定了这个工具能不能全员铺开。

5. 接入后常见的坑与排查方法

5.1 401/403 鉴权失败

表现是请求返回 401，Codex 报 invalid api key 或类似信息。解决思路按顺序来：先检查环境变量名和 config 里 env_key 是否一致；再看 API Key 是不是复制多了空格；最后确认平台账号是否实名认证、是否欠费。我的经验是，80% 的 401 都是环境变量没生效，改完环境变量一定要重新 source 一下再开终端。如果你在启动 Codex 之前已经开了终端，环境变量是旧的，这时候最容易产生“我明明配了怎么还是 401”的困惑。

还有一个小细节：有些平台生成的 Key 带有分隔符或类型前缀，复制时很容易只复制一部分。建议把 Key 放到一个纯文本编辑器里核对一遍，确认首尾完整。

5.2 base_url 拼接错误导致 404

Codex 会在 base_url 后面拼接口路径。如果你的 base_url 带了多余的 /chat/completions，就会出现 404。正确做法是只填根地址，例如 https://api.deepseek.com/v1，不要带后面的接口路径。另外注意使用平台文档里给的兼容模式地址，有些厂商同时有原生 API 和兼容模式 API，两者地址不一样，要选兼容模式那个。如果 404 响应里带了一个你不太认识的文案，大概率是地址选错了，去文档里重新搜一下“兼容”“OpenAI”这些关键词。

5.3 模型名不在已知列表的黄色警告

第三方模型肯定不在 Codex 的内置模型列表里。第一次运行会有黄色提示“模型某某不在已知列表，假定它支持 Chat Completions API”，不用管它。只要你已经显式设置了 wire_api = "chat"，它就真按 Chat Completions 协议来跑。这个提示很多第一次接触的人会被唬住，以为哪里配置错了，其实这是设计好的兼容策略，完全不影响使用。

5.4 工具调用失败：模型不返回 tool_calls

这个问题相对麻烦。表现是任务执行到一半，模型开始输出大段纯文本而不是工具调用，或者输出了一段假的结构化内容。排查时我建议按这几条走：

• 换一个更稳的模型名，比如厂商的旗舰对话模型，而不是那种只适合简单对话的轻量模型；
• 把任务拆小，减少单轮需要并行调用多个工具的复杂度；
• 在 config 里限制最大输出 token，避免模型回答到一半被截断。Codex 配置里可以对特定模型设置输出上限，长任务尤其需要这个参数。模型如果输出到一半被强断，工具调用格式就会残缺，Codex 会一直卡在解析阶段。

5.5 请求参数不被接受导致 400

有些国内模型服务对额外参数非常严格，Codex 如果带了它不认识的字段，就会 400。遇到这种情况，先确认 wire_api 设置的是 chat。另外更新 Codex 到最新版本，因为新版对第三方兼容模式越做越好，通常能自动裁剪不支持的参数。我遇到过最典型的场景是模型名里带版本号，Codex 把版本号解析成特殊参数塞进请求，导致 400。这种时候完全绕开，换成不带版本号的别名，或者检查一下模型标识的写法。

5.6 限流导致任务中断

长任务最容易碰到限流。表现是运行一段时间后突然报 rate limit exceeded 或被强制断开。我的处理策略是：给 Codex 配置里调小单任务的最大输出步长，同时把大需求拆分成多个小任务。与其让一个任务跑 40 轮，不如拆成几个 10 轮左右的子任务逐个执行，既省钱又不容易触限。另外，遇到限流报错后不要立刻重试，稍微等几十秒，让服务端的限流窗口刷新，盲目重试只会加重限流并浪费自己的时间。

5.7 上下文过长导致模型“失忆”

Codex 长任务会把历史消息不断追加，后端的上下文一旦打满，模型可能会忘记前面的关键信息。这种问题不太好直接看报错，因为接口本身可能还是 200 状态，但模型返回内容质量明显下降，甚至重复执行已经做过的操作。我的建议：不要让单个任务无限膨胀。一个仓库的完整重构，尽量分步骤交办；每次交办时把需求描述清楚，别指望模型记住半小时前它自己说过的话。遇到“失忆”可以直接开一个新会话，把当前进度和下一步目标解释给它，比在旧会话里硬拉效果更好。

6. 我把这个方案用在真实项目里的心得体会

6.1 哪些场景最适合接入国内低成本模型

我最推荐的是这些场景：批量、简单明确、重复性高的编码任务，比如修 lint、补测试、改格式、增删配置、生成脚手架。这类任务代码量不大但很消耗时间，用便宜模型跑是最划算的。稍微复杂点的功能开发，只要你能用一段清晰的话把事情说明白，也值得试。代码审查也可以交给它，虽然深度审视不如人细，但漏掉空指针、漏处理边界值这类低级问题，它还是能挑出来的。

我用下来还有一个意外收获：因为不心疼 token，我变得更愿意让 Codex 多探索几轮，而不是巴不得一句指令就出结果。很多修改它第一次方案不是最优，但多聊两轮之后，它会把边界条件补全。这在以前用贵模型的时候是舍不得这样做的。

6.2 哪些场景不建议硬换后端

如果任务是超大型代码库的重构、跨模块架构设计、非常复杂的系统性调试，我不建议用低成本通用对话模型硬扛。这类任务对模型的推理深度要求很高，有时贵模型多算一步就把问题解决了，便宜模型可能要无效迭代很多轮，最终费用和时间反而不划算。我现在的策略是“混用”：日常小活走低成本模型，遇到真正难啃的骨头，单独把个别任务切回官方模型。配置文件里加两个 provider，随时切换，并不麻烦。

另外要注意：低成本模型在“执行权限越权”方面的警惕性不如大厂模型，偶尔会执行一些比较危险的命令。我在本地沙箱里试过让它清理临时文件，它直接建议 rm -rf 一个目录，虽然目标目录是我临时建的，但你如果在一个正经仓库里跑，遇到这种操作一定要看清楚再放行。所以越是在能自动执行命令的 Agent 场景里，越要保留权限确认环节。

6.3 后续可以继续优化的方向

这个方案还有很多可以玩的地方。比如给 Codex 配置项目级的 AGENTS.md，让它在每次任务前先读项目规范，减少无效改动；再比如维护两份 provider 配置，通过环境变量或项目配置快速切换模型；还可以结合 CI，把 codex exec 接进自动化流水线，让它在每次提交后自动补测试或修格式。我现在已经在两个仓库里放了 AGENTS.md，内容就是编码风格和禁止事项，Codex 违规操作的次数明显下降。

还有个思路是模型路由：把简单任务固定跑最便宜的对话模型，把推理题切成独立任务去跑支持长思维链的模型。这样整体账单结构会更合理。因为我实际使用中发现，不是每个任务都需要旗舰推理能力，但所有任务都需要工具调用稳定。所以我的排序是：先保证工具调用合格，再谈便宜，最后才谈推理上限。

就我自己最近的体感来看，把 Codex 接到国内低成本大模型这件事，不只是省钱，更是把“让 AI 帮我改代码”从偶尔尝鲜变成日常习惯的那一步。算完账之后，你可以完全不用在意单次任务的 token 消耗，放心地和它多轮往复，把 Agent 的能力真正用起来。趁现在各家 API 价格都在卷，早点把自己的工具链切过去，体验一下批量跑任务也不心疼账单的感觉。