8.0
热点
AI SCORE
技术实践2026-04-12 13:45
Anthropic 降低 Cache 缓存有效期
Hacker News · github.com#Anthropic#Claude API#成本
Editor brief · 编辑速览
Claude API 的 prompt cache TTL 被降级，直接影响缓存策略和成本优化方案。
根据跨越 2026 年 1 月 11 日至 4 月 11 日的 Claude Code 会话 JSONL 文件原始数据分析，Anthropic 似乎在 2026 年 3 月初的某个时间段内，将 prompt cache TTL 默认值从 1 小时无声地降低至 5 分钟。在此变更之前，Claude Code 接收到的是 1 小时 TTL 的缓存写入——我们认为这是预期的默认值。降低至 5 分钟 TTL 导致缓存创建成本增加了 20-32%，并导致从未触及过配额上限的订阅用户的配额消耗出现可测量的激增。
这似乎与 #45756 中描述的行为直接相关。
会话数据提取自两台机器（Linux 工作站 + Windows 笔记本电脑，不同账户/会话）的 ~/.claude/projects/ JSONL 文件，共计来自 2026 年 1 月 11 日至 4 月 11 日的 119,866 个 API 调用。每条助手消息都包含 usage.cache_creation.ephemeral_5m_input_tokens / ephemeral_1h_input_tokens 分解，使得每次调用的 TTL 层级可观测。拥有两台独立机器加强了信号强度——两者都在相同日期显示出相同的行为变化。
我们认为第二阶段代表 Anthropic 的预期默认行为——1h TTL 大约在 2 月 1 日前后作为 Claude Code 标准推出，在两台独立机器和两个不同账户上持续保持了一个多月。1 月的全 5m 数据很可能早于 1h TTL 层级在 API 中可用。回归大约从 2026 年 3 月 6-8 日开始。
在这些阶段之间，客户端没有进行任何更改。始终使用相同的 Claude Code 版本和使用模式。TTL 层级由 Anthropic 在服务器端设置。
Date | 5m-create | 1h-create | Behavior
------------|------------|------------|----------
2026-02-01 | 0.00M | 1.70M | 1h ONLY ← 1h default begins
2026-02-09 | 0.00M | 7.95M | 1h ONLY
2026-02-15 | 0.00M | 13.61M | 1h ONLY ← heaviest day, 100% 1h
2026-02-28 | 0.00M | 16.15M | 1h ONLY ← 16M tokens, still 100% 1h
2026-03-01 | 0.00M | 0.12M | 1h ONLY
2026-03-04 | 0.00M | 8.12M | 1h ONLY
2026-03-05 | 0.00M | 6.55M | 1h ONLY ← last clean 1h-only day
| | |
2026-03-06 | 0.29M | 0.22M | MIXED ← first 5m tokens reappear
2026-03-07 | 4.56M | 0.50M | MIXED ← 5m surging
2026-03-08 | 16.86M | 3.44M | MIXED ← 5m now dominant (83%)
2026-03-10 | 10.55M | 0.51M | MIXED
2026-03-15 | 19.47M | 1.84M | MIXED
2026-03-21 | 21.37M | 1.70M | MIXED ← 93% 5m
2026-03-22 | 13.48M | 2.85M | MIXED
这种转变在日期粒度上是可见的：3 月 6 日是 5m tokens 在 33 天的纯 1h 行为之后首次重新出现。到 3 月 8 日，5m tokens 的数量比 1h 高出 5 倍。这与被逐步推出的服务器端配置更改一致，并在 3 月 8 日前后完成。
应用官方 Anthropic 定价（rates.json，更新于 2026-04-09）：
合并数据集（119,866 个 API 调用，两台机器）：
claude-sonnet-4-6（cache_write_5m = $3.75/MTok, cache_write_1h = $6.00/MTok, cache_read = $0.30/MTok）：
claude-opus-4-6（cache_write_5m = $6.25/MTok, cache_write_1h = $10.00/MTok, cache_read = $0.50/MTok）：
Anthropic 默认为 1h TTL 的 2 月份，仅显示 1.1% 的浪费（来自一台机器的一天内的微量 5m 活动）。其他每个月份都显示因 5m 缓存重新创建导致的 15-53% 的超额支付。成本差异完全由 TTL 层级解释，而不是由使用量解释。百分比浪费在模型层级之间是相同的（17.1%），因为它完全由 5m/1h token 分割驱动，而不是由每个 token 价格驱动。
使用 5m TTL 时，任何超过 5 分钟的会话暂停都会导致整个缓存上下文过期。在下一轮，Claude Code 必须以写入速率将该上下文作为新的 cache_creation 重新上传，而不是以读取速率进行 cache_read。对于 Sonnet，写入速率比读取速率贵 12.5 倍，相同的比例也适用于 Opus。
对于长编码会话——这是 Claude Code 的主要使用场景——这会产生复合惩罚：会话越长、越复杂，缓存的上下文就越多，每次缓存过期就变得越昂贵。
在分析的 3 个月期间内：
Pro/订阅计划的用户受配额限制，而不仅仅是成本限制。缓存创建 tokens 按全速率计入配额；缓存读取便宜得多（确切的系数正在 #45756 中调查）。3 月份无声地回归到 5m TTL 很可能解释了为什么订阅用户开始首次触及他们的 5 小时配额限制——包括此问题的作者，他在 2026 年 3 月之前从未触及过配额限制。
数据强烈表明 1h TTL 是 Claude Code 的预期默认值，并且截至 2026 年 2 月初已经到位。在 2026 年 2 月 27 日至 3 月 8 日之间的某个时间，Anthropic 无声地将默认值更改为 5m TTL——要么是作为成本节约措施的有意为之，要么是作为基础设施回归的意外结果。
支持"1h 是预期默认值"的证据：
最可能的事件序列：
33 天的纯 1h 行为窗口（2 月 1 日 - 3 月 5 日）跨越两台独立机器和两个单独账户，使这成为 1h TTL 是 Anthropic 有意默认值而非侥幸的最强可用信号之一。
确认或否认 Anthropic 在 2026 年 2 月初进行了服务器端 TTL 默认值更改，并在 2026 年 3 月初进行了回退
澄清 claude-code 会话的预期 TTL 行为——5m 是预期的默认值，还是 1h 打算成为永久的？
考虑恢复 1h TTL 作为 Claude Code 会话的默认值，或将其公开为用户可配置的选项。5m TTL 对于定义 Claude Code 使用的长会话、高上下文使用场景的惩罚是不成比例的
披露 cache_read tokens 的配额计数行为（参考 [BUG] Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage #45756），使用户能够对其使用模式做出明智的决定