Tokenomics：Claude缓存的62.5分钟法则（8分钟阅读）

# Tokenomics：Claude 缓存的 62.5 分钟法则 来源：https://skids.dev/blog/anthropic-cache-tokenomics/ 刷新 5 分钟缓存、让它过期，或者干脆依赖压缩——哪个更高效？ 不幸的是，作为一名长期“Token 榨取者”的缺点之一，就是经常在多个提供方上触发 5 小时和周度的 Token 限制。这通常发生在最不凑巧的时候——你正忙到一半，而且最好能避免再花更多钱购买额外的 AI 订阅。我开始更仔细地查看自己的请求日志，想看看这是不是技巧问题，结果发现我写入整个上下文（某些会话中可高达 400k/500k）到缓存的频率比我应该做的要高一些。每次写入单独看起来很小，但累积起来很快。 5 分钟其实并不长，所以很容易分心错过缓存刷新，然后支付完整的前缀写入费用。这让我开始思考：如果提示缓存即将过期，而我并没有真正的请求要发送，那么用保活信号 ping 一下更便宜，还是让它过期然后以后再重写？ tl;dr：答案是 **62.5 分钟**。如果你预计在那之前需要再次用到缓存，就刷新它；否则就让它过期。这个数字在不同模型之间不会变化，当缓存前缀从 5K Token 增长到 500K Token 时也不会变化。金额会变，但决策点不变。 ## 数字 https://skids.dev/blog/anthropic-cache-tokenomics/#the-numbers Anthropic 的定价页面（https://platform.claude.com/docs/en/about-claude/pricing）将提示缓存列为一组相对于正常输入 Token 价格的乘数： | 模型 | 基础输入 | 5 分钟缓存写入 | 1 小时缓存写入 | 缓存读取/刷新 | 输出 | |------|---------|----------------|----------------|----------------|------| | Opus 4.7 | $5 / MTok | $6.25 / MTok | $10 / MTok | $0.50 / MTok | $25 / MTok | | Sonnet 4.6 | $3 / MTok | $3.75 / MTok | $6 / MTok | $0.30 / MTok | $15 / MTok | | Haiku 4.5 | $1 / MTok | $1.25 / MTok | $2 / MTok | $0.10 / MTok | $5 / MTok | 所有模型的乘数相同：5 分钟缓存写入费用为基础输入价格的 1.25 倍，1 小时缓存写入为 2 倍，缓存读取为 0.10 倍。 读取操作承担两个任务：命中有存活的缓存的请求按读取费率计费，同时该请求将缓存的 TTL 刷新回 5 分钟，所以缓存命中 = 缓存刷新。 保持缓存温暖的诀窍是在 TTL 耗尽之前发送一个极小的请求来读取缓存的 TTL。成本是该前缀正常输入价格的 10%，但前提是你要一直这样做直到再次需要它。 ## 100K Token 前缀案例研究 https://skids.dev/blog/anthropic-cache-tokenomics/#a-case-study-of-a-100k-token-prefix 以 Opus 4.7 和 100K Token 的缓存前缀为例。这不算巨大的上下文窗口，但很容易达到，因为它通常刚好覆盖系统提示、工具定义、项目草稿以及来自代理会话的一些运行笔记。 将该前缀写入 5 分钟缓存的成本： `` 100K tokens * $6.25 / MTok = $0.625 `` 读取它（同时也刷新它）的成本： `` 100K tokens * $0.50 / MTok = $0.05 `` 如果我让缓存保持活跃 `T` 分钟，我需要支付首次写入，然后每 5 分钟一次读取： `` refresh_cost(T) = W + R * floor(T / 5) `` 如果让缓存过期然后再回来，我需要支付首次写入和第二次写入： `` rewrite_cost(T) = W + W = 2W `` 盈亏平衡点发生在刷新读取累计到一次额外写入的成本时： `` W + R * (T / 5) = 2W R * (T / 5) = W T = 5 * (W / R) = 5 * (1.25 / 0.10) = 62.5 minutes `` 实际边界会有阶梯效应，因为刷新是按 5 分钟块进行的，而不是连续时间。但这并不改变规则，因为大约不到一小时时，刷新总是获胜。超过一小时，继续支付保活税就不再高效。 ## 哪些因素抵消了 https://skids.dev/blog/anthropic-cache-tokenomics/#what-cancels-out 我原本以为答案会依赖于模型或文本大小，但令人惊讶的是，它并不依赖。比较的两边都与模型的基础输入价格和缓存的 Token 数量成比例。更大的前缀使两种策略都更昂贵，Opus 比 Sonnet 更贵，但当你用写入价格除以刷新价格时，这一切都消失了： `` W / R = (N * base * 1.25) / (N * base * 0.10) = 1.25 / 0.10 = 12.5 `` 这就是为什么 62.5 分钟的时间规则对于 5K Sonnet 前缀和 500K Opus 前缀是一样的，但“金钱损失”在两种模型之间会变化。 对于 Opus 4.7 和 Sonnet 4.6 上的 100K 前缀，两对都落在相同的 x 轴上： 刷新与重写累计成本 100K Token 缓存前缀的累计成本（分钟数自上次缓存写入以来）。实线表示 Opus 4.7 和 Sonnet 4.6 的刷新策略；虚线表示重写策略。所有四条线恰好交叉于 62.5 分钟，无论模型或前缀大小。 ``` $0.00 $0.50 $1.00 $1.50 $2.00 0 30 60 90 120 refresh wins let it expire crossover at 62.5 min (same for every model) Refresh vs. rewrite: cumulative cost on a 100K-token cached prefix Opus 4.7 (refresh / rewrite) Sonnet 4.6 (refresh / rewrite) minutes until you need the prefix again total spend on the cached prefix ``` Opus 线位置更高，因为 Opus 每 Token 成本更高，但交叉时间完全相同。 62.5 分钟法则是我想要的，但它并不是定价页面上唯一有用的数字。 **Opus 4.7 对相同固定文本最多可多使用 35% 的 Token。** Anthropic 在模型定价表格下方的注释中指出了这一点：Opus 4.7 使用了新的分词器，相同文本的 Token 数可能增加最多 35%。如果你将缓存的提示从 Opus 4.6 迁移到 4.7，不要假定旧的 Token 计数仍然适用。一个 100K Token 的前缀可能变成 135K Token，每次缓存写入/读取的计算也随之变化。在迁移任何昂贵的内容之前，先通过 Anthropic 的 Token 计数端点（https://platform.claude.com/docs/en/build-with-claude/token-counting）运行提示。 **小前缀不会被缓存。** Opus 4.5、4.6 和 4.7 至少需要 4,096 个可缓存 Token。Sonnet 4.6 需要 1,024 个。如果你的前缀低于下限，API 不会抛出有用的错误。它只是处理请求而不做缓存。唯一可靠的信号是 usage 块：如果 `cache_creation_input_tokens` 和 `cache_read_input_tokens` 保持为 0，那么你的缓存没有起作用。 **回溯窗口是 20 个块。** 每个缓存断点可以向后扫描最多 20 个内容块以查找之前的写入。如果你的代理在缓存命中之间添加了超过 20 个块，你想要的缓存条目可能超出搜索窗口。我遇到过一次，以为请求中的某个字段使缓存失效，但我的请求中有 23 个块，系统在块 20 处停止查找。显式断点文档（https://platform.claude.com/docs/en/build-with-claude/prompt-caching#explicit-cache-breakpoints）显示了修复方法：在需要之前更早地在前缀中添加另一个断点。 ## 金额小，但并非永远如此 https://skids.dev/blog/anthropic-cache-tokenomics/#the-dollars-are-small-until-they-arent 比率与模型无关，但账单高度依赖模型。在 Opus 4.7 上，一个周期是：将缓存写入一次，空闲 `T` 分钟，然后发送下一个真实请求。 | 前缀大小 | 策略 | T = 5 min | T = 30 min | T = 60 min | T = 90 min | |---------|------|----------|-----------|-----------|-----------| | 50K tokens | 刷新 + 在 T 时读取 | $0.338 | $0.463 | $0.613 | $0.763 | | 50K tokens | 在 T 时重写 | $0.625 | $0.625 | $0.625 | $0.625 | | 100K tokens | 刷新 + 在 T 时读取 | $0.675 | $0.925 | $1.225 | $1.525 | | 100K tokens | 在 T 时重写 | $1.250 | $1.250 | $1.250 | $1.250 | | 500K tokens | 刷新 + 在 T 时读取 | $3.375 | $4.625 | $6.125 | $7.625 | | 500K tokens | 在 T 时重写 | $6.250 | $6.250 | $6.250 | $6.250 | 30 分钟时，保持 500K Opus 前缀温暖可节省 $1.625。60 分钟时，仅节省 $0.125。90 分钟时，刷新已成为错误的选择，比让缓存过期多花费 $1.375。节省额在较短的闲置间隔和较大的前缀上最大。正好在交叉点之前，几乎没有钱可以省了。 ## 压缩并非免费的午餐 https://skids.dev/blog/anthropic-cache-tokenomics/#compaction-is-not-a-free-lunch Agent 还会做另一件事：压缩上下文——将不断增长的对话记录交给模型总结，然后从总结继续而不是原始内容。Claude Code、OpenCode 等都有 `/compact` 命令，而且几乎所有 agent 在接近上下文限制时也会自动执行此操作。 假设对话有 `N` 个缓存的输入 Token，总结有 `S` 个 Token。压缩需要三项成本： - 从缓存读取旧的 `N` 个 Token：`N * R` - 生成 `S` 个输出 Token，价格为基础价格的 5 倍：`S * 5B` - 将新的 `S` Token 前缀写回缓存：`S * W` 之后，每个未来轮次将读取 `S` 个缓存的 Token 而非 `N`，每轮节省 `(N - S) * R`。盈亏平衡的未来轮次数为： `` break_even_turns = (N + 62.5*S) / (N - S) = (1 + 62.5*r) / (1 - r), 其中 r = S/N `` 同样，绝对上下文大小抵消，只有压缩比才重要。 该曲线 `(1 + 62.5r) / (1 - r)` 看起来像这样： 自动压缩盈亏平衡 vs 压缩比 需要多少未来轮次才能收回一次压缩操作的成本，绘制成压缩比（总结 Token 除以原始 Token）的函数。当比率接近 1:1 时，盈亏平衡急剧上升。标记了三个参考点：20:1 压缩在 4.3 轮回本，10:1 在 8 轮，5:1 在 17 轮。结果与原始会话大小和所用模型无关。 ``` 0 25 50 75 100 0.00 0.10 0.20 0.30 0.40 0.50 compaction pays off compaction loses 20:1 (~4.3 turns) 10:1 (~8 turns) 5:1 (~17 turns) Auto-compaction break-even vs. compression ratio (model-independent) compression ratio (summary tokens / original tokens) future turns to break even ``` 经验法则大致是 10:1。如果你能将 100K Token 变成 10K Token 的总结，并且预计还有至少八个轮次，那么压缩在 Token 成本上就能回本。20:1 时，大约四个轮次回本。5:1 时，你需要大约 17 个未来轮次。2:1 时，你需要大约 65 个轮次，这已经不是压缩策略，而是一个非常昂贵的 tl;dr。 输出价格是曲线变得难看的原因。缓存读取便宜，总结 Token 是输出 Token，而输出价格是基础价格的 5 倍。一个冗长的总结可能即使技术上减少了提示，也可能造成严格意义上的损失。 还有数字无法显示的质量成本。一个压缩可能丢失十轮前的精确错误消息、分支名称或失败假设，节省了几美分，却可能让 agent 不得不重新发现同样的东西。 ## 捷径在哪里 https://skids.dev/blog/anthropic-cache-tokenomics/#where-the-shortcut-lies 62.5 分钟法则假设你确实会发出另一个请求。如果 30% 的会话只问一个问题就离开，你的期望值计算会变化，正确答案可能是根本不要缓存。交互式编码 agent 通常处于这一线的另一侧。 该法则还假设前缀确实被缓存了。在信任自己的仪器之前，请检查 `cache_creation_input_tokens` 和 `cache_read_input_tokens`。低于最小 Token 下限的缓存，或位于 20 块回溯窗口之外的缓存条目，并不是缓存。它们只是带有美好愿望的更昂贵的提示。