本篇文章更新時間：2026/04/13
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
Claude Code 快取 TTL 悄悄縮水：為什麼默默從 1 小時變回 5 分鐘？
這是一篇關於「小設定，大成本」的深度觀察
編輯前言：原始文章來自 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，導致成本與配額消耗大幅膨脹。
核心觀點 (Key Takeaways)
- 作者利用大量 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 官方回應。