本篇文章更新時間：2026/04/13
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
Pro Max 5x 配額 1.5 小時用光？一次深讀這篇技術回報背後的真正洞察
編輯前言：這篇來自 GitHub Issue 的技術回報指出一個很關鍵卻容易被忽略的痛點：在 Claude Code 中，Prompt Cache 的 cache_read token 可能被計入完整配額，導致 Pro Max 5x 的配額在短短 1.5 小時內就被耗盡。這篇筆記帶你快速掌握問題核心與實際影響。
核心觀點 (Key Takeaways)
- 使用者在 Pro Max 5x（Opus）方案中，在極度輕量使用下仍於 1.5 小時內用光配額。
- 原因高度疑似是 cache_read token 被當成完整 token 計入配額，而非應有的 1/10 成本。
- 多個「背景 Session」會持續自動呼叫 API，即使使用者沒有在操作也會吃掉配額。
- 大 Context（1M）雖然是特色，但在現行計費方式下反而變成加倍消耗配額的主因。
深入解析
這篇原文出自 GitHub Issue：
BUG: Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage
作者的使用情境很清楚：重置配額後，只做了約 1.5 小時的輕量開發與問答，卻突然收到配額用盡的通知。問題看似直覺，但往下挖會發現其背後是 token 計算邏輯與使用模式多重因素疊加而成。
引用原文一句話最能說明狀況：
"Investigation reveals the likely root cause: cache_read tokens appear to count at full rate against the rate limit, negating the cost benefit of prompt caching for quota purposes."
也就是說：Prompt Cache 雖然設計上 cache_read 的成本應為 1/10，但在配額計算時卻被當成 1 倍來算。這等於直接讓紀效率化的機制失去意義。
以下分幾個關鍵面向拆解：
-
1. cacheread 的配額計算方式可能錯誤：
原本的期望是 cacheread 應該只以 1/10 成本計入配額，但從實際消耗速度推算，系統似乎是用「完整 token」計算，導致 Context 越大、每次呼叫越貴。 -
2. 非主動操作的 Session 也會吃掉配額：
作者提到同時有兩個背景 Session（token-analysis、career-ops）在未操作的情況下依舊持續 auto-compact、背景 hook、retro 處理，累積超過 400 多個 API 呼叫。這些背景工作加總起來吃掉了 78% 的重置後配額。
-
3. auto-compact 反而造成成本尖峰：
Context 接近 960k token 時，系統自動觸發 compact，而 compact 本身會送出「完整 pre-compact context」進行 cache creation。這意味著：最貴的一次 API 呼叫是系統自動觸發，而不是使用者主動發送。
-
4. 1M context 看起來是加分，但在錯誤計費下變成反效果：
因為每次 API 呼叫都會攜帶整份 context，如果 cache_read 被算成 1 倍 token，那麼每個 call 將高達數十萬到百萬 tok 直接進配額。
作者給的數據非常明確：
- 中度使用（1.5 小時）有效 token 約為 13.1M
- 但實際配額消耗相當於 105.7M token
差距 8 倍，正好符合「cache_read 不小心按 100% 計算」的情境。
筆者心得與啟發
讀完這篇 Issue，我最大的感受是：這不是使用者誤用，而是系統邏輯與產品呈現之間的落差。
Prompt Cache 的設計初衷，正是讓大型 context 的操作能更省 token，也更適合長期編輯。然而如果 cache_read 在計費端仍以 1 倍計算，那使用者每呼叫一次 API，就會被動送出幾十萬 token。
這讓我重新思考：
- 在使用大型 context（1M）時，開發者應該更加注意 Session 數量與背景進程。
- 產品層面上，Claude Code 更需要明確揭露 token 消耗項目，否則使用者很難判斷到底是哪裡消耗了配額。
- auto-compact 雖然是必要機制，但若每次都付出將近百萬 token 的成本，這種「無形成本」應該被展現出來。
如果我是使用者，我會建議：
- 同時只保留 1 個活躍 Session
- 定期手動清除不需要的 context
- 使用 /context 檢查每次呼叫的實際負載
而站在產品角度，我認為作者提出的建議極具實務價值：
- cache_read 必須以有效 token（1/10）計算配額
- 閒置 Session 不應默默消耗 quota
- 顯示 cacheread / cachecreate / input / output 的即時用量
對於重度使用者與開發者而言，透明度與可預期性才是最重要的。