編輯前言：原始文章來自 GitHub 議題：Cache TTL silently regressed from 1h to 5m around early March 2026, causing quota and cost inflation。作者透過分析 12 萬筆 Claude Code session logs，發現了一項驚人的現象：快取 TTL 在未公告的情況下悄悄從 1h 回到 5m，導致成本與配額消耗大幅膨脹。
- 作者利用大量 session logs 觀察到：從 2 月初到 3 月初，Claude Code 的快取 TTL 的確長達 1 小時，且一致穩定。
- 3 月 6–8 日間，TTL 突然回到 5 分鐘，使大量上下文必須重複寫入快取，造成成本暴增 20–30%。
- 5m TTL 對長時段 coding session 特別傷，因為任何超過 5 分鐘的暫停都會導致上下文重新上傳，寫入成本比讀取高 12.5 倍。
整份原文非常細緻地比對了三個月、兩台不同設備、近 12 萬筆 API 呼叫的日誌。以下是我認為幾個關鍵觀察：
一、1h TTL 的確曾是預設，而且至少維持 33 天
作者將整段期間分成 4 個階段：
- Phase 1：1 月全是 5m，推測當時 API 尚未提供 1h tier。
- Phase 2：2 月 1 日到 3 月 5 日期間，100% 為 1h TTL。
- Phase 3：3 月 6–7 日出現轉折，開始混入 5m。
- Phase 4：3 月 8 日後 5m 重新全面主導。
原文用大量數據展示這段轉折，其中一句話最具力道：
「33 天完全乾淨的 1 小時 TTL 資料，兩台機器兩個帳號。這不是噪音、不是實驗，而是刻意配置。」
我完全認同。這種跨設備、跨帳號、跨數週的一致性，很難解釋成偶然。
二、5m TTL 讓成本直接跳升 20–32%
快取在 5 分鐘後失效，有什麼後果？
每次 expiration，Claude 都必須重傳 context。以 Sonnet 的費率為例：
- cache_read：0.30 美元/MTok
- cache_write：3.75 美元/MTok → 貴了 12.5 倍
因此當 TTL 從 1h 降回 5m，長 session 幾乎一定會反覆寫入 cache，成本自然水漲船高。作者計算這段期間總共：
- 多花了 17.1% 的費用（在 119,866 次呼叫上）
- 對 Opus 使用者來說，損失更達 1580 美元
而其中最令人震驚的是日讀數據：
3 月 22 日出現 30M tokens 的 5m cache 重寫，是整個 dataset 的最高峰。
這明顯像是某種 server-side flip，而不是使用者端行為造成。
三、5m TTL 對 Pro 訂閱者造成隱形的配額壓力
這點我也非常有感。快取寫入計入 full quota，而讀取則是折扣計算。如果 TTL 太短，等於每次 coding 休息後都在重新 burn quota。
原文更提到：
「包含作者本人在內，許多 Pro 使用者首次在 2026 年 3 月開始撞到 5 小時 quota 上限。」
這與 TTL 變化完全吻合。
這篇原文最讓我驚訝的不是技術細節，而是一個小設定就能造成巨大的連鎖反應。
尤其是 Claude Code 的使用場景本質上就是長時、反覆互動、上下文極長的 coding session。對這類使用者來說，5 分鐘 TTL 等於把所有成本打 12.5 倍。這大概是這篇文所要提出的最大問題：
如果 5 分鐘 TTL 是刻意調整，那是重大的產品定位變化；如果它是 regression，那它已經造成用戶實質損失。
我個人認為：
- 1h TTL 更符合 Claude Code 的真實使用方式。
- 若因後端成本壓力不得不調整，也應提供至少讓使用者「選擇 TTL」的能力。
- 最重要的是：配額計算方式與 cache tier 的對應邏輯必須公開透明，否則使用者無法對自己的成本與使用策略做出合理決定。
從資料完整性來看，我認為原文得出的結論非常可信。這篇分析不只是 debugging，而是一個使用者從真實資料中提出的產品洞察。非常值得 Anthropic 官方回應。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/260538.html