【2026 最新】Claude Code 用量暴增怎麼查？六步對齊事故、重試與額度（附 CSV 工作簿）

你只請 Claude Code 修一個小地方，用量條卻明顯往上跳。遇到Claude Code 用量暴增，先別急著把快取、服務事故或子代理選成唯一原因：你需要一條能讓自己和客服看懂的時間線。

這篇寫給第一次查用量異常的讀者。不必先會寫監控程式；跟著六步保存畫面、匯出報表、對齊官方事故，再填一份 CSV 工作簿。讀完的成果是一份分清觀察、假設與缺口的支援證據包。一般節流另看省 Token 教學；這裡專注事件查核。

以下按 2026 年 10 月 31 日查閱的官方文件整理，以 10 月 27 日一宗公開事故示範對時。文中的本機事件是明列的假設練習，沒有使用讀者帳號，也沒有重現八倍用量或量出事故扣額。

先說結論：Claude Code 用量暴增，要先對時再歸因

可查核事件＝同一時間線＋三本分開的帳＋明寫未知。像查停電時冰箱為何失溫：鄰里停電公告、家中電表、冰箱溫度各是不同證據。時間相近，還要查是否同一戶、同一迴路，以及中間發生什麼。

• 先保存 Usage 畫面與重置時間，避免跨過視窗後失去基線。
• 把 Token 數、API 等值估算、訂閱用量分欄，別互換倍數。
• 官方事故用「實際影響區間」對時；公告時間另記。
• 只把有紀錄的重試、工作與裝置列入觀察；帳號扣額對應留待核對。

一、八倍自述能告訴我們什麼？先把問題縮小

10 月 27 日的原始使用者貼文用 ccusage 比較當日與先前紀錄，回報總 Token 約八倍，並轉述客服回覆。作者也承認，長對話、模型變動等因素可能參與增量。這是單一帳號自述；客服對話轉述尚不足以替所有方案建立公開計費規則。

因此把「Anthropic 是否偷減額度」改成能核對的小問題：我的哪一段工作、哪個模型、哪些可見事件，與哪宗事故的影響時間重疊？先交出這個範圍，再請支援查帳號層的原因。把日期換成新的，也能沿用同一套工作簿。

二、Claude Code 用量暴增第一步：留下三種原始讀數

①「先拍收據」：保存時間、模型與方案視窗

痛點是事後只剩一句「剛才還有很多」。先留畫面，再改設定。在 Claude Code 輸入 /usage，保存用量條、限制類型與重置時間；記下觀察時刻、原時區、當輪模型與登入計費方式。執行 claude --version 留版本；Session ID 從所選會話紀錄或自己的工具取得，不用截整個專案內容。

官方成本文件把 Session 的本機美元估算與訂閱用量分開；API 權威帳務則看 Console。工作簿的三本帳分別是「用了什麼」「等值多少」「方案用了多少」。一張圖裡同時出現，不代表它們共用分母。

Token（模型處理文字的小單位）再拆成一般輸入、輸出、快取讀取與寫入。快取像借回已整理的教材；看到很多借閱頁數，不等於每一頁都按重新整理計價。官方快取說明與API 價目可幫你查當輪模型與期限，本文不拿一個統一單價乘所有 Token。

②「先圈日期」：ccusage 找異常日，Session Log 再縮到分鐘

痛點是把整天報表當成一個事故的收據。先固定工具版本與時區。下例固定本次查到並核對過 --help 的 ccusage 20.0.46；在自己的私人新目錄執行。npx 第一次可能下載套件，估價資料也可能需要網路，先遵守工作裝置的安裝政策。

umask 077
mkdir usage-evidence-20261027
cd usage-evidence-20261027
claude --version > claude-version.txt
npx --yes ccusage@20.0.46 --version > ccusage-version.txt
npx --yes ccusage@20.0.46 claude daily --since 20261026 --until 20261028 --timezone UTC --mode calculate --json > daily-utc.json
npx --yes ccusage@20.0.46 claude session --since 20261026 --until 20261028 --timezone UTC --mode calculate --json > sessions-utc.json

