4月12日，一位名叫 seanGSISG 的开发者向 Anthropic 的 Claude Code 仓库提交了一个 issue，标题是：
"Cache TTL silently regressed from 1h to 5m around early March 2026, causing quota and cost inflation"
翻译过来就是：2026年3月初，缓存TTL被悄悄从1小时退化成了5分钟，导致配额消耗和费用大幅上涨。
这不是一篇情绪化的抱怨帖。这是一份基于真实数据的调查报告。
作者从两台不同机器（一台 Linux 工作站 + 一台 Windows 笔记本，不同账号、不同会话）中提取了 Claude Code 的原始 session JSONL 文件，时间跨度从2026年1月11日到4月11日，总计 119,866 次 API 调用。这些数据里包含了每次请求的缓存类型明细——ephemeral_5m_input_tokens（5分钟缓存）和 ephemeral_1h_input_tokens（1小时缓存），两种缓存类型的比例直接暴露了服务器端 TTL 的设置。
作者把数据分成了四个阶段：
第一阶段（1月11日 - 1月31日）：只有5分钟缓存。 1小时缓存的字段完全为零。作者认为这个阶段很可能是因为 1小时 TTL 缓存层级还没有在 API 中开放，所以这个阶段的数据参考意义不大。
第二阶段（2月1日 - 3月5日）：只有1小时缓存。 在整整33天多的时间里，两台机器上的 ephemeral_5m_input_tokens 始终为零，ephemeral_1h_input_tokens 始终大于零，几乎没有例外。作者认为这就是 Anthropic 原本设定的默认行为——Claude Code 使用 1小时 TTL 缓存。
第三阶段（3月6日 - 3月7日）：过渡期。 5分钟缓存的 token 开始重新出现，但量还很小，1小时缓存仍然存在。
第四阶段（3月8日 - 4月11日）：5分钟缓存占主导。 5分钟缓存的 token 数量大幅飙升，1小时缓存变成了少数或完全消失。
整个行为变化的时间点精确指向 2026年3月6日左右。在此之前一个多月，Claude Code 稳定地使用 1小时缓存；在此之后，悄无声息地切换回了 5分钟。
这个变化带来的直接后果是：缓存失效频率提高了12倍，相同会话长度下需要更频繁地重新写入缓存，而缓存写入的成本远高于缓存读取。结果是缓存创建成本增加了20%到32%，许多原本从未触达配额的订阅用户开始莫名其妙地用光额度。
Anthropic 的回应：Jarred-Sumner 的技术解释
4月12日当天，Jarred-Sumner（Anthropic 员工）在 issue 下发表了一份详细回应。他的核心论点是：这次改动让 Claude Code 更便宜，而不是更贵。
他的解释逻辑大致如下：1小时 TTL 并不总是等于更低的成本。如果一个请求的结果在1小时内只被访问了一次（即"一次性调用"），那么使用 1小时 TTL 反而会产生更多的缓存写入 token，而缓存写入是要收费的。5分钟写入费用约为 $3.75/MTok，1小时写入费用约为 $6.00/MTok。对于一次性调用场景，5m TTL 的写入成本更低。改成 5分钟 TTL 之后，这类一次性调用的缓存写入量减少，总成本反而下降了。
他进一步解释说，Claude Code 的请求构成中包含大量一次性调用，服务器端在每个请求级别做了 TTL 优化选择（即某些请求用 5分钟，某些用 1小时），目的是降低用户的总体成本。
这个解释在技术上可能是成立的。但社区的反应几乎一边倒地不买账。
社区的愤怒：不只是技术问题
开发者们的不满远不止"成本上升"这一个点。
第一，也是最核心的：悄无声息。 没有任何公告，没有任何说明。用户突然发现自己的配额消耗速度翻倍，第一反应是怀疑自己使用方式出了问题，花了大量时间去排查。直到有人从海量 API 日志里挖出真相，Anthropic 才不得不出来解释。
第二，对订阅用户不公平。 一位用户在评论中写道："我已经付了月费，钱已经进了 Anthropic 的账户。所谓的'降低总成本'对他们来说是好事，但对我这个已经付了固定月费的用户来说，我看到的是我的配额在1小时内就用光了，不得不等待4小时才能继续工作。这实际上让产品变得无法使用。"
第三，混淆了 API 用户和订阅用户的关系。 有人在评论中指出，API 用户和订阅用户走的是不同的计费通道，不应该用 API 的成本逻辑来为订阅服务的体验下降辩护。API 用户按量付费，成本下降确实是好事；但订阅用户付的是固定费用，享受到的服务质量反而下降了，这中间的逻辑并不相通。
第四，这种做法在消耗信任。 一位 Hacker News 用户说得最为直接："你们悄悄改了规则，让用户花大量时间去排查自己是不是做错了什么。当他们终于发现是被'暗改'之后，他们再遇到任何问题都无法判断到底是自己的错还是又被悄悄改了什么。这种信任一旦失去，很难挽回。"
还有用户直接用了"经典骗局手法"（classic scammer tactics）来形容这次行为——先用优惠吸引用户，然后悄悄削减好处。
技术层面的深层问题
从技术角度，这次事件暴露了一个更深的问题：Claude Code 对用户来说是一个黑盒。
用户无法直接观察到 TTL 设置的变化，只能通过 API 返回数据中的 token 类型分布来推断。而这个信息需要用户主动去挖掘自己的 session 日志，普通用户根本不会这么做。这意味着 Anthropic 可以在不告知用户的情况下，随时调整影响用户体验的核心参数。
一位用户（spm1001）提供了独立的数据验证，在另一套设备上得出了完全一致的结论——时间线吻合，数据模式吻合。这说明这不是某个用户的个别现象，而是系统级的行为变化。
更令人不安的是，他的数据还揭示了一个新发现：Vertex API 账号始终是 5m——完全不受1h TTL 影响，这进一步证明 TTL 选择是在请求到达服务器后由服务端决定的。
舆论蔓延：从技术社区到更广泛的质疑
在 Hacker News 的讨论中（530 points / 405 comments），用户的关注点已经超出了这次 TTL 事件本身。
有人开始把 Anthropic 的近期动作串联起来：限制使用场景、夸大模型能力、在压力下改变行为……这些变化单独看可能都有各自的"合理理由"，但放在一起，用户开始感觉自己购买的产品和最初承诺的不再是同一个东西。
一位用户（davidkuennen）提到，他一周前从 Claude 切换到了 OpenAI 的 Codex，"体验令人惊叹"。这种"用脚投票"的现象在社区讨论中不止一次出现。
也有用户提到了更宏观的背景：在最近的 Dwarkesh 播客中，Anthropic 表达过对算力成本的担忧。这或许能部分解释为什么要做这样的优化——公司可能正在面临算力供给紧张的压力。但这显然不是可以在不通知用户的情况下悄悄削减服务的理由。
4月13日新进展：事态仍在发酵
issue 在4月12日被关闭为"not planned"之后，事态并未平息——4月13日出现了多个重要更新。
seanGSISG 主动纠正自己的数据
seanGSISG 在4月13日主动在 issue 下更正了自己的计算。他分离了主会话和子代理会话后发现：
- 主会话：46,376 次调用，5m tokens 35.3M，1h tokens 165.1M，读:写比 21.8:1，占总调用 38.7%
- 子代理：73,490 次调用，5m tokens 239.8M，1h tokens 134.5M，读:写比 9.1:1，占总调用 61.3%
87% 的 5m tokens 来自子代理会话。 子代理的中位间隔只有1.4秒——它们的缓存在5分钟内几乎不会过期，因此5m TTL 实际上为它们省钱。
修正后的数字：
- 子代理5m节省：239.8M tokens，约 -$539.63（相比1h写入）
- 主会话5m浪费：35.3M tokens，约 +$121.64（上限）
- 净节省：约 $418
seanGSISG 明确表示："原始的 $949 数字是错误的，我只是想把它记录下来。"这种主动纠错的姿态赢得了社区的广泛尊重。
bcherny 的补充说明
同日，另一位 Anthropic 工程师 bcherny 补充了更多信息：
- 1h 缓存对订阅用户已经在 rollout——在多个地方针对部分查询类型默认启用了1h TTL，但并非全局默认
- API 用户暂时不会默认获得 1h——"还需要更多测试来确保这是平均净改善"
- 子代理保持 5m 是合理的——"子代理很少被恢复，所以支付1h费用对它们没有好处"
- 关于遥测关闭导致5m的问题——这是 #45381 问题的根源：当遥测关闭时，实验门控不生效，Claude 读取客户端默认值（5m），而不是服务端下发的实验配置
- 即将推出环境变量控制——将提供
CLAUDE_CACHE_TTL=1h或5m之类的环境变量，让用户强制指定
社区进一步将需求拆分出来作为独立 issue 追踪：
- #47098：要求暴露 TTL 配置选项
- #47107：要求添加环境变量控制缓存 TTL
总结
这次事件并不复杂：Anthropic 在3月初把 Claude Code 的缓存 TTL 从 1小时悄悄改回了 5分钟，导致订阅用户的配额消耗速度大幅上升。他们后来解释说这是为了优化成本，但拒绝恢复原来的设置，并关闭了这个 issue。
真正让开发者社区感到愤怒的，不是参数调整本身，而是调整的方式：没有公告、没有说明、没有任何预警。当用户主动挖出真相后，得到的回应是技术解释，而非道歉或承诺改进。issue 被关闭，标记为"不计划修复"。
对于那些已经付费的订阅用户来说，这已经不是成本优化的问题，而是一个关于"我所购买的服务到底是什么"的根本性信任问题。Claude Code 曾经是一个能"一次搞定"原型实现的工具，现在即使给出完整的规格说明和详细计划，也很难完成工作了。这条从好用到不好用的轨迹，才是社区情绪背后真正的心结。
不过也有值得关注的积极信号：seanGSISG 主动纠正自己数据的态度赢得了尊重；bcherny 的补充说明展示了更细致的 rollout 计划；相关功能请求（环境变量控制 TTL）已经被作为独立 issue 追踪。这些是否意味着 Anthropic 正在认真对待社区反馈，还有待观察。
GitHub Issue #46829：https://github.com/anthropics/claude-code/issues/46829