Claude Code 30天燒掉2250億代幣：子代理模型設定盲點與成本優化實戰

我對編碼代理的原則是「用昂貴的模型規劃，用便宜的模型執行」。接著我統計了從9月15日到10月14日，我最忙碌的30天內所有Claude Code的代幣使用量：總計2251億個代幣，產生了736,633次API回應。其中94%是由Opus模型執行。

在其中兩週，我的大多數子代理都沒有指定模型，因此它們從父級會話繼承了Opus模型，而我當時並未察覺。我只用一台Mac、一台家用PC，在工作量大的日子裡，同時運行十個或更多的代理。如果你只運行一兩個代理，仍然適用於你的建議是：在不相關的任務之間使用/clear指令、為每個子代理指定模型，並提高cleanupPeriodDays以保留你的日誌。

其中97.9%的代幣消耗來自於模型重複讀取其上下文。其他人在規模小得多的日誌中也發現了相同的97%到98%比例（AgentsRoom統計為38億）。模型是無狀態的，因此在每個回合中，代理都會再次發送整個對話內容：系統提示詞、工具定義、它讀取過的每個文件，以及所有先前的訊息。

提示詞快取（prompt cache）處理了未改變的部分，而這部分幾乎佔了全部。平均每次回應會接收約305,000個上下文代幣，其中299,000個來自快取，並寫入約1,000個代幣。換句話說，模型每寫入一個代幣，就會重新讀取291個代幣。

在我的代幣使用中佔73%的Claude Opus 5.5模型，其快取讀取成本是輸入價格的5%（參見定價）。按照牌價計算，我一個月的花費約為97,000美元；如果沒有快取，費用將是這個數字的十倍左右。

我目前使用的是多個固定費率的編碼方案，所以這個數字只是一個衡量標準。即使是固定費率方案，重複讀取仍然會計入使用量。根據Claude Code的成本文件，「在一個已開啟一整天的會話中，即使只問一個單行問題，仍會計入整個對話的使用量」。由於每寫入一個代幣就需要重新讀取291個代幣，因此保持上下文簡短非常重要，建議在不相關的任務之間使用/clear指令，並將測試運行、日誌和文件查詢等冗長的工作推給子代理處理，這樣只會返回摘要。

更多代理，運行更多時間。在8月31日那一週，我的代理使用了40億個代幣。四週後，它們在一週內使用了608億個代幣。每個代理的工作量幾乎沒有變化。

每週每個代理每小時的代幣使用量維持在5200萬到8000萬之間。另外有兩件事發生了改變：同時運行的代理平均數量從2.0個增加到6.9個，而至少有一個代理運行的時數從每週38小時增加到145小時。這幾乎是每天21小時，意味著在我睡覺時代理仍在持續工作。

將這三個數字相乘，就能得到總數：第一週是2.0個代理 × 38小時 × 5200萬代幣 ≈ 40億，四週後是6.9個代理 × 145小時 × 6000萬代幣 ≈ 600億。

長期以來，瓶頸一直是我。同時運行多個代理讓我感到應接不暇。在我的金融研究中，我學到了「管理幅度」（span of control），即一個經理可以領導的人數。麥肯錫的版本指出，對於複雜多樣的工作，管理幅度為三到五個直接下屬；對於例行性、標準化的工作，則可超過15個。

我在代理身上也看到了同樣的情況。一個模糊的任務每隔幾分鐘就需要我介入。而一個有書面簡報、預先定義好「完成」標準，並共享任務列表的任務，則可以獨立運行一小時而無需我的干預。因此，我將工作變得更加例行化。每個代理都會收到一份簡報，並將其狀態寫入文件。

一個管理代理在家用PC上運行，負責追蹤誰在做什麼，並且只將需要我做決策的事項提交給我。另外兩件事也有幫助，我無法將它們的效果與我的努力分開：Opus 5.5於9月23日推出，而家用PC於9月28日開始承擔工作。

成果展現。代幣和代理工時都是投入。在同樣的30天內，我的代理和我總共在21個儲存庫中合併了1,029個合併請求（pull requests）：包括406個新功能和293個修復，平均每個合併請求約耗費三個代理工時。