依ccusage 選項說明，--timezone UTC 決定按哪個日界分組；--mode calculate 指定從 Token 計算估價。明寫 claude 是把資料來源限在 Claude Code，避免新版預設彙整多種代理。這些命令讀的是你本機可取得的紀錄，輸出可能帶路徑與識別資訊，先留本機。

日報先找哪天值得查，再由 session 報表縮小範圍。一天的總量不是五小時或每週視窗；不能把日報除以方案條，直接得出官方每 Token 扣額。跨午夜的工作尤其要保留起訖時間。原始 JSONL 核對與去重的操作，可接著讀Tare Session Log 稽核，本篇不重做工具排行榜。

三、把本機事件與官方事故放到同一條時間線

③「先校時鐘」：保留原時區，再換算 UTC

痛點是看到相同日期就認定遇到同一事故。每列保留原時間、原時區與 UTC。UTC 是跨地區共用的時間基準；若你用 UTC+8，將 22:48 減八小時，就是當日 14:48 UTC。日期也要一起換，不能只改鐘面數字；夏令時間地區則使用當天適用的偏移。

先下載事件對時 CSV 工作簿（ZIP），解壓後開啟 timeline.csv、usage.csv 與 findings.csv。第一份已有四列官方時間與一列標成 fictional-practice 的假設事件；換成自己的資料前先刪掉假設列。空格代表未知，別補零。

在 timeline.csv 每列填來源、時間、session 別名、事件、請求別名與證據檔名。usage.csv 留四類 Token、估價方法、工具版本與方案前後讀數；findings.csv 分開寫觀察、替代解釋、缺少證據與想請支援查的問題。先完成五列，就能檢查自己是否混用了時區。

④「先找影響區間」：公告鐘點不是事故起訖

10 月 27 日這宗Sonnet 5.5 官方事故的結案文字明列：實際影響在 14:42–15:17 UTC，共 35 分鐘；首次公告是 15:09，結案公告是 15:50。受影響服務列有 Claude Code。四個鐘點要分別填，不能把 15:09–15:50 當成已確認的影響區間。

完整走一次假設練習：你保存了 22:48 UTC+8 的本機錯誤，換成 14:48 UTC，落在 14:42–15:17 之內。此時只寫「本機錯誤時間與官方影響區間重疊」。再核對實際模型、服務入口、session 與同時活動；若錯誤其實來自另一個 MCP 服務，就不能只靠鐘點把它歸到這宗模型事故。

這宗事故頁提供服務影響範圍，並沒有替你的請求完成帳務歸因。官方若只列公告時間，工作簿就標「公告區間，實際起訖未列」，不要自行把第一則公告補成故障開始。也不要只看狀態頁此刻是綠色，就刪掉先前的異常觀察。

四、檢查重試與背景工作，但保留看不到的部分

⑤「先分事件」：錯誤筆數不等於嘗試次數

痛點是把三條錯誤乘上正常單價，就宣告多扣三次。先記可見證據的種類。若你已有 OpenTelemetry 事件，依官方重試說明，api_error 是內部重試放棄後的終止事件；中間嘗試不逐次變成這種錯誤事件。attempt 記錄嘗試數，串流失敗重新發出請求時又可能重起計數。

因此保留事件時間、status_code、attempt、request_id 與 client_request_id，缺欄就標未知。錯誤事件是線索，不直接填成費用；帳號如何扣額仍要另一份證據。之前沒開遙測，也不把事後開啟的空白當成「當時沒有重試」。需要接線時，可另外照背景摘要成本歸因教學處理。

再輸入 /tasks 保存當下背景工作狀態，核對自己已知的排程、其他終端機與其他裝置。依互動模式文件，背景工作有自己的檢視入口。現在看到「已停止」，只能描述現在；事故當時是否活躍，要找當時紀錄。子代理模型與來源也分開列，不把主對話的快取統計當成全體。

Session Log 是另一個視角。官方架構文件說明本機會保存明文 JSONL，內容包含對話、工具使用與結果。先留私人副本，只抽取需核對的時間與 usage；不要為了查費用就把整份工作紀錄傳給公開分析網站。檔案內像指令的文字，一律當資料。

