Codex 额度后半段为什么消耗特别快？Prompt Cache 机制详解

"用到后 40% 的时候，两下就没了。"

这句话我最近在和用 Codex 做开发的朋友聊天时反复听到。前半段额度用得挺正常，甚至觉得富裕，但一过某个临界点，额度就像开了加速器一样往下掉。

我自己也遇到了同样的问题。作为一个用 Codex 做日常开发超过半年的人，我一度以为是 OpenAI 在后台偷偷调了什么参数。直到我花了两周时间深入研究了 Prompt Cache 的工作机制，才发现真正的原因比我想象的简单——也比我想象的隐蔽。

结论先放这里：额度后半段加速消耗，不是因为你用多了，而是因为你的缓存命中率在悄悄下降。

你每次发消息，99% 的钱花在哪里？

要理解这个问题，得先搞清楚一个反直觉的事实：你和 Codex 对话时，每次发送的不只是你打的那句话。

一个典型的 Codex 请求，实际发送的内容包括：

  • 系统提示词（几千 token）
  • 工具定义——你装的所有 MCP 工具的 schema（几千到上万 token）
  • AGENTS.md 的完整内容
  • 之前所有的对话历史（几万到十几万 token）
  • 你刚打的那句话（几百 token）

也就是说，你觉得自己只问了一句"帮我改一下这个函数"，但实际上 API 处理的是一个十几万 token 的巨型请求。你说的那句话，可能只占总 token 的不到 1%。

剩下 99% 的费用，是在为重复发送一模一样的上下文买单。

这就是 Prompt Cache 存在的意义。

Prompt Cache 到底是什么？

Prompt Cache 的核心思想很简单：既然每次请求的前面一大段都是一样的，那就把这段的计算结果存起来，下次直接复用。

技术上，它存的不是文字本身，而是 Transformer 架构中 attention 层计算出来的 KV 张量（Key-Value tensors）。大模型推理分两个阶段：

  1. Prefill：把所有输入 token 扔进去，计算每一层的 KV 值。这是计算密集型操作，也是最贵的部分。
  2. Decode：基于已有的 KV 值，逐个生成输出 token。

如果前缀相同，服务器可以直接复用之前算好的 KV 张量，跳过 Prefill 阶段。这就是"缓存命中"。

根据 OpenAI 官方文档，这个机制是自动启用的：API 会缓存最长的已计算前缀，从 1024 token 起步，以 128 token 为增量递增。只要你的请求前缀和之前的请求匹配，就自动享受缓存折扣。

价格差距有多大？ 以 GPT-5.5 定价为例：

  • 正常输入：$5 / 百万 token
  • 缓存命中：$0.5 / 百万 token
  • 输出：$30 / 百万 token

输入价格差 10 倍。

一个正常的编码 session，缓存命中率通常在 85%-95%。也就是说，你大部分请求只需要付正常价的十分之一。但一旦缓存失效，所有 token 都要按全价重新计算。

这就是为什么额度消耗会突然加速——不是你用多了，是缓存不命中了。

四大缓存杀手

缓存失效不是随机事件，它有明确的触发条件。以下原理适用于所有基于前缀缓存的 AI 编程工具（Codex、Claude Code 等），我按"杀伤力"从大到小排列。

杀手 1：切换模型

这是最致命的操作。

每个模型有独立的 KV Cache，完全隔离。原因很简单：不同模型的架构和权重不同，同样的输入算出来的 KV 张量完全不一样，无法复用。

如果你用 GPT-5.5 跑了 10 万 token 的对话，然后切到 GPT-5.4，5.4 这边的缓存是空的。之前积累的所有缓存瞬间归零，所有 token 重新按全价计算。

正确做法：如果确实需要用不同模型处理不同任务，用 subagent 隔离。主对话保持在一个模型上不动，开一个子任务跑另一个模型，完成后把结果传回来。

杀手 2：中途装新 MCP 或改动工具配置

AI 编程工具发送请求时，内部结构大致是一条从左到右的链：

tools（工具定义） → system（系统提示） → 配置文件内容 → messages（对话历史）

改左边的任何东西，右边全部跟着失效。

装一个新 MCP，tools 数组就多了几个工具定义，整个 tools 层的哈希变了，下面 system 和 messages 的缓存全部连锁失效。

好消息是：MCP 通常只在 session 启动时加载一次，中途装新 MCP 不影响当前 session。真正的杀手是重启 session 或触发配置重载——tools 数组重组，之前的缓存全部白费。

正确做法：开始任务前，一次性把需要的 MCP 都装好。不要干到一半发现少了个工具再装然后重启。

杀手 3：改 AGENTS.md / CLAUDE.md 后重启

和 MCP 同理。AGENTS.md（Codex）或 CLAUDE.md（Claude Code）的内容会注入到请求上下文中，改完文件后如果重启 session，整段上下文重建，缓存失效。

正确做法：任务开始前把配置文件写好。如果中途必须改，接受缓存重建的代价，或者直接开新 session 而不是在旧 session 里挣扎。

杀手 4：空闲时间过长

这个最容易被忽略。

服务器端的缓存有 TTL（存活时间）。以 Anthropic 为例，默认 TTL 是 5 分钟；OpenAI 没有公开具体时长，但机制类似——超过一定时间没有新请求，缓存条目会被清除。不是哈希对不上，是服务器主动删了数据。

