Anthropic缓存命中率低：实际节省分析

Anthropic 上周给我们公司发了封邮件：你们的 prompt 缓存命中率偏低，缓存重复内容"最多可节省 64% 的直接 API 开支"。邮件对范围说得很谨慎——仅限直接 API，不含 Claude Code，因为它自己管理缓存。我去查了一下那个 64% 是怎么算出来的。

我们在此期间的直接 API 流量：16 次调用，总费用 $0.25，平均 prompt 90 个 token。这些调用来自 traceguard 的 rerun 工具，它将独立的咨询记录作为全新的单轮对话回放——每个 prompt 生来就是唯一的。这类负载天然无法命中缓存：调用之间没有重复前缀，而且 90 个 token 远低于 Anthropic 允许缓存的最低门槛（ Opus 4.8 上是 1,024 个 token，这些调用用的就是这个模型； Opus 5 / Fable 5 上是 512 个）。命中率 0%，结构性问题。$0.25 的 64% 是 $0.16。

这个指标是对的。但这钱根本不存在。

邮件排除在外的那一侧

真正有意思的数字在邮件正确排除掉的那部分流量里。我们将自家 Claude Code 的会话日志摄入到 traceguard 的 trace 存储中（Claude Code 的转录不包含费用字段，所以我们从用量中计算标价）。71 天，158 个会话，58,753 条 API 消息。这是命令输出的第一部分，未做任何编辑：

命中率是按 token 加权的；费用仅统计输入侧，按标价计算。两行 n/a 是有意为之——没有公布价格的模型就不猜金额，token 照常统计。

没有人配置过的缓存将输入侧削减了 83.9%。如果算上输出侧，整体账单只有无缓存反事实的 1/5.5 。这里已经没有优化空间了；剩余的开销大部分是真正新内容的一次性写入溢价。

keep-alive ping 的想法

最近流行一种优化手段：定时 ping 你的会话以保持缓存活跃，让下一轮能命中。从机制上讲这可能有效——缓存 TTL 默认 5 分钟，每次命中都会免费刷新一次，1 小时 TTL 的写入成本是 2 倍。但我们没有空谈，而是用自己的间隔数据跑了反事实。

我们会话中间隔在 5 分钟以内的占 97.3%；根本不需要 ping。可优化的空间是 422 个超过 1 小时的间隔：在这之后重建上下文，在 71 天内最多花 $1,913（这是高估，因为它把真正的新内容也算作了重建）。如果每隔 55 分钟 ping 一次来填补这些间隔，需要 6,765 次 ping，单是缓存读取就花 $2,009，还没算 ping 本身产生的输出 token。按对我们有利的假设，这个策略也是亏钱的。

原因很无聊：1 小时 TTL 让 ping 没了用武之地。我们的日志显示 Claude Code 已经把几乎所有缓存写入都写进了 1h 桶里（opus-4-8：1 小时 TTL 写了 155.9M token，5 分钟 TTL 写了 56.4M）。Ping 是扩展 TTL 出现之前的权宜之计。如果某个工具在 2026 年还向你推销自动 ping，先让它用你的日志跑一遍反事实再谈。

读取不等于测量，又来了

写这篇文章的时候我去查了我们的 SDK，发现了和以往多次向其他追踪器报的同一类 bug。traceguard 的 wrap_anthropic 记录 tokens_in = usage.input_tokens。在 Anthropic 的 API 上，input_tokens 不包含缓存读取和写入——而我们的流量中，缓存读取大约是原始输入的 1,000 倍，所以这个包装器少算了三个数量级。每个字段都读取正确，数量依然错了（splitrail #220 模式）。已在 PR #39 中修复，而这个修复是下一部分工作的前提。

没有分母的率不是发现。百分比在邮件里看起来很漂亮，但做决策要看美元。在根据指标邮件采取行动之前，先把它乘以对应的金额。

这个分析现在是一条命令，合并在 PR #40 里：

python -m traceguard.routing_audit.cache_audit

指向你摄入的 Claude Code 转录文件或 traceguard trace 存储，就能得到上表——按模型统计命中率、有无缓存的实际费用对比（按标价）、间隔分布，以及 keep-alive ping 划不划算的结论（我们打印出来是 NOT WORTH IT）。随 traceguard 1.2.0 发布——pip install -U traceguard。我们跑出来的最后一行是这样的：

Claude Code caching already saves us 84% ($12,110.31 vs $75,044.44 list). Checked with: python -m traceguard.routing_audit.cache_audit

如果你跑了这个命令，把你的数字发给我。如果 ping 在某个地方赢了——我很想看看什么样的流量特征会让 ping 合理。