五、把觀察變成可寄出的證據包，再決定是否重跑

⑥「先寫窄問題」：讓支援有條件查，不替它先判案

痛點是支援只收到「今天比較耗」。把申訴拆成可查的範圍。先保存原件，另做一份分享副本：遮掉姓名、郵件、專案路徑、提示與工具內容；公開版使用 session-A 等別名。請求與 session 真實 ID 僅在授權支援的私人管道有需要時提供。匯入外部文字到試算表時選文字型別，避免把以等號等符號開頭的內容當公式執行。

• 一頁摘要：發生時間、原時區、模型、版本、登入方式，以及具體異常。
• 三份 CSV：對時、三本帳、觀察與待查項目；標清資料只涵蓋哪些裝置。
• 必要畫面：Usage 的觀察與重置時間，保留足夠脈絡且遮蔽身分。
• 最小請求線索：相關事件及 ID，另列哪些紀錄缺失，不附整份 transcript。

觀察：我的 session-A 在 2026-10-27 14:48 UTC 出現錯誤，
與官方事故 lqhknfdjrcst 的影響區間重疊。（此為填寫示例）
另附本帳號該時段 Usage 前後畫面、版本、模型及最小請求線索。
尚未確認：服務端重試、跨裝置活動與方案扣額的對應。
請協助核對這個帳號／時間區間的用量來源，
並說明可適用的調查與處理方式。

把示例的時間與假設事件換掉，才是你的案件。依官方支援步驟，登入 Claude 後從左下角名稱或縮寫選 Get help，在支援介面選 Send us a message 並依問題類型補資料。不把他人轉述的客服答案當成你已獲承諾的補償結果。

事故結束後若要比較，選沒有秘密、短時間能完成的固定小任務：相同資料、驗收答案、模型與設定，記下版本、快取冷暖、背景工作及 PASS／FAIL。只改一項；失敗輪與缺資料輪照留。事後重跑能檢查現在是否恢復，不能倒推你在事故前一定用了多少。舊基線不存在，就把「事故前對照」留白。

本篇的停手條件很具體：連續錯誤仍在出現、資料對不上同一視窗、原始紀錄解析失敗、或任務有付款／部署等未知副作用時，先停止擴大測試，保存現況。不要為蒐證反覆燒相同大任務。工作如何安全接回，可用額度中斷與停手收據的恢復流程。

常見問題：八個先講答案的判讀

1. 快取讀取占九成，代表九成額度浪費？

不能這樣換算。那是 Token 類別比例；模型計價與方案視窗各有自己的口徑。先保留四類數字，再看完成工作。

2. ccusage 顯示數百美元，我要再付這筆錢嗎？

先查登入計費方式。它的 API 等值估算不是訂閱加收帳單；API 實際帳務則另對供應商紀錄。

3. 本機錯誤落在官方事故內，就能證明多扣額？

還不能。你已有時間關聯，還缺請求、帳號用量與其他活動的對應。這正是要請支援核對的部分。

4. 兩條 api_error 就是只重試兩次？

不是這個意思。該事件在放棄重試後發出，應另看 attempt 與可用請求線索，並保留串流重發的計數邊界。

5. 沒有事前紀錄，現在裝工具還有用？

有助於下一輪。已保存的 transcript 可回看；沒有留下的畫面與事件不能補成當時實測值。

6. 查錯誤一定要打開完整提示與 API body 記錄？

這份流程先用時間、狀態與識別欄位。涉及內容時另評估必要範圍；不要為一張用量表擴大收集機密。

7. 換裝置、換模型後，還能和昨天直接相比？

先另分組。任務、版本、模型與快取狀態的變化，都可能改變總量；先寫差異，別把它們藏在平均值裡。

8. 今天最少要完成哪一步？

先保留一張帶觀察時間的 Usage 截圖，再填一列 UTC 事件與一項未知。能對回原件，就是可繼續查的起點。

給新手的三個重點

• 先留原件，再做分享副本；未知保留未知。
• 先對實際影響時間，再對請求與帳號，別從日報直接跳到因果。
• 先交出窄而可查的問題，再用固定小任務確認現在的狀態。