Claude Code 兩天燒光九成配額：日誌揭露驚人消耗

我每天都使用 Claude Code 來開發一個 SaaS 產品。這週，我的使用量計費器在週三之前就達到了 95%。我原以為自己寫了大量的程式碼，但事實並非如此。

由於每個請求都在本地記錄，我將其加總。以下是三天（10 月 12 日至 15 日）的工作情況：65,000 個請求、處理了 126 億個 token，以及 1,400 萬個實際輸出 token。這意味著我 99.9% 的 token 並非程式碼，而是模型重複讀取它已知的部分。

真正的成本是上下文，而非程式碼。所有 token 中有 97.6% 是快取讀取。每次輪次，代理都會重新發送迄今為止的整個對話，包括已讀取的文件、工具結果和先前的決策。

當上下文達到 20 萬個 token 時，即使只是一行回覆，仍然需要 20 萬個 token 的讀取成本。我三分之二的用量來自上下文超過 20 萬個 token 的請求。只有 2.5% 的用量來自上下文小於 5 萬個 token 的請求。長時間的會話並非因為做了更多工作而花費更多，而是因為每次新的輪次都比上一次更昂貴。

子代理是消耗的倍增器。我的工作流程將任務分解為小塊。對於每個任務，一個子代理負責實作，另外兩個則負責審查，一個檢查規格符合性，另一個檢查程式碼品質。

這種方法產生了清晰的結果，但也產生了我 78% 的請求和 53% 的 token 消耗。每個子代理都以一個全新但仍然龐大的上下文開始，執行許多工具呼叫，而每次呼叫都會重新讀取該上下文。一個任務因此變成了數十個請求。

在 46 個會話中，有五個會話佔了總用量的四分之三。這些都是持續數小時的運行，其中上下文不斷增長，我從未重新開始。其中一個會話平均每個請求的上下文接近 40 萬個 token。

其餘的細分如下：Sonnet 模型佔 82% 的 token，Opus 佔 14%，Fable（高級方案）佔 3.6%，幾乎全部發生在單一天內。

我正在改變的做法包括：每個任務區塊只使用一個會話。我會在上下文達到 15 萬個 token 之前，就清除或壓縮它。我會減少平行子代理的數量。

對於常規工作，我會採用一個審查週期而非兩個。對於審查和探索等常規子代理，我會使用較小的模型。高級模型只用於規劃和困難的決策。我還會建立一個小型本地腳本，每天早上匯總日誌，這樣我可以在計費器顯示之前就看到使用曲線。

關於這些數字的注意事項：這些是原始的 token 計數。快取讀取與新的 token 計費或限制方式不同，因此這解釋了用量，而非使用量計費器上顯示的確切百分比。重要的是其模式。

總結來說，如果你的 AI 編碼配額消失得比你預期的輸出還要快，請在歸咎於模型之前，先檢查你的上下文大小和子代理的擴展情況。Token 並非花費在答案上，而是花費在記住問題上。你如何追蹤代理的使用情況？你會刻意重置會話，還是只在出現問題時才重置？