其中幾乎所有工作都是面向客戶的：一個生產級SaaS產品的全面重建，包括新的登入系統、團隊工作區、帶有webhook的公共API、一個讓AI助理能使用產品的MCP伺服器、獨立的信用額度計費系統、重建的變更監控與警報，以及重新設計的儀表板。一個活動平台，包含Android應用程式、票務系統、工作坊座位分配、入場報到、533封個人回顧電子郵件和15份合作夥伴報告。

一個從零開始建立的目錄網站，包括公司和地點頁面、3,555家公司的標誌、登入和付費帳戶。還有200份稅務和法律解釋文件，以及四個金融產品的免費工具。這些代理還完成了我過去大部分手動執行的品質保證（QA）工作：對設計進行一致性檢查、對資料提取器進行黃金測試，以及在切換前發現兩個缺陷的影子運行。

日誌無法告訴我的是，哪些代幣產生了哪些結果，或者這些工作的價值。4.5天、4080萬代幣、零提交。在我的一個開源專案中，一次Codex在目標模式（代理會持續運行直到滿足停止條件）下的運行持續了4.5天，使用了4080萬個代幣，卻沒有產生任何提交或產品程式碼，只產生了約2GB的產物。

在代幣儀表板上，這看起來像是四天半的穩定工作。這個目標有兩個缺陷：它的停止條件需要一個只有我才能執行的步驟，因此運行永遠無法結束。而且，迭代之間的規則是「採取下一個將開放需求轉化為證據的行動」。最便宜的證據就是更多的證據，所以代理寫了綱要、歷史記錄和一個1.7GB的JSON排程。

我重新定義了目標，使其圍繞可運行的軟體，並命名了那些不計入的捷徑，還增加了一個「三振出局」規則。下一個會話產生了17次提交。

一封回顧電子郵件花費34萬個代幣。我讓代理為534位活動參與者（533封已寄出；一人從未在門口掃描過）撰寫並驗證個人回顧電子郵件。每封郵件約花費34萬個代幣，預計整個列表將花費1.8億個代幣。

我在使用了約5500萬個代幣後暫停，然後用一個更便宜的模型測試了五封植入錯誤的郵件，並用它完成了其餘的郵件，大約花費了5300萬個代幣：總計約1.1億個代幣，且每個代幣的價格更低。對於一個目錄網站，我需要為4,255家公司準備標誌。將每個公司首頁發送給模型會花費約8500萬個代幣。

純程式碼處理了其中2,003個，並將1,603個不明確的發送給小型Haiku審閱者，後者為1,552個公司選取了標誌。而一個針對兩個項目的Codex冒煙測試，在預設設定下，選擇了能力最強的模型並以最高努力運行，耗盡了整整五小時的使用窗口。

未指定模型的子代理。當我根據自己的規則檢查日誌時，我發現我大部分時間都沒有遵守它。在十月份，我97%到98%的子代理代幣運行在Opus模型上。在九月底和十月初，59%到80%的子代理沒有指定模型，而未指定模型的子代理會繼承其父級的設定。

我腦中的路由邏輯從未實際寫入配置中。直到10月11日，當PC上的工作會話開始運行Z.ai的GLM-5.3（一個更便宜的模型）時，情況才有所改變。接下來的一週，便宜的模型產生了所有輸出代幣的14%，但僅佔總代幣成本的約5%。然而，便宜的模型也帶來了它們自己的問題。

在目錄專案中，一個便宜的模型作為備用方案進行了84次呼叫，花費了六美分，卻增加了七個錯誤答案，沒有一個正確答案。現在，只有在少量已知答案的案例證明它確實有幫助後，備用方案才會被啟用。

我的Sonnet測試使用了與Opus大致相同的代幣量，因此任何節省都來自於每個代幣的價格。在會話中途切換模型會丟棄快取。在Claude Code中，每個模型都有自己的提示詞快取，因此切換後的第一個請求會重新讀取整個對話，而沒有任何快取命中（參見提示詞快取文件）。因此，建議為便宜的部分生成一個新的子代理。

