最近 Codex 圈子里有个说法很扎心：Codex 最容易算漏的钱，藏在一句“继续”里。我一开始将信将疑，直到自己把几个不同任务场景完整跑下来，对着账单逐条核对了 usage 数据，才发现这句话一点不夸张。
Codex 是 OpenAI 推出的编程智能体，配套有命令行工具和编辑器插件。它按 token 计费，但很多人对它的计费模型有误解，以为“我发一条指令，它回一段代码，扣一次钱”。实际上 Codex 不是按“指令条数”收费，而是按“每一轮请求里携带了多少上下文”收费。真正吃钱的大头，往往不是那几次关键改动，而是你随手点下的“继续”背后，被反复发送的整段历史记忆。
这篇文章会把 Codex 的计费逻辑拆开讲清楚，再结合我实测跑过的任务，把最容易超支的几个场景列出来，最后给你一套可以直接照做的成本控制方案。适合刚接触 Codex、准备拿它跑真实项目的开发者，也适合已经被账单吓到、想搞明白钱到底花在哪的人。
1. 先把账算明白：Codex 到底按什么扣钱
1.1 不是按“次数”，而是按“每轮对话的完整上下文”
Codex 底层走的是大模型接口，计费核心就是 token。token 可以粗略理解成“模型处理文字的单位”：一个英文字母往往不到一个 token，一个中文汉字可能占一到两个 token，一段代码、一段日志、一次工具调用的输入输出，全都会被折算成 token。
但 Codex 和普通聊天不一样的地方在于，它不只是把你最新输入的那句话发给模型。它是一个多轮 Agent，每一轮请求里都包含了：系统提示词、可用工具的定义、从任务开始到现在全部的历史消息、中间所有工具执行的结果、以及你最新追加的那句“继续”。也就是说，Agent 每推进一轮，模型都要把整本“任务回忆录”从头读一遍。
我用一个生活化的类比来解释：你请人帮忙改一本书里的一个错别字，正常做法是告诉他页码和位置，他翻到那一页改掉就行。但 Codex 的机制类似于，你每说一句“还有哪里要改”，他就把整本书重新复印一遍，再在复印件上找那个错别字。复印整本书的成本，远远高于改那个错别字本身。Codex 的钱就是这么悄悄花掉的。
每次工具调用也会让上下文变得更胖。Codex 跑一个任务，通常会经历“读文件 → 改代码 → 跑测试 → 看结果 → 再改”这样的循环，每一次循环的结果都会追加进历史消息。等到任务过半，上下文可能已经积累了几万甚至十几万 token。而下一轮“继续”，这些 token 全部都要重新计费。
这也是为什么很多人看 Codex 的账单会懵：明明没有几个来回，代码改动也不大，但费用高得离谱。不是模型单价贵，而是每一轮都在为“整段历史”买单。
1.2 为什么“继续”按钮是账单炸弹
“继续”按钮在界面上看起来只是一个普通操作，但在 API 层，它意味着发起一次全新的完整请求。这个请求会把整个会话的上下文全部带上，哪怕你只是为了让模型多说一句“好的，我继续排查”，输入侧的 token 也已经按照全量历史计算了。
我举个具体例子。假设你跑了一个中等体量的重构任务，经过 30 轮工具调用后，上下文已经积累到 120k 输入 token。这时候你点一次“继续”，仅输入部分就要按 120k token 计费。如果按每百万 token 输入价格 1.2 美元估算（不同档位价格不同，实际以你账户定价为准），那这一次“继续”光是输入成本就是 120000 / 1000000 × 1.2 ≈ 0.14 美元，再算上模型生成的输出 token，单轮成本可能到 0.2 至 0.5 美元。
听起来单轮不多，但如果你在一个长任务里点了 20 次“继续”，那就是 20 轮全量计费。而且上下文还在持续膨胀，越到后面，每一轮越贵。前面 10 轮可能每轮只要 3 万 token，后面 10 轮每轮可能已经 10 万 token，总费用不是线性增长，是加速增长。
下面这张表可以帮你直观感受“上下文规模 × 轮数”对成本的影响。按输入单价 1.2 美元/百万 token、单轮输出 3000 token、输出单价 10 美元/百万 token 估算：
| 会话上下文大小 | 单轮输入费用 | 单轮输出费用 | 单轮合计 | 跑 20 轮累计 |
|---|---|---|---|---|
| 10k token | 0.012 美元 | 0.03 美元 | 0.042 美元 | 约 0.84 美元 |
| 50k token | 0.06 美元 | 0.03 美元 | 0.09 美元 | 约 1.8 美元 |
| 100k token | 0.12 美元 | 0.03 美元 | 0.15 美元 | 约 3 美元 |
| 200k token | 0.24 美元 | 0.03 美元 | 0.27 美元 | 约 5.4 美元 |
注意这只是理想情况。如果每一轮里还夹着大量工具输出、失败重试、大文件读取，单轮输入 token 会比表格里的估计高很多，累计费用翻几倍很正常。所以“继续”不是免费续杯，它是把前面所有历史重新结一次账。
2. 我实测下来的账单爆点：藏在四个不起眼的地方
2.1 失败重试的“乘数效应”
我测试过程中最心疼的一笔钱，不是模型能力不够，而是它反复失败的“乘数效应”。Codex 执行命令时，如果第一步跑失败了，它会基于失败信息重新尝试。表面上你只看到了“测试没过，它继续修”，但每一轮尝试都会把上一次的失败日志、命令输出、新的修改方案全部追加进历史，然后再完整发送一遍。
我跑过一个编译错误修复任务，第一次改完编译还是挂，Codex 连续重试了 5 轮。每一轮上下文都越来越胖，最后几轮单轮输入 token 稳定在 9 万以上。算下来，这一个本该十几分钟搞定的任务，消耗的 token 足够跑三四个正常任务。失败重试的可怕之处在于，它不仅浪费本轮，还会推高后续所有轮次的输入成本，因为那段失败记录会一直留在上下文里，之后每一次“继续”都要为它付费。
注意：看到连续两三次失败重试，先手动停一下。让 Codex 自己无限重试，是最快的烧钱方式。停下来，清理掉无用的调试输出，或者干脆重开一个会话再继续，成本会低很多。
2.2 工具输出无脑塞进上下文
第二个爆点是工具输出。Codex 需要调用命令来了解项目状态，比如跑测试、查日志、看文件内容。问题在于，很多人给它的命令太野了，一条 grep 能打出几百行匹配结果，一条 cat 能把整个配置文件读进去，一条测试命令能把几千行堆栈全部灌进上下文。
我在一次后端接口排查里，让 Codex 帮忙定位一个报错。它执行了一条测试命令，测试框架把整份详细报告打了出来，两千多行。这些行全部变成了上下文 token。随后它又为了找线索，连续读了好几个大文件，上下文瞬间冲破 15 万 token。其实我只需要它看最后 50 行报错摘要，但工具输出没有做任何裁剪，结果就是为大量无关文本付费。
这不是 Codex 单方面的问题，是使用习惯的问题。你让它执行什么命令，决定了它会看到多少内容。如果你平时习惯把整个日志文件 cat 出来，或者让测试命令输出完整报告，那就相当于主动给上下文注水。后面我会专门讲怎么“让工具输出话少一点”，这里先记住一个判断标准：凡是你不愿意自己盯着看十分钟的内容，就不该让它整段进入上下文。
2.3 自动继续 / 无人值守跑批
第三个爆点，也是最隐蔽的，是无人值守模式下的自动循环。Codex 支持在无人干预的情况下自主跑完一个任务，比如你只丢下一句“把这个模块重构完”，它就会自己循环执行“读文件、改代码、跑测试、看结果、再改”。这个模式很爽，但账单也很刺激。
我测试过一个大一点的重构任务，从外面看只是派了一个活，实际后台跑了 40 多轮。每轮都带着越来越大的上下文，中间还有几次测试失败重试。等我第二天看到结果时，成果确实不错，但费用比我预想的高出好几倍。问题不在于它多做了事，而在于“没有结束条件”的自主循环会把成本无限放大。
我后来给自己定了一条铁律：任何无人值守任务，必须先限制轮数，再保持只读沙箱或人工审批，绝不能让它在一个会话里无限续跑。Codex 的能力再强，也需要人为设置边界，否则它只会在“把活干好”和“把钱花光”之间毫不犹豫选择后者。
2.4 会话复用 / 不清理上下文
第四个爆点是会话复用。有些人习惯早上开一个 Codex 会话，从项目 A 改到项目 B，再到项目 C，一整天都不关。这样做看起来省事，实际上每一轮“继续”都在为之前所有项目的历史消息付费。你明明已经开始处理项目 C 了，模型却还要背着项目 A 和项目 B 的几十条旧消息，每一次请求都重新读一遍。
我做过对比：同一个改动，在刚开的新会话里做，上下文只有几千 token；在一个已经堆了两个小时历史的老会话里做，同样的改动光输入 token 就多花了好几倍。会话越长，单轮成本越高，这是物理规律，没法绕过。
所以我的做法是：一个任务一个会话，做完就关。大任务拆成几个阶段，每个阶段开新会话。你可能会担心新会话会丢失上下文，但其实只要把上一阶段的可验收成果、关键结论写进一条简短总结，下一阶段用这条总结开局，效果并不差，成本却能省下一大截。
3. 怎么把“一句继续”变成可控成本：实操配置与习惯
3.1 给 Codex 加“预算围栏”
成本控制第一步，不是等到月底看账单，而是任务开始前就设好边界。我给 Codex 的日常使用加了四道围栏：审批策略、沙箱权限、任务拆分、上下文意识。
审批策略上，我尽量保留人工确认环节，不让它在没有监督的情况下大幅改动项目。沙箱权限上，我倾向用只读或受控写入模式，避免它乱执行高危命令，也能减少因为权限问题导致的失败重试。任务拆分上，我坚持一个任务只做一件可验收的小事，比如“修好这个接口的鉴权”“把这两个字段接入新模型”，而不是“优化整个系统”。上下文意识则是时刻提醒自己：别让一个会话无限膨胀。
Codex 的配置文件一般在~/.codex/config.toml。一个基础但重要的配置是模型档位。我列一个保守示例，具体字段以你安装版本的官方文档为准：
# ~/.codex/config.toml # 模型档位会影响单价和可用能力，填当前账号可用的模型代号 model = "gpt-5-codex"这里要特别提醒：网上流传的配置和模型代号未必适合你的账号。如果你把不存在的模型名填进去，任务一开始就会报错，比如常见的the 'xxx' model is not supported。我会在后面的排查部分再展开。
3.2 盯着 usage 字段记账
光设置边界还不够，你要知道每次请求到底花了多少 token。Codex 的每次响应里通常会带 usage 信息，至少包含输入 token 和输出 token 两部分。我强烈建议你把这个数据记下来，不要只等平台账单。
最简单的做法是，每次跑完一个任务，手动看一眼 usage，把输入 token、输出 token 按任务维度记在一个文本文件里。比如：
2025-06-10 修复登录接口鉴权 input: 86000 output: 4200月底把记录汇总，你就能看出哪类任务最烧钱，哪类任务性价比最高。我在实测中发现，最烧钱的任务往往不是最复杂的，而是上下文管理最差的那几类：反复失败重试、工具输出过长、会话跨项目复用。这些通过 usage 记录一眼就能看出来。
注意：如果只看输出 token，你至少会低估一半以上的真实成本。我的实测里，大任务的输入 token 通常是输出 token 的十到二十倍，因为每一轮都要重发整段历史。
3.3 让工具输出“话少一点”
控制工具输出，是成本控制里立竿见影的一招。核心思路很简单：别让 Codex 看到完整的大文件、大日志，给它看摘要和关键片段就够了。
举个例子，跑测试时不要直接让它执行裸的npm test，可以先把输出重定向到文件，再只展示最后几十行：
npm test > test.log 2>&1; tail -n 50 test.log查日志时不要cat 整个文件，用带行号、带过滤的精确查询：
grep -n "ERROR" server.log | head -n 20读源码时不要让它读整个仓库，明确告诉它看哪个文件、哪个函数区间。这些命令层面的小改动，对 Codex 的最终结果影响很小，但能把上下文里的无用 token 砍掉一大半。我在实际项目中，用这个方式把单个任务的输入 token 平均降了 40% 左右，效果非常直接。
3.4 把长会话切成短会话
短会话的好处前面已经说过，这里再给一个具体操作节奏。我一般把任务分成“理解→方案→实现→验证”四个阶段，每个阶段开新会话。
理解阶段，我让 Codex 读关键文件并输出一份简短的项目现状说明。方案阶段，我基于这份说明，让它给出改动计划。实现阶段，我带着明确的改动清单让它写代码。验证阶段，我让它跑测试、修失败。每个阶段开始时，我把上一阶段的结论用三五句话总结给它，而不是把上一阶段几百行历史全部带过来。
这样做有两个好处：第一，每一轮的上下文都保持在合理范围，单轮成本不会失控；第二，模型不会被旧阶段的无关信息干扰，理解反而更聚焦。缺点是你要多花一点点时间写阶段总结，但这点时间换来的费用节省，我在实测中大概是三到五倍。
4. 翻车现场与排查速查表
4.1 账单翻倍的三个典型现场
我把实测里遇到的翻车现场整理成下面这个速查表，每一条都是真实发生过的场景，带有明显的特征信号，你可以对照检查自己的使用习惯。
| 翻车现场 | 典型现象 | 真正原因 | 处理方式 |
|---|---|---|---|
| 跑了半小时“没干活”却在扣费 | 模型反复执行命令、反复失败重试，界面看起来很忙但产出很少 | 工具输出噪音大，失败日志反复入上下文，自动循环不受控 | 手动中断，清理上下文，限制轮数再继续 |
| 越到后面越贵 | 同一个任务前半段便宜，后半段每轮费用明显上升 | 上下文线性膨胀，每轮全量重发历史 | 按阶段拆分任务，避免单会话无限累积 |
| 一个会话做三个项目 | 项目 A 的改动，在项目 C 的会话里做，费用翻倍 | 跨项目历史堆积，无关 token 全部计价 | 一个任务一个会话，做完即关 |
这三种现场的共同点，都是上下文管理失控。Codex 本身是个高效工具，但如果你不对上下文做约束，它就会把每一分预算都花在“重新阅读历史”上。
4.2 常见报错与解决
我整理了四个 Codex 使用中最常见的报错信息，都是真实踩过的，每个附带排查思路。
| 报错信息 | 含义 | 排查与解决 |
|---|---|---|
the 'xxx' model is not supported when using codex | 填了当前 Codex 通道不支持的模型名 | 检查模型代号是否拼错，换成账号当前可用的模型档位 |
auth token is unavailable | 没有可用的认证凭证 | 检查 API Key 是否设置、环境变量是否加载、登录状态是否过期，重新登录再试 |
codex is ignoring 1 unrecognized configuration setting | 配置文件里有未知字段或拼写错误 | 打开 config.toml，对照官方模板逐项核对，删掉多余或错误字段 |
| 上下文长度超限 | 会话历史太长，超出模型窗口 | 停止当前会话，重开新会话，把关键结论带过去 |
这些报错大多不是 Codex 本身的问题，而是配置习惯和会话管理的问题。遇到报错先不要反复重试，把上下文清一下、配置核对一下，往往比盲目重发更省钱。
4.3 给新手的第一次 Codex 省钱清单
如果你是第一次用 Codex，下面这份清单可以直接照做，避免第一步就把预算打光：
- 第一次只跑小任务，比如让 Codex 解释一段代码、补一个单元测试，不要一上来就做整个模块重构。
- 尽量保持只读沙箱或人工审批，不要放开全自动执行。
- 收到第一个报错时，先检查配置，不要点“继续”让它自动重试很多轮。
- 跑完一个任务看一眼 usage，记录输入和输出 token，形成记账习惯。
- 任务中途如果发现上下文已经很大，果断开新会话，不要心疼已经聊了多久。
- 记住这个公式：成本约等于“每一轮的上下文总量 × 轮数”，任何能减少这两者的操作，都是在省钱。
这份清单不复杂，但能把大多数新手账单事故扼杀在摇篮里。
5. 最后分享几个我自己养成的习惯
5.1 我的三个省钱铁律
第一，任务开始前先想清楚结束条件。没有结束条件，就不让 Codex 开工。“做完就停”和“做完再优化”是两个完全不同的预算级别，我非常建议你把任务描述写具体，比如“把这个函数改成支持传入配置对象，保持原有调用方式不变，跑通现有测试”。
第二，会话里第一次出现失败重试时，手动停一下。我会快速判断这次失败值不值得继续，如果不值得，就清理掉相关上下文再继续。虽然多花了一点操作时间，但后面每一轮都少付几万 token，长期算下来非常划算。
第三，跑完任务立刻关会话。不管成果满不满意，都不在原会话里硬接着做下一个任务。下一件事，永远是开新会话、写阶段总结、重新开局。
5.2 一个你可能忽视的土办法
最后分享一个土办法：我在本地维护了一个codex-cost.log文件，每次跑完任务就追加一行，格式只有四个字段：日期、任务名、输入 token、输出 token。一个月下来，我只要简单加总，就能看出哪类任务最烧钱。
这个方法没有任何技术含量，但对成本控制极其有效。因为 Codex 的钱不是一次花光的，而是散落在几十次“继续”里，如果你不主动记录，根本感知不到它在持续漏钱。当你开始记录之后会发现，很多你以为“没跑几步”的任务，其实已经积累了惊人的 token 消耗。
Codex 是个好工具，问题从来不在工具本身，而在于我们对它的计费机制和上下文管理重视不够。养成一点记账和拆任务的习惯，就能让它把每一分钱都花在真正有用的代码上。
