最近 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 token0.012 美元0.03 美元0.042 美元约 0.84 美元50k token0.06 美元0.03 美元0.09 美元约 1.8 美元100k token0.12 美元0.03 美元0.15 美元约 3 美元200k token0.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 21; 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 是个好工具问题从来不在工具本身而在于我们对它的计费机制和上下文管理重视不够。养成一点记账和拆任务的习惯就能让它把每一分钱都花在真正有用的代码上。