Claude Max 用量異常：我如何追查背景程式的代幣消耗

我的 Claude Max 每週用量限制在早上六點重置。大約下午一點時，我查看用量計，它顯示 2%。那天早上我幾乎沒怎麼使用，肯定不值 2% 的用量。我知道這數字很小，但它讓我感到困擾，如果有些東西正在消耗我的額度，我想知道是什麼。在開始之前，快速說明一下：我大部分的追查工作都是用 Claude Code 本身完成的，修復程式碼也是用它寫的。

所以，這確實是一個關於使用一個 AI 工具來找出另一個 AI 工具花費我多少成本的故事。

首先，我實際使用了什麼？Claude Code 會為每個會話保存一份記錄，每份記錄都記載了代幣用量。因此，我將重置後機器上的所有記錄加總起來，總計約佔我每週額度的 0.26%。我自己的工作量僅能解釋計量器顯示的約八分之一，其餘的消耗顯然沒有寫入記錄。

我也想確認計量器是否出錯，Claude Desktop 在 ~/Library/Application Support/Claude/plan-usage-history.json 中保存了用量歷史：早上六點是 0%，下午一點前是 2%。所以，用量飆升確實發生在那個早上。

唯一在背景運行的程式，我有一個會在背景執行的外掛程式：claude-mem。這是一個很受歡迎的記憶體外掛程式，它會監控你的工具呼叫，並將它們傳遞給一個背景運行的「觀察者」Claude，該觀察者會為你未來的會話寫入記憶筆記。這個觀察者以 claude --no-session-persistence 模式運行，這表示它不會寫入會話記錄，這正好解釋了我所遺漏的部分。

該外掛程式的工作程式有一個狀態端點，於是我檢查了它。/api/processing-status 回傳 queueDepth: 2080，我的上一個會話大約在七小時前結束，但它仍在處理一個佇列。

記錄顯示了什麼？該外掛程式自己的記錄檔（GMT+6）顯示了完整的時間軸：凌晨 2:34，它的額度保護機制在每週用量達到 93% 時暫停。工作被緩衝起來，而不是被丟棄。凌晨 5:37，有 3,285 個工具呼叫在緩衝區中等待。凌晨 5:46，每週額度用盡。

早上 6:00，額度重置為 0%。早上 6:08，外掛程式恢復運行，開始處理積壓的工作，這些工作現在計入新的一週。早上 6:00 到 7:00 之間，該觀察者進行了 677 次處理。因此，在接近額度上限時暫停並沒有節省任何東西，這些工作只是被計入下一週。

對於記憶體工具來說，不丟棄工作是合理的，因為你不希望筆記中出現空白。但在有上限的方案中，這意味著積壓的工作會在你新的一週開始時被支付。

為何每次處理成本如此高昂？處理量是一個問題，另一個問題是每次處理都非常耗費資源。觀察者在每次處理時都會重新讀取整個對話內容。這個對話在重置前會增長到大約 10 萬個代幣，並且預設情況下，它每次處理一個工具呼叫。當我將 CLAUDE_MEM_OBSERVER_MAX_CONVERSATION_CHARS 從 400,000 降低到 100,000 時，每次處理的代幣量降至約 26,000 個。這是一個設定問題，而不是程式錯誤，所以我將其留給維護者處理。

第二個部分是一個真正的程式錯誤。當 Claude Code 編輯檔案時，編輯結果會包含 originalFile，這是編輯前的整個檔案內容。我在外掛程式的記錄中發現，在 44 秒內有 7 次呼叫，每次輸入代幣約 67.5K，因為被編輯的檔案大約是 210 KB。

每次呼叫產生約 150 個代幣的輸出，且沒有任何快取重複使用。claude-mem 本身已經有程式碼可以從編輯結果中移除 originalFile。那麼，為什麼它仍然被傳送呢？

這個程式錯誤在於，修剪功能有一個安全檢查。它只會在編輯結果中的每個鍵都是它能識別的鍵時才運行。Claude Code 2.1.309 在編輯結果中新增了兩個欄位：contentNotInModelContext 和 staleRecovered，兩者都只是布林值。

但它們不在允許清單中，因此檢查機制將整個結果視為不熟悉，並按原樣傳送，包括整個檔案。沒有錯誤，也沒有警告。修剪功能在 Claude Code 更新後就停止運行了，而且沒有人注意到。我認為這個檢查在編寫時是合理的，如果你不知道一個欄位包含什麼，不觸碰酬載會更安全。它只是沒有預料到上游會新增無害的欄位。

修復方法：在進行任何更改之前，我在我機器上儲存的實際編輯結果上重新執行了修剪邏輯，以確保這確實是問題的原因。結果證實了。然後我在該函數中做了兩個小改動（PR #5027）：值為布林值、數字或 null 的未知鍵不再阻止修剪。因為 true/false 不可能包含原始碼，所以沒有什麼需要保護的。

未知字串、陣列或物件仍然會走謹慎的路徑，這也涵蓋了 Claude Code 將來可能新增的任何旗標。如果修剪後的版本仍然超出大小預算，它現在會被壓縮。以前，它會回退到原始酬載，包括整個檔案。測試從 4 個通過、2 個失敗變為 6 個全部通過，並且類型檢查和程式碼風格檢查都乾淨。

當我對 639 個實際儲存的編輯結果重新執行新邏輯時，有 168 個被修剪，而之前只有 29 個。

在我提出問題約 15 小時後，維護者合併了我的修復，並留下了這段評論：「第二點（編輯酬載將完整的 originalFile 帶入壓縮）已由 @smrifat1411 撰寫的 #5027 解決，他也是這個問題的報告者……它已在主分支上，並將在下一個版本中發布。感謝如此詳盡的報告。」這讀起來令人欣慰。問題中的其他幾點（預設觀察者大小、用量可見性、積壓工作重播）是設計決策，這些則由維護者決定。

我在自己機器上的做法是，我清除了積壓的工作。然後我卸載了 claude-mem，並改用 Claude Code 內建的記憶體功能（CLAUDE.md 加上自動記憶體），它不會進行任何背景呼叫。這主要是為了我的用量上限方案，與外掛程式本身無關。

這是一個很棒的專案，維護者對此處理得既迅速又友善。我並不是唯一遇到這個問題的人。其他人在儲存庫的問題追蹤中也報告了大量的背景用量：一天內約 76.7M 代幣（#2315）、佔 Max 20 倍每週上限的約 62%（#2451）、約 649M 代幣（#2643）。

我沒有親自驗證這些數字，而且大多數人都只是選擇卸載。據我所知，我是第一個報告每週重置後積壓工作被重播的案例。

我從中學到的教訓是：如果背景工具在你的訂閱下運行，即使你沒有工作，它也會消耗你的額度。理論上我知道這一點，但我從未真正思考過。暫停不等於跳過，緩衝的工作最終還是會運行，你仍然需要為此付費。當計量器和你自己的記錄不一致時，請尋找那些沒有寫入記錄的東西，這個差異就是我發現所有問題的關鍵。

此外，允許清單（allow-lists）可能會悄無聲息地失效。如果你拒絕任何不熟悉的內容，請思考一個未知欄位實際上可能造成什麼影響。一個布林值永遠不會傷害任何人。如果你想了解更多細節，問題報告在此：問題：https://github.com/thedotmack/claude-mem/issues/5023 修復（已合併）：https://github.com/thedotmack/claude-mem/pull/5027