Claude 偷偷涨价了：一个隐藏在缓存里的 AI 成本陷阱
上周五，一个开发者打开了 Anthropic 的账单页面，愣住了。
Claude API 费用比上个月涨了近 26%。他的第一反应——我是不是哪里写了死循环？花了两天排查代码，重新审计每一条 prompt，换了台电脑跑测试。结果一切正常。
直到他翻出 Claude Code 本地的 JSONL 会话日志，逐条比对 API 返回的 usage 字段，真相才浮出水面。
Anthropic 在 3 月初悄悄把 prompt cache 的 TTL 从 1 小时降到了 5 分钟。没有公告，没有邮件，没有 changelog。
这件事在 GitHub 上炸了锅。Hacker News 417 分、318 条评论，开发者社区的愤怒值拉满。
缓存为什么这么重要？
先说背景。Anthropic 的 API 有 prompt caching 机制：你发给 Claude 的上下文如果在 TTL（存活时间）内再次请求，走缓存读取而不是重新写入。关键在价格差——缓存读取是写入的 1/12.5。Sonnet 写入 $3.75/百万 token，读取只要 $0.30。
说人话就是：缓存命中，你省 90% 以上；缓存过期，全价重来。
<figure><img src=“images/01-cache-ttl-cost.png” alt=“缓存TTL对成本的影响”></figure>
数据说了什么？
GitHub 用户 cnighswonger 做了一件硬核的事。
他从两台机器（Linux 工作站 + Windows 笔记本，不同账号）提取了 1 月 11 日至 4 月 11 日的全部会话日志——119,866 次 API 调用，逐一分析每次请求的缓存 TTL 层级。
数据讲了一个没有歧义的故事：
- 2 月 1 日 – 3 月 5 日：100% 走 1 小时 TTL，连续 33 天无例外
- 3 月 6 日：5 分钟 TTL 的 token 突然重新出现
- 3 月 8 日起：5 分钟 TTL 占主导，1 小时成为少数派
两台机器，两个账号，33 天的 100% 一致行为，然后突然翻转。这不是噪声，是服务端配置的静默切换。
钱去哪了？
用 Anthropic 官方定价算一笔账。以 Sonnet 4.6 为例：
- 2 月（1h TTL）：$1,120 实际花费，浪费率 1.1%
- 3 月（5m TTL）：$2,776 实际花费，浪费率 25.9%
- 3 月比 2 月多付了 $719，纯粹因为缓存策略变化
如果用 Opus 模型，三个月累计多付 $1,581。
<figure><img src=“images/02-cost-comparison.png” alt=“每月成本对比”></figure>
5 分钟 TTL 为什么这么致命？因为 Claude Code 是长会话场景。你写代码、思考、查文档、喝杯咖啡回来继续。5 分钟窗口意味着：你去倒杯水，缓存就过期了。下一次对话，整个项目上下文（几十万 token）要以写入全价重新上传。
数据佐证：220M token 被写入 5 分钟缓存层，这些 token 后来产生了 57 亿次缓存读取——它们被频繁使用。如果在 1 小时层，大部分重访就是 $0.30/MTok 的读取，而不是 $3.75/MTok 的重写。
不只是钱：配额也崩了
订阅用户（Pro/Max 计划）遭遇了另一击：配额耗尽速度暴增。
缓存写入按全价计入配额，读取的配额消耗低得多。TTL 缩短意味着更多写入、更快的配额消耗。issue 作者说，他在 3 月之前从未触碰过 5 小时配额上限，3 月开始第一次撞上了。
HN 上有用户评论：
“Anthropic is leaving so much evidence around… proving damages and a pattern is becoming trivial.”
还有人更直白：
“They’re vibe coding their infrastructure and they vibe coded their response to the increased load.”
核心问题：你的成本模型建在沙子上
这件事最该关注的不是"Anthropic 是不是偷偷涨价"——虽然没通知确实不体面。
真正的问题是：prompt caching 的 TTL 从来没有 SLA。
翻遍 Anthropic 的文档，找不到任何地方承诺"缓存 TTL 保证为 X"。它是一个实现细节，一个随时可以被修改的优化参数。但无数开发者把它当成了成本模型的基石。
这就像在免费停车场旁边开店，把"免费停车"写进了商业计划书。停车场一收费，利润模型就崩了。问题不在停车场——在于你把别人的善意当成了自己的权利。
<figure><img src=“images/03-infra-dependency.png” alt=“基础设施隐性依赖”></figure>
这不是 Anthropic 独有的问题。所有 AI API 都有类似的"隐性参数"：
- 速率限制：文档说 “up to X requests/min”，实际执行随时可能收紧
- 模型版本：同一个 model ID 背后的模型可能被静默更新
- 缓存策略：TTL、容量、淘汰策略——全由服务端控制
当产品建立在这些没有 SLA 的参数之上，你本质上是在裸泳。
四个实际建议
骂 Anthropic 没什么用（虽然该骂）。更实际的做法：
1. 监控实际缓存命中率。 定期从 API 返回的 usage 字段提取 cache_creation 和 cache_read 比例，设告警阈值。cnighswonger 开源了分析工具 claude-code-cache-fix，可以直接用。
2. 成本预算留安全边际。 如果你的测算假设 80% 命中率，至少按 40% 做压力测试。TTL 可以变，预算不能变。
3. 评估多供应商策略。 不是说换掉 Claude，而是算清楚：如果明天缓存完全失效，你的成本会涨多少？你能不能扛住？
4. 推动供应商正式承诺。 GitHub issue 已经在推动 Anthropic 明确回应。参与讨论，要求把缓存 TTL 写进 SLA 或至少写进 changelog。
写在最后
AI 行业有一个值得玩味的现象：每家公司都在高调"降价"，但很多开发者的账单悄悄涨了。
这不一定是阴谋论。更可能的解释是：你的用量在增长，而那些让你省钱的隐性机制（比如缓存 TTL）也在被悄悄收回。一手给你 discount，一手收走 discount 的前提。
最终你看到的是一个更低的单价，和一个更高的总账单。
AI 越"便宜"，你越需要关注隐性成本。 这不是焦虑，这是常识。
来源
- GitHub Issue: anthropics/claude-code#46829 — 缓存 TTL 回退的完整数据分析（cnighswonger, 2026-04-12）
- Hacker News 讨论: 417 points, 318 comments（2026-04-12）
- Anthropic API 定价: rates.json (updated 2026-04-09)
- 分析工具: cnighswonger/claude-code-cache-fix (GitHub)