Codex cached tokens 很大，是不是在烧钱？
Codex 用量里常见这种写法：
Codex cached tokens 很大，是不是在烧钱？ (text)
input=2,542,755 (+191,449,344 cached)cached 虽然数字大，但其实并不是“又多算了一份 input”。它表示一段相同的 prompt 前缀命中了 prompt caching。Codex 继续在同一条会话里工作时，系统指令、工具说明、AGENTS.md、会话历史、已读文件摘要、当前计划，都可能留在这个前缀里。所以 cached tokens 大，只说明一件事：这条会话带着一段稳定上下文。它可能是 OK 的，但也可能只是把太多无关材料反复带进了每一轮请求。判断成本时，单看
cached 没意义，要和新的 input、output、reasoning 明细一起看。cached tokens 是什么
Prompt caching 复用的是 prompt 里相同的前缀。稳定内容越靠前，后续请求越容易命中缓存；每轮都会变的用户输入、临时数据、工具结果，放在后面更合适。
在 coding agent 里，这个前缀往往很长。一次普通的 Codex 会话里，前缀可能包含：
- 系统指令、工具说明和已加载的 skill / plugin 元数据
- 被实际使用过的 skill 内容
- 仓库里的
AGENTS.md - 当前启用的 MCP server 定义
- 会话历史
- 已读文件摘要
- 计划、约束和中间结果
怎么读一组 token 数据
拿这组数举例：
Codex cached tokens 很大，是不是在烧钱？ (text)
total=3,000,759
input=2,542,755 (+191,449,344 cached)
output=458,004
reasoning=196,833total 是 input + output：Codex cached tokens 很大，是不是在烧钱？ (text)
2,542,755 + 458,004 = 3,000,759后面的
+191,449,344 cached 是单独列出来的缓存输入量，当前这个 usage 说明这条会话里有大量重复前缀被复用了。缓存命中占比：
Codex cached tokens 很大，是不是在烧钱？ (text)
cached / (input + cached)
= 191,449,344 / (2,542,755 + 191,449,344)
≈ 98.69%这个比例很高，说明前缀稳定，本身不是坏事
缓存量和新输入的比例：
Codex cached tokens 很大，是不是在烧钱？ (text)
cached / input
= 191,449,344 / 2,542,755
≈ 75.3这说明被复用的上下文远大于每轮新增输入。这不等于浪费，但已经暴露出一个问题：被反复带着走的上下文，是否都和当前任务有关？
再看
output 和 reasoning。有些界面会把 reasoning 作为输出明细展示。看到这种明细时，不能在 output 外面再手动加一遍，先确认当前平台怎么归类。小任务配上很长的解释，或者过高的 reasoning effort，才是更直接的成本信号。cached 很高不需要优化的情况
有些 cached 高不用处理。
比如在一个明确任务里连续改同一组文件，Codex 已经读过项目约束、测试命令、相关类和失败日志。后面几轮
cached 变高，input 没有继续爆炸，output usage 也处于合理的范围，这其实是健康状态：上下文稳定，缓存命中好，agent 没有到处乱读乱用。又比如 Codex 正在做一轮比较复杂的架构 review。前面读了不少文件，后面持续讨论同一个调用链。只要任务边界还清楚，cached 高只能说明它还在同一条思路里工作。
这种时候不要为了“把 cached 降下来”去清空会话，比如在使用一些 Code Graph 工具（比如
Understand Anything），下一轮可能需要重新读取上下文，缓存命中变差，结果更慢也更贵。什么时候该优化
下面几种情况才需要收缩上下文。
现象 | 判断 | 处理方式 |
|---|---|---|
cached 很高，input、output 都可控 | 前缀稳定，缓存命中好 | 继续做 |
cached 很高，但 credits 掉得快 | 便宜 token 也经不起大量消耗 | 缩小上下文来源 |
input 很高，cached 低 | prompt 前缀不稳定，缓存命中差 | 固定静态前缀，减少无关变化 |
output 或 reasoning 明显偏高 | 模型说太多，或者思考预算过重 | 限制输出，降低 reasoning effort |
MCP 很多、 AGENTS.md 很长、会话越聊越散 | 每轮都在背一堆不需要的东西 | 精简注入源，必要时开新会话 |
优化目标不是把 cached tokens 清零。cached 命中本来就是一件好事。更合适的目标是：每轮只带当前任务需要的上下文，同时保证稳定前缀带来的 cache 命中率。
成本公式
费率会变，不同计划也不一样。成本结构大致是这样：
Codex cached tokens 很大，是不是在烧钱？ (text)
cost = input_tokens * input_rate
+ cached_input_tokens * cached_input_rate
+ output_tokens * output_rate如果看的是 ChatGPT / Codex credits，可以把
rate 理解成每 1M tokens 对应的 credit rate。这个公式只是提醒几个边界：cached input 通常更便宜，但不是零；output 往往更贵；fast mode、图片、并行任务、自动 review 这类功能也可能改变消耗速度。
Codex 工作流怎么降成本
降成本先从任务边界开始，而不是从缓存的用量开始分析。
一个 session 应该尽量围绕一个明确的上下文目标展开。
如果“理解项目、修 bug、写测试”都是为了解决同一个问题，它们可以属于同一个 session；但“改 CI”“写文档”是否继续放在同一个 session，还得是要看它们是否仍然属于同一段上下文。
关键不是按工作类型拆分，而是按上下文边界拆分：当任务目标或所需背景发生明显切换时，就应该开启新的 session。
AGENTS.md 也要克制。构建命令、测试命令、代码风格、关键架构约束适合放进去；长规范、完整 API 文档、大段示例，最好放到按需读取的文档里，渐进式加载，只要它每轮都会进上下文，每一个字都应该斟酌，尽可能压缩，不要超过 200 行不用的 MCP 可以先关掉。MCP 很好用，但每个 server 都会带工具定义和说明。简单任务没必要把一堆外部能力都挂着。
指令里直接写范围，比让 agent 自己猜要省很多：
Codex cached tokens 很大，是不是在烧钱？ (text)
只看 src/payment 和 tests/payment。
先总结调用链，不要修改代码。
如果需要读其他目录，先说明原因。这要比“全仓扫描一下，看看哪里能优化”省得多，也更容易得到可检查的结果。
小任务不需要太高的 reasoning effort。复杂架构、并发 bug、安全问题可以用高档；改一个字段名、补一个小测试、查一个配置问题，没必要让模型长时间 deep think。
最终输出也要限制。变更摘要、测试结果、风险点通常就够了。复述没改过的文件、写完整工作报告，都会把 output 撑大。
subagents 适合大范围审计、多方案探索、互相校验。普通单 bug，一个 agent 更省，状态也更清楚。
长会话已经跑偏时，开新 session，再贴一段短状态摘要，通常比一直用旧会话继续跑更干净，需要注意：cached 高不代表上下文干净。
一个可用的 Codex prompt Demo
下面这段 prompt 只做一件事：控制上下文边界。
Codex cached tokens 很大，是不是在烧钱？ (text)
目标：修复 <具体 bug / issue>。
范围：
- 只检查 <目录/文件>
- 不要扫描全仓，除非必要
- 不要修改无关文件
流程：
1. 先给出 5 行以内计划
2. 再只读取必要文件
3. 修改前说明会改哪些文件
4. 修改后运行最小相关测试
5. 最终输出：变更摘要、测试结果、风险点
约束：
- 不要重写整个文件
- 不要做全仓格式化
- 不要引入新依赖，除非先说明原因后写 ADR这段 prompt 的重点是限制起步范围。任务越明确，无关上下文越少，缓存前缀也越稳定。
总结
cached tokens 高，不一定是坏事。
先检查几个点：
- 输入是不是一轮比一轮大
- cached input 有没有稳定命中
- 回复是不是太啰嗦，输出了很多任务不需要的解释
- reasoning effort 有没有开得超过任务实际需要
如果这些都没问题，cached 高通常说明上下文复用得不错。Codex 能命中缓存。
所以真正的问题不是缓存高，而是会话失控：任务边界越来越模糊，
AGENTS.md 太重，MCP 带入了太多无关信息，reasoning effort 开得过高，或者一个 session 被拉得太长。真正费 credits 的，不是缓存命中多，而是每轮都把一堆用不上的上下文一起带进去。