Prompt Cache 写入成本：1.25x 溢价何时回本？
只要在 TTL 内再次读取一次，prompt cache 写入就能回本：写入按输入价格的 1.25x 计费，读取按 0.1x 计费。因此，一次命中就能让两次调用的总成本从溢价 25% 变为节省 32.5%。但在我们的五种 Agent 场景中，同样的溢价却让其中一种场景实测多花了 6%。区别只在一个数字：流量的读写比。本文要解决的，就是如何在账单到来前测出这个比例。以下数据均通过 Synthorai gateway 的实时计费指标测得。Agent 数据来自一套包含 150 个 episode 的测试，TTL 和聚类结果则来自使用不同 salt 的专项探测。
TL;DR
- 显式 cache 写入按 1.25x（5 分钟 TTL）或 2x（1 小时）计费；GPT-5.6 的 breakpoint 也采用相同的 1.25x/0.1x 结构；再次读取一次即可回本。
- 在整套 Agent 测试中，该溢价的净影响从 +6%（RAG，读写比 0.2）到 -83%（批处理，15.7）不等。
- Cache 命中会免费刷新 Claude 的 TTL：持续流量只需在每次空闲间隔后支付一次写入费用，而不是每个 TTL 窗口都支付。
- 隐式 caching 的效果差距很大：GPT-5.5 在一次预热后连续探测 8 次命中 7 次；Gemini 即使将请求聚在一起，每 12 次也只命中 1–3 次。两者都没有写入溢价。
一次 cache 写入到底要花多少钱？
我们对比的 provider主要有三种定价模式，其中两种对写入收费。Claude 的显式 caching 中，默认 5 分钟 TTL 的 cache 创建费用是输入价格的 1.25x，1 小时档为 2x，读取则为 0.1x；GPT-5.6 改用了显式 breakpoint，写入和读取的倍数同样是 1.25x 和 0.1x。现在，业界规模最大的两个显式实现已经采用相同定价。第三种是隐式 caching（Gemini、Kimi 和 5.6 之前的 OpenAI 模型）：写入完全不加价，只有 provider 实际命中时，读取才会打折。
显式写入的盈亏平衡计算很简单。假设 prefix 有 P 个 token，不使用 cache 时按正常价格计算，成本为 P。写入 cache 后，首次调用成本为 1.25P；TTL 内每次再次读取的成本为 0.1P，而不是 P。只需再次读取一次，两次调用的总成本就是 1.35P，未使用 cache 则为 2P，相当于节省 32.5%。此后每次命中都能节省 90% 的 prefix 成本。真正的风险不在溢价，而在于写入后再也没有读取的 block。这个风险完全取决于 workload 的形态。
写入溢价什么时候会亏钱？
当 prefix 的变化速度快于重复速度时。我们在五种 Agent 场景中测量了读写 token 比例，使用相同模型和相同的标记方式，然后按照 1.25x/0.1x 的价格计算 caching 的净影响：
| 场景 | 读写比 | 相比不使用 caching 的净影响 |
|---|---|---|
| 批处理（指令稳定，任务很多） | 15.7 | prefix 支出 -83% |
| 长对话（历史记录不断增长） | 6.8 | -75% |
| Tool loop / tooling | 5.4 | -72% |
| RAG（检索文档位于 prefix 中） | 0.2 | +6%：使用 caching 反而更贵 |
| 整套测试 | 3.5 | -64% |
最需要记住的是 RAG 这一行。每次查询检索出的文档都不同，因此每次调用都会重新写入一段下次无法复用的 prefix：每读回 1 个 token，就写入了 5 个 token，1.25x 的溢价最终造成净亏损。这里没有配置错误，只是这种 workload 无法摊薄写入成本。解决办法是分层，而不是完全禁用 caching：标记在不同查询之间保持稳定的 system prompt 和 tool 定义，把检索文档放在最后一个 breakpoint 之后，不做标记。所有易变内容都应这样处理，包括时间戳、用户名和单次请求的上下文。还要注意会悄悄让 prefix 失效的设置：如果每个 turn 都改变 output_config.effort，prompt 会被重新渲染，cache 也会失效。因此，在同一个 cached session 中，effort 应保持不变。我们的 LangChain 研究也发现了同类框架侧问题：有些 builder 让“全部标记”和“正确标记”一样容易。
写入费用实际多久会再次产生？
每次空闲间隔后一次，而不是每个 TTL 窗口一次，因为命中会免费刷新计时。我们使用一段加了 salt、长度为 4,981 个 token 的 prefix，在 Claude Opus 4.8 上验证了这一点：
| 调用 | 时间 | Cache 写入 | Cache 读取 |
|---|---|---|---|
| 1 | t=0 | 4,981 | 0 |
| 2 | +3 分钟 | 0 | 4,981 |
| 3 | +6 分钟 | 0 | 4,981 |
| 4 | +9 分钟 | 0 | 4,981 |
| 5 | 静默 7 分钟后 | 4,981 | 0 |
第 4 次调用早已超过最初的 5 分钟 TTL，但仍然完整命中，因为第 2、3 次调用都免费延长了有效期；只有静默 7 分钟后才需要重新写入。实际效果是：只要某条 route 的请求间隔始终短于 TTL，写入溢价就只是一次性成本，5 分钟档的表现与永久 cache 无异。1 小时档适用于另一类流量：写入按 2x 计费，并通过 gateway 验证会进入独立的 ephemeral_1h_input_tokens 计费 bucket。与其在每个空闲间隔后反复支付 1.25x，不如一次支付 2x；只要能避免一次重新写入，1 小时档就更划算。因此，它适合空闲间隔在 5 分钟到 1 小时之间的 route。静默超过 1 小时后，两种档位都无法跨 run 保留 cache。定时任务应按单次 run 内的行为估算成本：cron 每次只发一个请求，写入 cache 没有收益；如果一次 cron 会扇出大量使用相同 prefix 的请求，它本质上就是批处理，cache 行为也完全相同。
能否通过调整流量形态改善隐式 caching？
这完全取决于具体的隐式 cache，因为 best-effort 的效果差距很大。表现较好的一端是 GPT-5.5 的自动 caching，它的行为更像一个稳定机制：预热一次后，cache entry 在 2 秒后即可读取。我们尝试的两种 salt 中，首次探测都命中。随后的一轮突发请求里，8 次探测有 7 次从 cache 读取了 5,170-token prompt 中的 4,864 个 token，而且完全没有写入溢价。这是真正的无成本收益，只需发送两次相同 prefix。另一端则是 Gemini 3.6 Flash：在同一套 Agent 测试中，显式 caching 覆盖了 Claude 77–78% 的输入 token，而 Gemini 的隐式 cache 只覆盖了 4%，尽管这些 workload 确实存在重复 prefix。
我们尝试通过调整流量形态来改善表现较差的一端：把相同 prefix 的调用聚在一起，尽量保持 provider 的 cache 仍处于 warm 状态。Gemini 3.6 Flash 连续执行 12 次调用，只命中 1 次，即第 10 次；第 11 次又未命中。按 3 分钟间隔执行 8 次调用则一次都没命中。为排除偶然性，我们在第二条独立请求路径上重新执行了聚类测试，并对 Gemini 3.5 Flash 做了同样测试。两者分别命中 3/12 和 1/12，连续命中从未维持多久；唯一成功缓存的 block 在两条路径上返回的 token 数都相同，均为 4,073。机制是一致的，命中概率却不稳定。
部分未命中来自写入延迟，而且不同 provider 的延迟差异很大：GPT-5.5 的 entry 在预热 2 秒后即可读取，而 Gemini 需要几十秒才能建立 cache。因此，第一次调用后立即发起的突发请求会跑在 cache 前面。我们的所有 Gemini 测试中，都没有任何一组在第 4 次调用前命中。先预热 prefix，等待 45 秒再发起突发请求后，命中率提高到 3/8，这是所有流量调整方式中的最好结果；但等待 90 秒后却是 0/8，等我们回来时，entry 已经消失。几天前，同一模型在更长时间的预热扫描中还能持续命中，说明命中率也会随时间和负载漂移。综合建立延迟、较短的存活时间和命中率漂移，聚类对表现较差的实现只能算略有帮助：命中 3 次总比 1 次好。（测试时应注意：探测隐式 cache 时，需要控制调用节奏并加入“预热后等待”的实验组；还应通过预热后的阶梯式探测测出建立延迟。连续调用测到的是请求速率，不是 cache 本身。）
因此，可靠的判断标准应针对 provider，而不是 caching 机制：先测清你的 provider 更接近 GPT-5.5（预热后可以信任），还是更接近 Gemini（任何命中都只当作额外返利）。Kimi K3介于两者之间：没有溢价，存在较低的最低门槛，无需配置即可让输入中的 57–62% 由 cache 提供。还有一个数据点很能说明哪种方式更有优势：OpenAI 拥有我们测过的最佳隐式 cache，却仍然在 GPT-5.6 中改用显式 breakpoint，把不由客户控制的随机优惠换成由客户自行标记的确定性机制。
哪些 workload 能摊薄写入溢价？
根据读写比和空闲间隔做决定。这两个数字都可以在正式采用前从自己的 usage 记录中获得：
| Workload | 结论 | 原因 |
|---|---|---|
| 多轮 Agent session | 使用 cache | 每个 turn 都会重新读取历史记录；整套测试的总体 R:W 为 3.3–3.6 |
| 共享 system prompt，QPS 稳定 | 使用 cache，5 分钟档 | 请求间隔 < TTL，意味着只写入一次，此后命中会免费刷新 |
| 突发 session，间隔 5–60 分钟 | 使用 cache，1 小时档 | 一次支付 2x，优于每个间隔后支付 1.25x |
| 使用相同指令的批处理任务 | 使用 cache，并将任务聚在一起 | 实测 R:W 为 15.7，成本 -83%；聚类可让 TTL 窗口保持有效 |
| 文档频繁变化的 RAG | 分层处理 | 只标记指令和 tool；文档放在最后一个 breakpoint 之后 |
| 每次 run 只有一个请求的定时 cron | 跳过 | 每次 run 间隔数小时，每次写入都会在读取前过期 |
| 每次 run 包含多个请求的定时 cron | 在 run 内使用 cache | 一次 run 就是一批任务：首个请求写入，其余请求读取；命中会让 TTL 在整个 run 期间保持有效 |
| 低于最低门槛的 prompt | 跳过 | 低于各模型的 cache 最低门槛时，本来就不会缓存 |
计费数据给出两条结论。第一，应根据自己的 usage 明细中 cache_read 与 cache_creation 的比例判断 caching 是否有效，而不是凭命中是否频繁的主观感受。RAG 场景看起来很适合 cache，实测比例却只有 0.2。第二，如果读写比健康，溢价几乎可以忽略。整套测试的读写比为 3.5，即使计入所有写入费用，prefix 支出仍下降了 64%。
常见问题
RAG 值得使用 prompt caching 吗？
检索出的文档不值得。在我们的实测中，RAG 每读回 1 个 token 就写入 5 个 token，1.25x 的溢价最终造成 6% 的净亏损。应缓存稳定层，也就是 system prompt 和 tool 定义，并把检索内容放在最后一个 breakpoint 之后；完整的 caching 指南详细介绍了 prompt 分层。
应该使用 5 分钟还是 1 小时 cache TTL？
应根据空闲间隔选择，而不是 session 时长。命中会免费刷新 5 分钟 TTL，因此，只要 route 的请求间隔小于 5 分钟，就永远不需要重新写入，较便宜的档位实际上可以无限持续。只有当空闲间隔在 5 分钟到 1 小时之间时，才值得支付 1 小时档的 2x 写入费用；只要能避免一次 1.25x 的重新写入，它就更划算。如果间隔超过 1 小时，估算成本时应按完全没有 cache 处理。
隐式 caching 会收取写入费用吗？
不会，从机制上也无法这样收费：只有调用方主动选择写入时，写入溢价才合理。因此，溢价只存在于显式 caching 中，包括 Anthropic 的 1.25x/2x 倍数、GPT-5.6 的 breakpoint，以及 Gemini 等显式 cached-content API 按 token-hour 收取存储费的模式。我们实测的所有隐式实现（Gemini、Kimi、5.6 之前的 OpenAI）以及所有主流公开价目表（DeepSeek、Qwen、Grok），都只对隐式 cache 的读取提供折扣。区别在于可靠性：GPT-5.5 的隐式 cache 在预热后的 8 次探测中持续命中 7 次，而 Gemini 在我们的 Agent 测试中只覆盖了 4% 的输入，聚类也几乎没有改善。可靠获得且没有溢价的折扣当然最好；如果折扣随机出现，它的价值还不如一个可以自行控制、但有少量溢价的机制。
数据于 2026-07-25 至 2026-07-29 通过 Synthorai gateway 测得：场景读写比来自 Claude 测试组的 150 个 Agent episode，并按每次调用拆分 cache 明细（Gemini 和 Kimi 的占比来自各自的测试 run）；TTL 刷新和 1 小时 bucket 探测使用 claude-opus-4-8（加入 salt 的 4,981-token 和 3,742-token prefix）；隐式 cache 探测使用 gemini-3.6-flash 和 gemini-3.5-flash（加入 salt、约 6,800-token 的 prefix；包含聚类、分散及预热后等待的实验组）以及 gpt-5.5（加入 salt 的 5,170-token prompt，预热后突发调用）。净影响百分比根据实测比例，按 1.25x 写入 / 0.1x 读取倍数计算。价格和 cache 行为可能变化，请以自己的 usage 记录为准。