4月2日,Anthropic把Claude Code的提示缓存存活时间砍掉了92%。没人发公告,没弹横幅,工程师们是从配额进度条提前见底才发现的。
谁最先发现的?
5小时订阅档的工程师。他们的配额在一周前就撞到了天花板。
几个人把账单日志丢进Python脚本跑了一遍,证实了直觉:每次咖啡回来,缓存就失效了,得重新付写入费。
GitHub issue #46829的公开复盘帖、dev.to上的社区复盘、The Register对Anthropic回应的报道——这三处文档记录了这次变更。The Register援引Anthropic的说法:5分钟缓存对它们的负载混合来说平均更便宜,因为很多Claude Code会话是一次性的。
这个说法在聚合层面或许成立。但对那个正在跑长篇重构会话、每小时重复写入8万token系统提示的工程师来说,完全无关。
真正的麻烦不是TTL该多长
托管大模型基础设施上的厂商侧参数,现在可以静默变动。而它产生的故障模式——成本更高、输出完全一样——对大多数团队现有的监控体系完全隐形。
延迟监控什么都没抓到。messages.create的p50和p99纹丝不动。错误率没动。输出token数没动。
唯一变动的信号是这些:
这就是这次回退的完整形态。如果你的可观测栈只追踪请求数、延迟、5xx率:恭喜你,这次变更对你完全隐形。如果它追踪token但只到汇总层,汇总内部的成本比例变了,但总数看起来像有机增长。
三类故障藏在这个盲区里
第一类:缓存策略变动。厂商缩短TTL、调整逐出策略、或在不同缓存层之间迁移流量。症状是成本上升,延迟和错误率不变。
第二类:路由暗改。请求被悄悄导向更贵的模型变体或区域。症状是成本上升,token数和延迟不变。
第三类:定价阶梯漂移。折扣阈值、批量费率或订阅权益的边界移动。症状是成本上升,使用模式不变。
传统APM为第一代云故障而建:延迟、错误、饱和。大模型运维需要另一套记分牌。
三个信号能在账单到来前抓住这类事故
第一,提示缓存命中率的时间序列。每个支持缓存的托管大模型都会在单次调用里暴露缓存读取和缓存写入的计数器。把它们发出来。按会话、按用户、按部署汇总。要盯的数字是:cache_read_input_tokens / (cache_read_input_tokens + cache_creation_input_tokens)。稳定负载下这条线是平的。它掉了,就是哪里变了。可能是你的提示,可能是他们的。
第二,账单与用量的漂移。追踪两个比率:每会话token数、每会话美元数。它们应该同向变动。当每会话美元数涨得比每会话token数快,token的单位经济变了。这几乎总是厂商侧动作:缓存变更、定价档位移、或路由到更贵模型。
第三,黄金集合回退。一小批固定提示,每天对生产模型重放并做diff。能抓住缓存指标漏掉的语义漂移。运行成本低得可笑。用的人少得更可笑。
你的监控栈现在覆盖到哪一层了?
热门跟贴