兩個禮拜前開始，國外出現了 Claude Quota Crisis 一詞。很多人發現自己的額度比以前少了很多，打幾則訊息就被鎖住，根本到了不可用的程度。官方出了「尖峰時刻限縮額度」的公告後更是火上澆油，一發不可收拾。
然後，Reddit 上有人花了一個下午，把真相挖出來了。
兩個吃掉你額度的 Bug
BUG 1：快取字串竄改
正常情況下，Claude Code 對話時會命中上下文快取，快取費用為原本的 10%，不用重新計費。但官方的安裝版有一段程式碼，會在每次送出訊息時修改內容。本來只會改到系統設定的部分，但如果你的對話紀錄中剛好出現某些特定的技術字串，它就會抓錯地方，改到對話內容本身，於是讓快取失效，直接用原價讀整包完整對話。Token 費用暴增。
什麼情況會中招？對話過程提到 Claude Code 內部運作或技術相關字眼、這串技術字串剛好在你的 Claude.md 裡面、或者讀過貼上 Claude Code 的原始碼。
怎麼避免？用 npx @anthropic-ai/claude-code 啟動，而不是跑電腦上裝好的版本。
BUG 2：Resume 重算整包上下文
用官方的 --resume 接回過去的對話。本來這個功能是很好的，但從某個版本開始，每次只要使用這個功能，第一條訊息就會重建快取，把過去的對話全部算一遍。假設前面的對話已經很長，那這一次可能就燒掉 10 幾% 的額度，但你什麼都還沒做。雖然後面的訊息恢復正常快取，但這個入場費每次 resume 都要付，一天 resume 五六次就飽了。
怎麼避免？比較務實的做法是避免使用 resume，改用開新對話加貼前次摘要的方式來避雷。
被網友嗆翻的是：「你們手握最先進的模型，還不如網友花一個下午查出來的 BUG。」
百萬 Token 的複合效應
Bug 之外，還有一個結構性的問題。有人在 Reddit 上發了一篇數據分析文章，叫做「對百萬上下文 token 消耗的數據分析——上下文增長加快取遺失的複合效應」。
1M 上下文上線前，大約到 160k token 時會自動壓縮。1M 上線後天花板消失，對話很容易就累積到 50 萬。在這種情況下，光是一個短回覆就會燒掉 50 萬，如果模型做三次 tool call，就是實際燒掉 150 萬 token。
快取有效期大約是 5 分鐘，過期後下一個 prompt 就是以 10 倍原價重算整個上下文。其實遺失率沒變（2.5%），但 context 變厚的情況下，每次 miss 的代價超過三倍。
我拿自己最活躍的四個專案跑了分析：
- A 專案有對話完全沒有壓縮，讓上下文膨脹到 454k。如果某個 prompt 觸發了三個 tool call，實際消耗就是 1.39M。
- B 專案的快取遺失率高達 4.3%。因為那個專案常常需要中斷五分鐘以上再回來，所以每次就是整個 context 重算。
- C 專案是 1M 上線後才用的，從來沒有 auto compact 過，長期養成壞習慣會越來越耗費額度。
- D 專案對話最多、每個對話上下文平均厚度高，應該要養成「新任務就要新對話」的習慣。
2.1.89 修復
四月一號發布的 2.1.89 版本，Boris 說這次更新能解決最近的用量額度異常問題。目測幾個重點：
- 把連續壓縮地獄修掉了。之前壓縮後立刻填滿，連續壓縮三次後就變成無限 loop，狂燒 API calls。
- 長對話容易遺失快取的問題修掉了。Tool schema bytes 在 session 中途會改變，導致快取失效。
- Claude.md 在讀過很多檔案的長對話中有多次重複注入的問題修掉了。
/stats統計數字沒有算進 subagent token 用量，使用者以為自己 token 用得少。這次修掉了，真實反映 token 用量。
算是遲來的修復。但至少，真相大白了。