Claude Code 的 token 都去哪了：9 種流失模式，以及 2026 年的修復方法

在一個例子中，全新的 Claude Code 工作階段執行/context時，顯示 200K 中已有 60K token 被占用，當時還沒送出第一則訊息。專案儲存庫裡只啟動了claude。60K token——三分之一的額度就花在「準備」對話上了。

兩週後，我終於弄清楚這些 token 到底去了哪裡。以下列出你開始輸入之前就會消耗 token 的全部 9 種模式，以及各自的修復方法。數據來自 Anthropic 官方文件和真實工作階段的測量。

「提示詞送出前，73% 的 token 就流失了」是什麼意思？#

以下是 9 種模式的整理表，包含真實工作階段測量數據及 Anthropic 官方成本管理頁面的資料。

我不會說「73」這個數字絕對準確——依你的設定而定，可能是 60%，也可能是 80%。但整體情況確實如此，而且每種模式都能個別修正。以下每次會介紹三種。

Claude 讀取你的請求前，如何建立上下文？#

視窗大小取決於模型。根據 Anthropic 的模型文件，截至 2026 年 9 月，Opus 4.7 及更新版本、Sonnet 5 和 Fable 模型在所有方案中都提供 1M-token 視窗，包括 Pro。未使用 extended context 的 Opus 4.6 和 Sonnet 4.6，以及透過CLAUDE_CODE_DISABLE_1M_CONTEXT=1變數停用 1M 的工作階段，仍採用 200K。視窗變大並不能解決上下文膨脹：第一則訊息送出前載入的所有內容都會隨每次請求傳給模型，而成本文件明確指出，上下文越多，token 用量就越高。訂閱方案也不會改變這點——任何方案中，每多一個 token 都會占用你的額度。

上下文的前三分之一去了哪裡：CLAUDE.md、歷史紀錄與 MCP#

模式 1. 每則訊息前載入 CLAUDE.md

CLAUDE.md 可能是第一個流失來源。這個檔案不是每個工作階段只載入一次，而是在你送出每則訊息前都會載入。含有 5,000-token CLAUDE.md 的請求，會占用這麼多上下文；但新輸入、快取寫入與讀取需分開記帳，重複內容未必按完整未快取費率收費。

Anthropic 在文件中直接寫道：

這是外部最難察覺的模式，因為你看不到它。後續請求會提供保留的對話上下文；提示詞快取可重用穩定前綴，壓縮或清除則會改變保留文字。即使快取價格降低成本，重複提供的內容仍占用視窗。

模式 2. 每次回覆都會重新讀取對話紀錄

解決方法是在不相關的工作之間使用/clear。我的規則是每個新任務都開新聊天。如果任務很長，而且你需要保留歷史紀錄，就用/compact把過去的內容摘要成精簡摘要，再從那裡繼續。

我的工作階段中有實際案例，詳見指南「如何避免一天內用完 Claude Code 額度：節省 token 的 8 個規則」。

模式 3. MCP 伺服器會把所有工具註冊到上下文中

Anthropic 在 2025 年 12 月至 2026 年 1 月推出 Tool Search 功能，解決了這個問題的一大半。

Anthropic 文件目前的說明如下：

在正式環境中可以這樣做：

1. 將 Claude Code 更新到支援 Tool Search 的版本（2025 年 12 月以後的所有目前版本都支援）。
2. 開啟/mcp，停用目前工作階段不需要的伺服器。在這個案例中，Playwright 和 shadcn 兩個伺服器一直保持連線；其他伺服器則只在單一任務期間啟用，結束後立即執行/mcp disconnect。
3. 可行時以 CLI 取代 MCP。使用gh代替 GitHub MCP 伺服器。改用瀏覽器中的行事曆，而非 Google Calendar MCP。

我在「2026 年的 Claude Code MCP 伺服器：7 種現成設定與逐步安裝指南」中介紹了 MCP 伺服器的基本概念和合理設定方式。

CLAUDE.md 和 Skills 的問題不只在於大小，也在於結構。CLAUDE.md 是核心指示檔。額外的專案知識，例如受眾、產品、法律文件、每日指示，則放在business/資料夾中；在我的方法論裡，這就是Second Brain。Claude 只會讀取目前需要的內容，而上下文壓縮在這個層級就已經開始。完整說明請見「Claude Code 中的 Second Brain」。

