额度刚重置一晚就少了一半：一次 Codex 用量排查的完整记录
昨天晚上额度刚重置，我只跑了一个用 GPT-6 Astra 的任务，今天打开一看，额度只剩 50% 多了。第一反应是怀疑缓存没生效——多轮对话里同样的上下文反复计费，才烧得这么快。带着这个疑问我和 Codex 排查了一轮，结论和预想正好相反：缓存不但生效了，命中率高达 98.1%；真正的问题是任务总量失控。把这次排查整理下来，以后再遇到额度异常下降，可以照着这个思路查。
一、先回答核心问题：Codex 有缓存命中的概念吗
有。OpenAI 的 Prompt Caching 会自动缓存提示词的前缀——系统指令、工具定义、历史消息这些固定部分，默认开启，不需要手动配置。下次请求的前缀和之前一致，这部分 token 就命中缓存。
关键的一点是：命中的 token 照样计费、照样计入额度，只是费率打折。不同模型的折扣力度不一样，所以"缓存命中率高"和"便宜"是两回事。这一点是后面所有分析的起点。
OpenAI 官方的 Prompt Caching 指南在这里：https://developers.openai.com/api/docs/guides/prompt-caching ，原理、限制和费率说明都可以查到。
二、排查结果：缓存工作正常，数字却吓人
Codex 统计了额度重置后本机的运行记录，结果是这样的：
| 项目 | 数据 |
|---|---|
| 累计逻辑输入 | 约 4.07 亿 tokens |
| 缓存命中输入 | 约 3.995 亿 tokens |
| 输入缓存命中率 | 约 98.1% |
| 输出 tokens | 约 153 万 |
| 模型线程 | 24 条 |
先解释一下"4.07 亿"的口径，免得被吓到：这不是说我手工输入了这么多内容，而是每次模型调用都要重新携带全部历史、文件内容、工具返回和系统指令。一个长任务跑几百次工具调用，上下文每次整份重复进模型，累计起来就是这个量级。
98.1% 的命中率说明缓存一直在正常工作。那额度为什么还是掉得这么快？问题出在别处。
三、真正的元凶：一个从"看文档"失控成大型多代理任务的会话
绝大部分消耗来自一个名为"查看 niuma-boss 最新文档"的任务：
- 主任务加子代理，一共开了 21 条模型线程
- 混用了 GPT-6 Astra 的 high 和 ultra 推理档位
- 累计约 4.02 亿输入 tokens，占重置后本机加权消耗的 98.8%
- 检查时这个任务还显示为 active，仍在继续消耗
它名义上是"看文档"，实际演进成了持续读大量文件、修改设计、反复校验、交叉评审，还不断派出子代理。机制上，每执行完一次工具，模型都要把当前上下文完整地再处理一遍；上下文越滚越大，几百次调用乘下来，就是数亿 token——即使每一次都命中缓存。
四、为什么命中了缓存还是这么贵：算一笔账
按 Codex 排查时引用的官方费率，GPT-6 Astra 的额度折算是：
| 计费项 | credits / 百万 token |
|---|---|
| 普通输入 | 250 |
| 缓存输入 | 25 |
| 输出 | 1,250 |
缓存输入是普通输入的约 10%，很划算，但不是免费。昨晚那个任务仅缓存输入就接近 3.94 亿 tokens，折算仍约消耗 9,853 credits；加上未缓存输入和输出，整个任务约 13,628 credits。对照当时账户——通用周额度已用 44%、剩余约 56%，GPT-5.3-Codex-Spark 的独立额度还是 0%——就能对上账了。
五、原因可以确定为六条
- GPT-6 Astra 本身额度单价高；
- 任务用到了 high/ultra 高档位；
- 多代理扩展到了 21 条模型线程；
- 长上下文在每次工具调用后重复进入模型；
- 缓存虽然省了约 90% 的输入费率，但总输入规模达到数亿 token；
- 任务排查时仍在运行，还在继续消耗。
六、怎么优化：别再追命中率，去压总量
98.1% 的命中率已经接近极限，从 98% 提到 99% 没有意义。真正该做的是降低"缓存上下文被重复读取的总量"。
先说保住命中率的做法（同一段时间内）：
- 不切换模型，不频繁切换 high/ultra 档位；
- 不随意启用、关闭或调整 MCP、插件、工具；
- 固定的要求放提示词前面，每次变化的内容放最后；
- 相关工作连续处理，间隔别太久——缓存有效期有限，但每次命中会续期；
- 后续补充只说变化，比如"继续处理第 3 阶段"，不要重新粘贴整份需求。
原理就是前缀一致才能命中：模型、工具定义、推理档位、前部指令任何一样变了，后面就全 miss。
更重要的是给大型任务加消耗约束，我现在的做法是把这段话直接放进任务提示里：
控制本任务的额度消耗：
- 最多使用 2 个子代理，子代理不得继续创建子代理；
- 普通工作用当前 reasoning effort，只有明确的困难决策才临时提高；
- 不重复读取已确认的完整文件，优先搜索命中行，只读必要上下文；
- 命令和工具输出只保留结论、错误及必要证据，不返回整份日志或整份文件；
- 每完成一个阶段压缩上下文，只保留：已完成事项、改动文件、关键决定、验证结果、剩余任务；
- 历史上下文过大时，生成交接摘要并停止，由新任务继续；
- 达到当前阶段验收条件后立即停止，不做未要求的扩展、重复评审或重复测试。
再配合模型分工：日常编码、文档整理用 Terra；简单检索、批量处理用 Luna 或 Spark；架构决策、疑难评审才上 Astra high；ultra 只在明确需要时用。
还要说明一点：在 Codex 桌面端，缓存由系统自动管理，prompt_cache_key、显式断点这些属于 API 侧能力，目前没有公开的桌面端配置入口。所以有效的优化顺序是：限制子代理 → 缩短上下文 → 减少工具返回 → 降低模型档位 → 最后才轮到把命中率从 98% 提到 99%。
结语
这次排查最大的收获是搞清楚了一个因果：额度异常下降不是"缓存失效"，而是"一个任务在多代理和长上下文的放大下失控"。缓存解决的是单价问题，解决不了总量问题；总量问题只能靠任务管理解决——限制子代理数量、阶段完成后新开任务、别让一个会话无限膨胀。Astra 留给真正重要的决策，普通活儿交给便宜的模型，额度的曲线自然就平了。
数据说明：文中账户状态、token 统计和费率折算均来自 2026-09-13 与 Codex 的排查对话；Prompt Caching 机制参考 OpenAI 官方指南（developers.openai.com/api/docs/guides/prompt-caching）。