我第一次的模型比較誤導了我。它說MiniMax每個會話使用的代幣是兩倍，但它56個會話中有53個都集中在一個專案中。在兩個模型都參與的同一個專案中，結果卻相反，但會話數量太少，無法得出任何有意義的結論。我當時比較的是工作負載。在Claude Code中，模型是在子代理定義中的model欄位：可以是haiku、sonnet、opus、完整的模型ID，或inherit。

要更改所有未指定模型的子代理所使用的模型，請設定CLAUDE_CODE_SUBAGENT_MODEL（參見子代理文件）。

任務中遇到的限制。運行這麼多代理，我至少遇到過以下每一種情況：使用限制：一個夜間限制在凌晨04:20到08:20之間停止了30個代理的任務。所有代理都恢復了，沒有丟失任何工作。現在，該運行只允許兩個活動代理，並且我在恢復之前會檢查每個代理提交了什麼。

API容量：同時啟動八個Opus代理會返回「529 Overloaded」錯誤。分批啟動三個也失敗了。現在我會同時啟動較少的Opus代理；如果重試批次也失敗，我就會在前景完成工作。Mac記憶體：交換空間已滿（30.7GB中的29.3GB），而可用RAM看起來正常，所以將建構堆減半沒有任何作用。

現在我會測量交換空間，而不是可用RAM。睡眠：Mac在限制重置期間進入睡眠狀態，運行停滯等待按下Enter鍵。現在我會為每個夜間運行使用caffeinate -s指令。

這30個代理之所以能夠恢復，是因為它們的狀態儲存在文件和共享任務列表中，而不是在對話中。Claude Code預設也會將每個會話的並行子代理數量限制在20個（CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS可以更改此設定），較新版本甚至可以在使用限制重置後自行等待並繼續中斷的任務。

新的審閱者，以及一個得分0.48的評審。對於一系列稅務和法律解釋文件，撰寫代理會檢查自己的主張並報告為「綠燈」（無問題）。然而，被告知要查閱每個陳述的原始資料的新審閱者，仍然在他們檢查的每篇文章中發現了需要修正的地方。在我有完整統計的三篇文章中，他們分別修正了64個陳述中的11個、44個中的11個和26個中的17個。

我也測試了一個檢查器。在一個實驗中，我根據我後來是否質疑代理報告來標記它們，大約有7%的報告被質疑。一個將每個主張與代理的工具日誌進行比對的LLM評審，在挑選出這些被質疑的報告方面，表現並不比隨機猜測好（AUROC 0.48）：它將大約70%的所有主張標記為「無證據」，無論報告類型如何。

一個簡單的詞頻分類器（TF-IDF）在相同的標籤上得分為0.65。兩者都不夠好用，但便宜的基準模型卻勝過了評審模型。

我的測量方法，以及如何檢查你的使用情況。要檢查你自己的使用情況：Claude Code中的/usage指令會顯示當前會話每個模型的輸入、輸出、快取讀取和快取寫入量。對於歷史記錄，npx ccusage@latest daily會統計一台機器上的所有紀錄。我對Mac和PC上所有的Claude Code紀錄運行了ccusage，並將它們合併，這樣每個API回應只計算一次。

如果將每台機器的報告直接相加，會重複計算438億個代幣，因為紀錄在機器之間有複製。手動計算一天的結果，誤差在0.3%以內。代理工時計算的是每個會話或子代理的工作時間：同一紀錄中相隔不超過5分鐘的兩個回應算作工作。

「同時運行的代理數量」是代理工時除以至少有一個代理運行的總時數：在30天內，總計3,268個代理工時除以547小時。合併請求（pull requests）是指在此期間我的GitHub帳戶下合併的請求。代理是在我的帳戶下開啟它們的，因此這個數字無法區分它們的工作和我自己的工作。

美元數字是牌價等值，並非我實際支付的金額。Codex最多增加了約10億個代幣；Cursor不保留代幣計數。Claude Code預設會在30天後刪除紀錄，因此我九月之前的歷史記錄大部分都已消失。還有一個配置檔指定了一個模型，但紀錄卻顯示另一個模型運行了4,213次。

我最初將這篇文章連同所有十張圖表發佈在jacksonly.xyz上。這篇文章是在AI協助和人工審閱下撰寫的；所有數據都來自我的個人日誌。價格和限制均按照2026年10月的文件記錄。