#人工智能 Claude Code 将缓存时间从 1 小时改成 5 分钟可能增加使用成本,但开发团队称这是降低成本的优化措施。开发者认为更快过期的缓存会让 CC 需要频繁输入更多上下文,1 小时过期反而会更好,CC 开发团队则表示很多数据输入一次就不需要了,长时间不清理反而会增加成本。查看详情:https://ourl.co/112632
日前开发者 @seanGSISG 提交问题报告指出 Claude Code 从 2026 年 3 月 6 日开始将缓存生存时间 (TTL) 从 1 小时修改为 5 分钟,也就是缓存过期时间会更快,这可能导致使用成本显著上升。
缓存过期时间主要用来控制多长时间内使用缓存数据,如果缓存数据被更快、更频繁的清除,那就需要重新拉取完整数据,这也是开发者认为 tokens 使用量增加的原因。
值得注意的是 Claude Code 曾多次调整过缓存生存时间,包括从 5 分钟改成 1 小时,然后又从 1 小时改成 5 分钟,按照开发者的统计,变成缓存生存时间后会增加更多使用成本。
部分统计数据如下:
- 2026 年 1 月:缓存生存时间为 5 分钟时,tokens 浪费比例高达 52.5%
- 2026 年 2 月:缓存生存时间为 1 小时时,tokens 浪费比例降低至 1.1%
- 2026 年 3 月:缓存生存时间为 5 分钟时,tokens 浪费比例上升至 25.9%
- 2026 年 4 月:缓存生存时间为 5 分钟时,tokens 浪费比例降低至 14.8%
开发者抽取使用数据得出如下分析:
在缓存生存时间设置为 5 分钟时,会话中任何超过 5 分钟的暂停都会导致整个缓存上下文过期,因此下次使用时 Claude Code 必须以 cache_creation 输入而非 cache_read 缓存读取重新上传上下文数据。
对 Claude Sonnet 4.6 而言,输入价格是读取价格的 12.5 倍多,这种情况在 Claude Opus 4.6 中也同样存在,多数情况下模型输入价格都要高于读取价格。
对于长时间复杂的编码任务,这会造成明显的累积性损失:即会话时间越长、越复杂,缓存的上下文就会越多,每次缓存过期造成的使用成本也会越高。
对于使用 Claude Code 的开发者来说,调整后更容易触发配额限制,@seanGSISG 称以前从未达到过 5 小时配额限制,调整之后就容易触发限制。
CC 开发团队称 5 分钟缓存实际降低成本:
对于开发者提出的这个问题,Claude Code 团队也进行回应然后关闭这个问题,开发团队称用户观察到的缓存生存时间调整是正确的,也就是 3 月 6 日这个关键节点。
不过开发团队也表示调整缓存生存时间是为了降低成本而不是提高成本,原因在于 Claude Code 请求中相当一部分都是一次性调用,缓存内容只会使用一次,之后就不会再使用这些缓存数据。
因此将缓存生存时间设置为 1 小时后,只会带来更高的输入成本,而且没有后续缓存读取操作来分摊这部分成本,因为 1 小时的输入成本要高于 5 分钟缓存级别的输入成本。
在 3 月 6 日 Claude Code 团队调整了缓存生存时间,同时也进行了缓存优化:不同请求类型适用于不同级别的 TTL 层级,客户端会根据每个请求的情况自动设置不同的缓存生存时间。
总体而言这些优化和调整可以降低用户的使用总成本,而在 3 月 6 日之前的那些调整并非 Claude Code 预期的稳定状态,3 月 6 日调整后才是稳定状态。
最后 Claude Code 团队暂时不考虑提供全局缓存生存时间切换选项,对于缓存读取配额加权问题 (#45756),Claude Code 团队将继续跟进调查。
