用 Codex 怎么省 Token：账单别让上下文偷偷烧掉

一个让人肉疼的早晨

某天我盯着 Codex 的 /status，发现一个简单的小任务——就改了三行代码——居然吃掉了将近七万 token。我当时第一反应是："这模型是不是把我整个仓库背了一遍？"

后来发现，还真差不多。

很多人用 Codex 觉得 token 烧得快，第一反应是"模型太贵了""换个便宜的模型吧"。这个方向不算错，但通常不是第一刀。真正的大头往往不在模型多能干，而在上下文管理。 一个臃肿、跑偏、塞满无关文件的会话，在一些实测场景里会比干净会话多吃数倍 token；而调整回复啰嗦程度这类动作，通常只是小头（可以参考 r/codex 社区的实测讨论，但别把社区数字当成物理定律）。

换句话说：你抠模型回复的字数，是在捡芝麻；你管好上下文，才是在保西瓜。

这篇文章不灌鸡汤，咱们先搞懂 Codex 的 token 到底花在哪，再给一份能直接照着做的清单。

一、先搞懂：Codex 的 token 到底烧在哪

要省钱，得先知道钱怎么花的。OpenAI 官方有一篇 《Unrolling the Codex agent loop》 把这事讲得很透，我给你提炼三个关键点。

1. 每一轮对话，都要继续带着"历史包袱"

这是最反直觉、也最烧钱的一点。

你以为多聊一句只花一句的钱？不是。模型每一轮都需要看到可用的历史上下文；从计费和上下文窗口的角度看，之前的消息、工具调用、文件内容，都会继续占用输入预算。

所以一个会话越聊越长，每一轮的成本就越高——不是线性增长，是越滚越大的雪球。这就解释了我那个"改三行花七万 token"的早晨：不是这次改动贵，是这个会话之前已经堆了一屁股上下文。

2. 开局就有一大坨"固定开销"

你还没说话，Codex 已经先往 prompt 里塞了一堆东西：

• 权限和沙箱说明
• 模型自带的指令（base instructions）
• 全局和项目里的 AGENTS.md / AGENTS.override.md。按 官方说明，项目指令会从项目根目录沿着当前工作目录往下收集，默认合并上限是 32 KiB
• 如果你配了 skills，开局会带上技能名称、描述和路径；skills 使用 progressive disclosure，只有真正用到某个 skill 时，才会再读取完整的 SKILL.md
• 环境上下文（当前目录、shell 等）

社区有人拆过，在某些配置下，光这些默认上下文就能让一次交互的 prompt 很快膨胀到上万 token（见 dev.build 的拆解）。具体数字会随着客户端、模型、工具和项目配置变化，但结论很稳：你的 AGENTS.md 写得越胖，每一个任务都要背着它出门。

3. Prompt 缓存：省钱的关键，但很"脆"

好消息是，OpenAI 有 prompt 缓存（prompt caching）——如果你这次请求的开头部分（前缀）跟上次完全一致，服务器可以复用之前的计算，缓存命中的部分便宜很多。

坏消息是，prompt cache 喜欢稳定的前缀。下面这些变化，都容易降低缓存命中率：

• 会话中途切换模型；
• 会话中途增减工具（比如 MCP server 动态改变了工具列表）；
• 改了沙箱配置、审批模式，或者切换了工作目录。

记住这条原则：静态的东西放前面，多变的东西放后面，中途少乱动配置。 这是省 token 的底层逻辑，后面很多招都从这儿派生出来。

二、最值钱的一招：会话脏了就开新的

如果这篇文章你只记一条，就记这条：

不相关的新任务，开新会话（new thread）；当前会话明显跑偏或臃肿，果断重开。

为什么这是性价比最高的动作？回到第一节——每轮都要继续携带历史上下文。当一个会话里堆满了上一个任务的文件、试错、跑偏的搜索，你做下一件事时，这些全都在陪绑收费。

我自己的经验法则：

• 任务切换 = 会话切换。修完登录 bug，要去写个新接口，别在同一个会话里接着聊，开新的。
• 跑偏早打断。如果 Codex 前几步在读一堆无关文件、反复搜索、或者范围越做越大，别等它把这一轮额度烧完——立刻打断，把它拉回最小的下一步动作。
• 长任务用 handoff 交接。当一个会话快变"老油条"了，与其让它带着一身陈年上下文继续，不如让它先输出一份交接纪要（当前目标、相关文件、已做的决定、已知的坑、验证命令、下一步），然后开个干净会话，把纪要贴进去重新开始。