還有一個常被忽略的細節：清理 CLAUDE.md、改用 Skills、停用 MCP 都只是第一步。接下來就要運用上下文工程方法論，決定每個提示詞要放什麼、順序為何，哪些工作交給 Plan Mode，哪些透過/compact處理。本指南只涵蓋其中一個組成部分。

工作階段中會累積什麼？哪些內容無法刪減？#

模式 4. 工具輸出會在工作階段中持續累積

有個很少人提到的細節：Claude 執行bash cat huge-file.log時，該指令的完整輸出都會進入上下文，並一直保留到工作階段結束或執行/clear為止。用Read讀取大型檔案也是一樣——10,000 行都會保留下來，在後續每則訊息中持續占用 token（見模式 2）。

解決方法：

1. 用head、tail、grep取代讀取全部內容。用bash tail -100 deploy.log代替Read deploy.log。輸出會立即減少 10-100 倍。
2. 用 hooks 預先處理。在~/.claude/hooks放入腳本，在 Claude 看到 bash 輸出之前先進行篩選。Anthropic 文件中的範例是 PreToolUse hook，執行npm test 2>&1 | grep -A 5 -E 'FAIL|ERROR'，而不是印出完整測試輸出。這能將內容壓縮 50-100 倍。詳情請見「2026 年的 Claude Code Hooks：逐步設定與 7 個現成範例」。
3. 大量讀取後執行/clear。如果你為了某個特定任務讀取了大型檔案，之後也不再需要，就不要「以防萬一」把它留在上下文裡；直接開啟新聊天。

模式 5. 系統提示詞 + 系統工具 = 固定的基準用量

這種模式無法改變，因為你幾乎無能為力。Claude Code 啟動時會載入系統提示詞（約 3 200 個 token）和所有內建工具的說明——Read、Edit、Write、Bash、Glob、Grep、WebSearch、WebFetch、TodoWrite（約 16 100 個 token）。合計為19 300 個 token的固定基準用量，無法刪減。

實際上可以這樣做：

• 先了解。要知道固定的 19K「基本稅」：在 200K 視窗中，200K - 19K = 181K 可供其他內容使用（還要扣除 CLAUDE.md、MCP 和自動壓縮緩衝區）。1M 視窗的空間比較大，但每次請求仍會帶著這筆「基本稅」。
• 測量重複處理。基準內容占用視窗，也可能在後續請求重現，並不是每個工作階段只收一次 token 費。計算成本應分開看輸入、快取寫入、快取讀取與輸出總量。

Skills、plugins 和 agent teams 會在哪裡消耗 token？#

模式 6. Skills 和 plugins 可能重複註冊

這個問題隨著 plugins 在 2025 年底加入 Claude Code 而出現。安裝會新增 skills 的 plugin 後，這些 skills 就會進入上下文。如果你也在~/.claude/skills/安裝了類似的 user skills，它們也會載入。有時候兩者還會重複。

Vercel 在 AI 技術堆疊研究中分享了一項數據：工作階段中有 56% 的 skills 從未被呼叫，但它們的說明卻持續載入上下文。每個說明以 100 個 token 計算，100 個 skills 最多會帶來 5 600 個 token 的「行李」。

可以這樣做：

1. 用/context查看實際占用狀況。如果 Skills 區塊超過 3K，就整理一下。
2. 執行ls ~/.claude/skills/，查看已安裝的 skills。刪除超過一個月沒用過的項目。
3. 對你安裝來「試用」後就忘記的 plugins 執行/plugin remove。

「2026 年的 Claude Code Skills：如何打造個人 Skills 資料庫」介紹了 Skills 的適當結構，以及它們和 CLAUDE.md 的差異。

模式 7. Agent teams 在 Plan Mode 中會多消耗 7 倍 token

Agent teams 是一種讓 Claude Code 啟動多個平行模型執行個體的功能，每個執行個體都有自己的上下文。Anthropic 在文件中直接表示：

也就是說，Plan Mode 中的五名團隊成員等於五個平行工作階段，各自載入系統基準用量、自己的 CLAUDE.md 副本和 MCP 工具。總 token 用量會以非線性方式增加。

可以這樣做：