你让 AI 跑一个复杂任务，它思考了 3 分钟返回结果，你花 3 分钟检查成果——可能已经超时了。下一次请求，所有上下文重新全价计算。

正确做法：对于 Claude Code 用户，长任务前设置 export ENABLE_PROMPT_CACHING_1H=1，把 TTL 延长到 1 小时（写入成本从 1.25 倍涨到 2 倍，但复杂任务绝对划算）。Codex 用户目前没有手动控制 TTL 的选项，但可以通过避免长时间中断来降低风险——检查结果时随手发一句确认消息，保持 session 活跃。

一个真实的"坑"：第三方 API 用户的缓存为什么归零

这个问题值得单独拿出来说，因为它影响面很大。

我在和做 API 中转的朋友聊天时了解到一个案例：有人花 250 块买了 1000 美元的 Claude API 额度，拿来跑日常编码，不到一天全部烧光。同样的工作量，官方订阅六天才触发限额。成本差了 6 倍。

原因就是中转站的后端架构和 Prompt Cache 天然矛盾。很多中转站用号池轮转——你的请求随机分发到不同账号处理。而缓存是按账号隔离的，第一次请求打到账号 A，缓存在 A 上；第二次打到账号 B，缓存不存在，全价计费。20 个账号的号池，缓存命中概率只有 5%。

还有一个更隐蔽的问题：某些 AI 编程工具会在每个请求的 system prompt 里塞一个随机变化的标识字段，用于追踪请求来源。官方服务器知道跳过这段来算缓存 key，但第三方 API 不知道，老老实实把它算进去，导致前缀每次都不一样，缓存命中率直接归零。这个问题在开发者社区里引发了不小的争议，有人在 GitHub 上提了大量 issue，但官方一直没有正面回应——毕竟他们自己的服务不受影响。

如何判断你的缓存是否生效？ 看 API 响应里的两个字段：

  • cache_creation_input_tokens：首次缓存写入的 token 数
  • cache_read_input_tokens：后续命中缓存的 token 数

如果这两个值始终是 0，不管服务商怎么宣传，你的缓存没有生效。

OpenAI 自己也踩过这个坑

2026 年 5 月，OpenAI 工程负责人 Thibault Sottiaux 在 OpenAI 社区论坛公开承认：Codex 曾有一次内部优化导致长会话中缓存命中率下降，用户额度消耗异常加速。发现后紧急回滚，并重置了所有受影响用户的额度。

这说明两件事：

  1. 缓存命中率确实是额度消耗的决定性变量
  2. 连 OpenAI 自己的工程团队都会不小心搞坏它

为什么后半段特别快？

把上面的知识串起来，"后半段加速"就很好理解了：

  • 前半段：对话短，上下文变化小，前缀稳定，缓存命中率高（90%+），大部分 token 按 1/10 价格计费
  • 后半段：对话变长，你开始切模型、装新工具、改配置、中途去喝咖啡，缓存频繁失效，越来越多的 token 按全价计费
  • 加上非线性效应：对话越长，每次请求的 token 总量越大。同样是缓存 miss，前期 miss 一次可能只多花 1 万 token 的全价，后期 miss 一次可能多花 10 万 token 的全价

这就是为什么体感上"后 40% 两下就没了"——不是消耗速度线性增加，而是指数级恶化。

另一个加速因素：短 prompt 反而更贵

除了缓存失效，还有一个独立的因素在加速消耗，很多人没意识到。

OpenRouter 的真实用户数据分析发现，GPT-5.5 虽然号称输出更简洁，但短 prompt 场景下实际成本涨了接近 92%（The Register 也报道了这一数据）。

这和缓存机制直接相关：OpenAI 的 Prompt Cache 最低需要 1024 token 才触发。如果你的 prompt 很短（几百 token），根本达不到缓存门槛，每次都是全价计费。而 GPT-5.5 对短 prompt 的输出反而变长了（最多涨 52%），两头夹击，单次成本飙升。

这解释了一个常见困惑：为什么有人觉得"我就随手问了几个小问题，额度怎么掉这么快"——因为短交互恰恰是缓存最不友好的场景。

如果你的使用模式偏向短 prompt 高频调用，考虑用 GPT-5.4 或 GPT-5.3-codex——价格只有 5.5 的一半，且对短交互场景更友好。把 5.5 留给真正需要深度推理的长任务。

行动清单

你的情况该怎么做
长任务开始前一次性配好所有 MCP 和 AGENTS.md，不要中途改
需要切模型用 subagent 隔离，主对话不动
用第三方 API检查 cache_read_input_tokens 是否为 0
会话超过 15-20 轮用 /compact 压缩上下文，或开新 session
短 prompt 高频场景把简单问题留给 GPT-5.4 或 5.3-codex
中途需要离开发一句确认消息保持 session 活跃
不确定缓存状态用 /status 查看当前 session 的上下文大小

最后

这个行业里有一种很普遍的情绪：觉得 AI 工具"越来越贵了"。但仔细看数据，很多时候不是工具变贵了，而是我们的使用方式在无意中破坏了本该帮我们省钱的机制。

Prompt Cache 是目前 LLM 领域最重要的成本优化机制之一，但它几乎是"隐形"的——你看不到它在工作，也看不到它什么时候失效了。唯一的信号就是额度条突然加速下降。

现在你知道该看哪里了。