补一句原理：Codex 的上下文压缩（compaction）本质就是在做这件事——它在 token 逼近窗口上限时，自动把会话压成一份"交接摘要"。既然如此，与其等它被动压缩，不如你主动在干净的时候就切，省得为那一大坨膨胀的上下文付费。

三、给 AGENTS.md 瘦身：每个任务都在为它付费

前面说了，AGENTS.md 是开局固定开销的一部分，新会话、新任务通常都要带着它跑。所以它不是越详细越好，而是越精准越好。（AGENTS.md 到底该写什么、怎么和 rules、hooks、skills 配合，我在 《给全栈程序员的 Codex 实战手册》 里专门拆过，这里只谈"省 token"这一面。）

r/codex 上有位用户分享过一个很实在的做法（我深以为然）:

我把 AGENTS.md 里所有关于"好习惯""行为规范"的泛泛指导全删了，现在只留两类内容：一是功能上必需的，二是 Codex 不写就会反复犯错的。

这个标准很好用。给你一张自检表，对 AGENTS.md 里的每一条问一句：

一句话：AGENTS.md 是给 Codex 的项目说明书，不是给它的思想品德课本。

四、模型和推理档位：别用高射炮打蚊子

Codex 现在有不同的模型和推理档位（reasoning effort），价格差很多。最常见的浪费，就是所有任务，无论大小，一律拉满。

我的搭配策略：

• 规划用强的，执行用弱的。复杂任务先用高推理档（high/xhigh）的模型做规划、拆解，想清楚了，再切到中/小档（medium/mini）去执行具体编码。
• 按风险选推理档。改文案、调格式、小重构、明摆着的修复——这些低风险活儿用轻推理就够了；只有涉及架构决策、复杂逻辑、容易出错的地方，才值得上高推理。
• 默认用 standard，别默认用 fast。fast 模式是用更高 credit 成本换更低延迟，它适合"等待成本 > 费用成本"的场景，比如现场排障、实时调试、需要快速来回确认的问题。常规任务先用 standard，别把加速当默认档。

注意一个缓存的坑：会话中途切换模型、工具和配置，都可能影响 prompt cache。所以更稳的做法是"规划"和"执行"分在不同会话里做，而不是在同一个会话里反复横跳着换档。

五、把消耗"看得见"：你管不了你看不见的东西

省钱的最后一步，是别再当睁眼瞎。Codex 已经能通过 /status、/usage 这类命令展示会话配置和 token 使用。账看得见，优化才有抓手。

几个能落地的监控手段：

• 会话中随手敲 /status：看当前这个会话烧了多少 token。逼近窗口上限了，就别让它继续往上堆，开新会话。
• 用 ccusage 做周审计：这个小工具会读 ~/.codex 下的会话日志，按天/按月算出 input、output、reasoning、cache 各项的 token 和花费。

bash # 看 Codex 的每日 token 消耗明细 npx @ccusage/codex

重点盯一个指标：cached-input 占比。如果某些会话明显偏低，说明你的 prompt 缓存可能在频繁失效——多半是中途切了模型、改了工具或目录，对照第一节去查。不要迷信一个固定阈值，先拿自己的项目做基线。 - 盯紧客户端版本：客户端的展示、统计和缓存策略都可能变。建议锁定一个已知良好的版本，升级前先拿一个小任务测一下 token 消耗，别盲目跟最新版。

bash codex --version

怎么度量：别只凭感觉省钱

省 token 不能靠玄学，也不能靠"我感觉这次挺省"。至少做一张小表，每周看一次：

六、几个容易被忽略的小动作

上面讲的是大原则。落到每天写代码，还有一些很小、但很管用的习惯。它们的共同点是：少给上下文，但给准上下文。

1. 开工前先要"最小上下文计划"

不要一上来就说"帮我修这个问题"。这句话太宽，Codex 很可能先在仓库里跑一圈，读一堆暂时用不上的文件。更好的开场是：

先不要改代码。请先判断这个任务最少需要读哪些文件，
列出 3-8 个候选文件和理由。

这一步看似多花了一轮，其实常常更省。因为它把搜索范围先框住了，后面少走很多冤枉路。

2. 先搜索，再局部读文件

好顺序是：rg 找入口，sed 读局部，必要时再读完整文件。别让 Codex "先浏览一下项目"，这个说法太豪放，token 也会很豪放。

rg -n "refreshToken" src test
sed -n '120,190p' path/to/file
git diff -- path/to/file

同理，能说"看 FooService.java 的 refreshToken()"就别贴 300 行代码。贴代码只贴最小片段，最好带上行号、错误信息和你已经排除过的可能性。

3. 管住命令输出，别让日志淹死人

很多 token 不是模型说掉的，是工具输出刷掉的。cat 大文件、全量 git diff、测试日志刷屏，都是隐形大户。