1. 團隊成員使用 Sonnet 或 Haiku。只讓負責協調的團隊主管使用 Opus。每 token 費率可能較低，但應測量各成員完整任務成本與品質，不要假設固定節省幅度。
2. 縮小團隊規模。用兩三名團隊成員，而不是十名。
3. 清除閒置的團隊成員。任務結束後，如果成員仍在執行，就會繼續在背景消耗 token。

Plan Mode的更多資訊，以及它何時真正有幫助，請見「Claude Code 的 Plan Mode：2026 年逐步指南與 4 個階段」。

你沒注意時，Claude 會在哪些情況下計入 token？#

模式 8. Extended thinking 會在你沒有參與時消耗 token

Extended thinking 是 Claude 在回答前，先於隱藏的思考區塊中「推演」解法的模式。計算時，這些內容會視為輸出 token，和一般回覆一樣列入計算，但聊天中看不到它們。

Anthropic 在文件中表示：

這表示，單一複雜請求就可能用掉 10-30K 思考 token，侵蝕你的額度，但你在聊天中只看得到簡短摘要。

可以這樣做：

1. 簡單任務使用 /effort low。它會把思考預算降到最低。
2. 在環境中設定 MAX_THINKING_TOKENS=8000，設下上限。
3. 對於 Claude 不需要「思考」的日常例行任務，可以使用/config → 停用 thinking。

複雜架構、多步驟推理等情況下何時適合使用 thinking、何時不適合，請見「Claude Code 中該用 Sonnet 還是 Opus 4.7：2026 年的模型與 /effort 選擇指南」。

模式 9. 閒置時執行背景摘要

這種模式影響很小，但很有意思。Claude Code 會在背景執行程序，為claude --resume指令整理先前工作階段的摘要。即使你沒有輸入，程序仍會執行。

Anthropic 在相關文件中明確指出：

每個工作階段 4 美分不算什麼。但如果你一天開著 10 個工作階段，被動消耗就已經是每天$0.40、每月$12。關閉目前不需要的工作階段即可。你可以從索引執行/resume還原工作階段，不必一直開著。

如何測量 token 流失：/context指令與其注意事項#

先介紹指令。在 Claude Code 中開啟/context（或用/usage查看計算結果），會看到類似以下的內容：

上下文視窗: 200 000 tokens

系統提示詞:              3 200 (1.6%)
系統工具:               16 100 (8.0%)
MCP 工具:               12 600 (6.3%)
CLAUDE.md:                4 800 (2.4%)
記憶檔案:                 3 000 (1.5%)
對話:                   18 400 (9.2%)
可用空間:              141 900 (71.0%)

這是初步清理後正常的固定基準用量。很好——視窗有 71% 的空間可用。

已知的/context錯誤：MCP 用量高估 3 倍

直到近期更新之前，/context顯示的 MCP 流失量約為實際數字的 3 倍，因為每項工具的額外負載都會分別計算。

Cameron 表示，Anthropic 已在目前版本修正這個問題；同一個 XcodeBuildMCP 現在會顯示 12 600。因此：

1. 如果/context顯示 MCP 工具占用 50K 以上——你可能使用的是舊版 Claude Code。請更新。
2. 如果 MCP 是 8-15K——這很正常，代表使用 Tool Search 時的實際成本。
3. 如果新版的 MCP 是 30-50K——你確實連接了許多未使用的伺服器。前往/mcp並中斷連線。

除了/context之外還要查看什麼

/usage—顯示過去 24 小時或 7 天的方案用量。在 Pro 和 Max 中，它會列出 skills、subagents、plugins 和個別 MCP 伺服器的用量明細，方便找出哪個 skill 消耗最多。

/cost—供 API 使用者查看。會以美元顯示目前工作階段按比例分攤的成本。Pro/Max 訂閱者不需要這項功能。

/usage-credits—在 Pro/Max 中可設定每月支出上限。如果你不想讓指令碼啟動的 agent team 意外刷爆信用卡，這項功能就很有用。

如何在 15 分鐘內整理 Claude Code 的上下文#

在 Claude Code 中開啟專案，依序完成以下步驟：