给 Codex 下命令时，可以明确限制：

只看失败测试的最后 80 行日志。
不要展开无关模块的 diff。
如果连续两次搜索没有新线索，请停下来汇报，不要继续扩大范围。

长日志也不要整锅端。先给最后 50 行、关键 exception、复现命令、最近改动文件、期望行为和实际行为。排障不是吃自助餐，夹太多反而消化不了。

4. 大任务拆 checkpoint，不要一口吞

大任务最容易烧 token，因为它会把"读需求、找入口、改代码、补测试、跑验证、写总结"全混在一锅粥里。

更稳的节奏是：

1. 先读需求和相关文件，输出计划，不改代码。
2. 确认计划后，只改核心逻辑。
3. 再补测试。
4. 最后跑验证，给出风险和回滚点。

这不是流程洁癖，而是给上下文做分段管理。每一步都能停下来检查，少返工，也少让旧上下文滚雪球。

5. 管住 IDE 上下文和长提示词

如果你用 /ide 或 IDE 插件，注意打开的文件也可能被带进上下文。任务前把无关 tab 关掉，或者明确说：

不要使用 IDE open files，只看我指定的文件。

还有一种常见浪费：每次都贴一大段 code review 规则、写作规则、测试规则。反复出现的长提示，应该沉淀成 skill。Codex skills 本来就支持 progressive disclosure：平时只带名称、描述和路径，用到时才读取完整说明。该沉淀的沉淀，该临时贴的临时贴，别把一次性说明塞进长期上下文。

6. 少要长篇解释，多要结构化结果

实现类任务里，解释太多也会变成后续历史包袱。可以直接限制输出：

只给：变更点、风险、验证命令。不要解释背景。

测试失败也一样。先让 Codex 抽取失败测试名、错误类型、第一处业务相关栈帧、可能相关文件。必要时开新会话，只带这份摘要继续查。

最后提醒一句：省 token 不是让 Codex 少知道，而是让它只知道当下必须知道的东西。该给的安全约束、数据迁移风险、并发边界、测试要求、发布限制，不能省。省掉这些，后面返工更贵。

总结：省 token 的本质是"管好上下文"

绕了一圈，你会发现省 token 的所有招数，根上其实就一句话：

每一轮都要继续携带历史上下文，所以让历史保持短、保持干净、保持缓存友好，就是省钱。

抠模型回复字数那些事，是小优化；管好会话边界、AGENTS.md、模型选择和缓存命中，才是大账。别捡了芝麻丢了西瓜。

省 Token 核对清单（可以直接抄走）

• [ ] 换任务就换会话：不相关的新活儿一律开新 thread，别在老会话里接着聊。
• [ ] 跑偏早打断：前几步就发现 Codex 在读无关文件、范围蔓延，立刻拦下拉回最小动作。
• [ ] 先要最小上下文计划：开工前让 Codex 列出需要读的 3-8 个文件和理由，别直接全仓库探索。
• [ ] 限制工具输出：优先 rg、局部 sed、指定文件 git diff，少用全量日志和大文件输出。
• [ ] AGENTS.md 只留两类：功能必需的 + 不写就会犯错的，其余正确的废话全删。
• [ ] 规划强、执行弱：高推理档做规划，中小档做编码，分会话进行。
• [ ] 默认 standard：没有非常充分的理由，别用 fast。
• [ ] 中途别乱动配置：别在一个会话里反复切模型、增减工具、换目录，护住 prompt 缓存。
• [ ] 长任务拆 checkpoint：计划、实现、测试、验证分段做，别一口吞。
• [ ] /status 随手看，ccusage 每周查：盯住 cached-input 占比和 input/output/reasoning 结构，先建立自己的基线。
• [ ] 锁定客户端版本：升级前用小任务测 token，别让展示变化或客户端 bug 偷偷影响判断。

明日行动

明天打开 Codex，先做四件事：

1. 把你的 AGENTS.md 拿出来，按"删了会不会犯错"的标准过一遍，砍掉所有正确的废话。
2. 给常用任务准备一句开场白："先不要改代码，先列最小需要阅读的文件和理由。"
3. 跑一次 npx @ccusage/codex，看看过去一周哪几个会话的 token 异常高、缓存命中异常低，找出你自己的烧钱模式。
4. 给自己定个肌肉记忆：做完一件事，养成开新会话的习惯，而不是在一个会话里从早聊到晚。

最后留个问题：你现在的 Codex 会话，平均一个任务烧多少 token？如果你答不上来，那第一件该做的事，就是先把 /status 和 ccusage 用起来——毕竟，你管不了你看不见的东西。