1. /context—記下目前的用量明細，作為基準。
2. /clear—如果聊天累積了與目前任務無關的歷史紀錄，就執行這項指令，開啟全新的視窗。
3. ls -la ~/.claude/skills/—查看已安裝的 skills。刪除一個月沒用過的項目。指令：rm -rf ~/.claude/skills/[skill-name]（或透過介面刪除資料夾）。
4. /plugin list—同樣檢查 plugins。使用/plugin remove <name>移除不再使用的項目。
5. /mcp—查看已連線的 MCP 伺服器。只保留目前任務需要的項目，其餘使用/mcp disconnect <name>中斷連線。
6. 用編輯器開啟 CLAUDE.md。如果檔案超過 200 行，就把專門用途的指示移到 Skills（~/.claude/skills/[topic]/SKILL.md）。目標是保留 100-200 行的核心內容，以及 5-15 個主題 Skills。詳細指南請見「如何在 2026 年設定 CLAUDE.md：現成範本與 6 個規則」。
7. 檢查/effort—簡單任務使用/effort low。只有複雜架構任務才需要較高的 thinking 預算。
8. 最後再次測量/context，並和步驟 1 比較。

本文描述的工作階段中，清理後上下文占用從 60–80K 降至 25–30K。這是快照占用變化，不是總處理 token 或成本固定下降的證明。宣稱節省前，請比較同一任務完整執行，包括快取與輸出用量。

如果你想進一步理解 token，並建立一套完整的 Claude 工作方法論——包括AI 分身、Second Brain（business/）和上下文工程——這三者就是方法論的組成部分。

什麼時候改用 Sonnet 或 Haiku，比整理上下文更有效？#

Anthropic 在文件中談到模型時寫道：

輸入 token 價格概略比較（截至 2026 年 5 月 27 日）：

我的設定：

1. 預設使用 Sonnet 4.5。在/config → default model中設定，能處理 80% 的任務。
2. 遇到真正困難的任務（架構選擇、診斷難以理解的錯誤、新產品）時，手動執行/model opus。
3. 測試和格式整理使用/model haiku，或在 subagent 設定中明確指定model: haiku。
4. /effort與模型分開設定。你可以在 Opus 上使用/effort low——以精簡的思考量使用強大的模型，快速處理中等難度的問題。

以下情況，整理上下文比更換模型更值得：

• 上下文使用量超過 50%——先整理。
• 上下文狀況良好，但任務很複雜——使用正常 effort 的 Opus。
• 上下文狀況良好，任務屬於日常工作——使用 Haiku。

模型與 effort 的詳細比較，請見「Claude Code 中該用 Sonnet 還是 Opus 4.7：2026 年的模型與 /effort 選擇指南」。

哪些技巧會增加用量，反而無法節省 token？#

反模式 1.「刪掉所有會消耗 token 的 MCP」

最常見的錯誤就是懶得整理。沒錯，MCP 過去最多會消耗 49% 的上下文，但 Tool Search 推出後已降至 8-15%。而且 MCP 提供了實用工具，否則你得自己手動打造。刪掉所有 MCP，就等於回到人工操作，耗掉的時間可能比省下的 token 還多。

正確做法是只保留你經常使用的 MCP 伺服器。我會保留 Playwright（測試 landing page）和 shadcn（產生介面），其他的則視個別任務使用。

反模式 2.「不要用 CLAUDE.md，所有內容直接放進提示詞」

聽起來「很合理」：既然 CLAUDE.md 每次請求都會載入，那就不要載入它。但實際上，沒有 CLAUDE.md 時，你每次傳送訊息都得手動輸入相同指示，而且 Claude 也會在訊息之間忘記上下文。這樣消耗的 token 反而更多——只是改由另一個管道傳送。

正確做法是讓 CLAUDE.md 保持精簡（100-200 行），放入核心內容，並將專門用途的內容移到 Skills。詳情請見「如何在 2026 年設定 CLAUDE.md」。

反模式 3.「永遠用 Plan Mode 工作」

對於需要先探索程式碼庫並提出計畫的複雜任務，Plan Mode 是很棒的工具。但透過 agent teams 使用時，平均會多消耗7 倍 token（Anthropic 文件）。像「修正 README 中的拼字錯誤」這種簡單任務，用 Plan Mode 會比直接編輯多消耗 7 倍。

正確做法是只在需要 30 分鐘以上的複雜任務中使用 Plan Mode。短任務直接提出請求，不必使用 Plan Mode。各模式的適用情況請見「Claude Code 的 Plan Mode：2026 年逐步指南與 4 個階段」。

更多資料請見 Ailoot。