Claude Code 如何避免長對話變慢與費用增加

如何避免 Claude Code 長時間對話導致變慢與費用增加

Claude Code 的對話若持續過長，會因每一輪對話都需重新發送完整上下文而導致速度變慢且費用增加，且上下文只會不斷累積。解決方法是依序執行維護作業。執行 /context 查看佔用視窗的內容，移除每次請求都會產生費用的項目，接著在處理不相關的任務之間執行 /clear，並在單一長任務中使用 /compact 搭配指令。請以連續的工作時段進行作業，因為冷啟動的 prompt cache 會將低成本的讀取轉變為對所有已輸入內容的完整重寫。

關於為何會產生計費，詳見 代理對話背後的 token 計費機制。

在變更任何內容前請先閱讀 /context

不要臆測視窗內的內容。Claude Code 會告知您。

/context [all] 以彩色網格繪製目前的 context 使用量，並針對 context 負載過重的工具與記憶體膨脹提供優化建議；all 則以全螢幕模式展開各項目的詳細分析。請將結果視為五個儲存區：

• 系統提示詞 (System prompt)。 Claude Code 自身的運作指令。在工作階段期間固定不變。
• 工具定義 (Tool definitions)。 代理程式可呼叫的每個工具之架構，包含所有已連接的 MCP (Model Context Protocol) 伺服器。
• 記憶體檔案 (Memory files)。 CLAUDE.md 與自動記憶體，於工作階段啟動時載入。
• 檔案與工具結果 (Files and tool results)。 讀取的每個檔案，以及您指令所輸出的所有內容。
• 訊息歷史 (Message history)。 您的對話輪次與其回覆。

前三項為固定成本，在工作階段期間的每次請求皆需支付。後兩項則會隨時間增長。請在開始時削減一次固定成本；並持續管理增長的部分。

以下兩個字串代表視窗已滿：

Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.
Context is 94k tokens past the 200k-token compaction window — run /compact to reduce usage.

前者為硬性限制，請求將被拒絕；對應的 API (application programming interface) 錯誤訊息為 Prompt is too long。後者為壓縮視窗，在 100 萬 token 的模型中，其數值可能低於模型實際的 context 視窗。請求在超過此數值後仍可成功，因此這僅為警告而非拒絕。

在付費方案中，/usage 會補足剩餘部分，標記如長 context 或快取未命中 (cache misses) 等行為，並將近期使用量歸因於個別技能、子代理程式與 MCP 伺服器。若系統告知額度已用盡，您正在等待的限制視窗將決定縮減 context 是否能立即解決問題，或是您需要尋找其他工作路徑。

CLAUDE.md 是永久性的內容負擔，因此應保持精簡

您的 CLAUDE.md 會在工作階段開始時載入，並持續保留在上下文中。如果其中包含詳細的部署程序，那麼即使您只是在測試檔案中修正拼字錯誤，這些 token 仍會存在。Anthropic 建議只納入必要內容，並將檔案控制在 200 行以內。

請將程序移至 skills。只有在叫用 skill 時才會載入，因此每週執行兩次的工作流程，不會在其他日子佔用任何成本。壓縮後，skills 會有自己的額度；每個 skill 上限為 5,000 tokens，總上限為 25,000 tokens，並優先捨棄最舊的內容。截斷時會保留檔案開頭，因此請將最重要的指示放在 SKILL.md 的前段。

壓縮後仍能保留的內容，決定了指示應放置的位置。

• system prompt 與輸出樣式不會改變，因為它們不屬於訊息歷程。
• 專案根目錄的 CLAUDE.md、未限定範圍的規則，以及自動記憶體會從磁碟重新注入。
• 具有 paths: frontmatter 的規則會遺失，直到再次讀取相符的檔案。
• 子目錄中的巢狀 CLAUDE.md 會遺失，直到再次讀取該子目錄中的檔案。
• Hooks 仍會持續執行，因為 hook 是以程式碼執行；只有 hook 先前加入的上下文會與其餘對話一併摘要。

因此，您所依賴的規則應放在專案根目錄的 CLAUDE.md：Claude Code 會先清除較早的工具輸出，再進行摘要，因此對話早期的指示可能會遺失。請使用 /memory 編輯記憶體。Claude Code 會保留工作階段開始時載入的副本，因此工作階段中途進行的精簡會保留 prompt cache，並且要到下一次 /clear、/compact 或重新啟動時才會套用。上下文遺失只是規則停止遵循的其中一個原因；因此，當規則明顯仍在上下文中，卻依然未被遵循時，請先 逐一排查其他原因，再重新撰寫規則。

任務之間使用 /clear，單一任務內使用 /compact

這兩者看似可以互換，但成本差異很大。

/clear [name] 會在沒有既有上下文的情況下開始新的對話。它不會傳送請求，因此不會產生成本。傳入名稱即可在 /resume 選擇器中標記上一個對話；/reset 與 /new 是別名。切換到無關任務時，應立即使用它，否則舊任務會在新任務的每則訊息中重複傳送並再次計費。

/compact [instructions] 會在繼續同一個對話的同時釋放上下文：它會摘要目前的歷史記錄，並以摘要取代原內容。適合在仍需要延續性的單一長期任務中使用。

一律為 /compact 提供指示。 單獨執行 /compact 時，會依據不知道你仍需要哪個工作部分的預設提示進行摘要。提供指示則可保留以下內容：

/compact focus on the auth bug fix
/compact keep only the plan and the diff

如果每次都因為相同原因執行 compact，請在專案的 CLAUDE.md 中，於 # Compact instructions 標題下加入固定指示。在新工作階段中，/compact 會輸出 Not enough messages to compact.，表示對話回合太少，無法進行摘要；即使上下文已滿，也可能發生這種情況，例如單次大型貼上內容就填滿了上下文。

這裡常會混淆兩種成本。摘要請求會共用前綴，因此會讀取現有快取，而不是重新處理歷史記錄；大部分時間都花在產生摘要。壓縮大型上下文仍然是大型請求，因為要摘要的對話就是輸入內容。壓縮後的下一回合並不是耗時部分：它只需為較短的提示重建快取。

另外有兩個成本較低的命令。/rewind 會將程式碼與對話回復到檢查點；如果要完全放棄某條路徑，這比 compact 更適合，因為它會截斷回已快取的前綴。/recap 會將摘要附加為命令輸出，而不是取代歷史記錄，因此快取的前綴仍可保留。

自動 compact 反覆觸發時，會輸出以下內容：

Autocompact is thrashing: the context refilled to the limit...

compact 已成功，但檔案或工具輸出連續數次重新填滿上下文視窗，因此 Claude Code 停止重試。若要復原，請依行號範圍讀取過大的檔案、執行 /compact 並指定會排除大型輸出的 focus、將該工作移交給 subagent，或在早先的對話已不再需要時使用 /clear。

MCP server 是固定的額外負擔

每連線一個 MCP server，整個工作階段的每次請求都會增加負擔。無論你是否呼叫該 server，都必須支付這項成本。

Claude Code 可降低這項影響。MCP 工具定義預設會延後載入，因此在 Claude 使用特定工具前，只有工具名稱會進入上下文。執行 /context 可查看各 server 的實際成本，執行 /mcp disable <name> 可移除今天不會使用的 server。如果你在 VPS 上執行自有的 MCP server，相同的計算方式也會限制單一 server 應公開的工具數量。

請在工作階段開始時執行這項操作。定義維持延後載入時，連線或中斷 server 只會附加到對話中，快取也會保留。若工具搜尋已停用、不可用，或低於 auto 閾值，導致定義改為載入前綴，則相同的變更會使下一次請求重新讀取全部內容。

在工具輸出進入上下文前進行過濾

工具的執行結果會被視為輸入，並在後續的每一輪對話中被重複發送。若一次測試執行產生 20,000 個 token 的輸出，這並非一次性成本：在該輸出離開上下文視窗前，每一輪對話您都必須為此付費。

請在來源端進行過濾。透過 Hook 將測試結果縮減為僅顯示失敗項目，再傳送給 Claude，即可將原本龐大的輸出量縮減為數百個 token，這不僅適用於當前對話，也能節省後續每一輪重新發送時的成本：

npm test 2>&1 | grep -E "FAIL|Error:" | head -40

Hook 本身不會進入上下文，因為它們是以程式碼形式執行。對於任何輸出長度超過一個螢幕的工具，請務必採取此作法。同樣的邏輯也適用於 3,000 行的檔案：請僅請求您所需的行數範圍，因為一旦整個檔案進入視窗，它就會一直佔用空間。

限制代理程式的讀取範圍並委派繁瑣工作

若提示詞明確指定檔案與徵狀，代理程式僅會讀取該檔案。若僅發出「整理專案」的模糊請求，代理程式會自行判斷相關檔案並全數讀取，這些讀取紀錄將佔用上下文視窗。

將繁瑣工作委派給子代理程式（subagent）。執行測試與處理日誌皆會消耗實際的上下文資源；子代理程式會將輸出保留在各自的視窗中，僅回傳摘要結果。權衡之處在於：子代理程式需建立專屬快取，首次呼叫時無法命中快取，且即使在訂閱模式下，快取存活時間仍為 5 分鐘。委派機制能有效保護主上下文，但未必能降低總 Token 用量。

快取時鐘：分段工作

Prompt caching 讓重送內容的成本變得可負擔。寫入前綴的費率是基本輸入費率的 1.25 倍；若使用一小時生命週期，則為 2 倍。在 Haiku 5.5 上讀取快取的費率是 0.1 倍，在 Opus 5.5 和 Sonnet 5.5 上是 0.05 倍（每百萬 tokens 為 $0.20 和 $0.10），在 Fable 5.1 上是 0.025 倍（每百萬 tokens 為 $0.25）。每次使用都會以零額外成本重新整理項目，因此計時會從上次使用開始。這些倍率能說明帳單的結構，但無法表示實際金額；請搭配每百萬 tokens 的實際成本，將完整 context window 換算成美元金額。

你取得的生命週期取決於驗證方式。這也是籠統說「你的快取會在五分鐘後到期」不正確的原因。

• 使用 Claude 訂閱時，Claude Code 會自動要求一小時的生命週期。
• 超過方案額度並開始使用 usage credits 後，這些用量會計費，因此生命週期會恢復為五分鐘。
• 使用 API key 或 cloud provider 時，生命週期維持五分鐘。將 promptCacheTtl 設為 1h 或 ENABLE_PROMPT_CACHING_1H=1，即可選用一小時的生命週期；FORCE_PROMPT_CACHING_5M=1 則會強制恢復為五分鐘。

無論採用哪種方式，節奏建議都相同：請持續工作一段時間。因為閒置時間超過生命週期後，下一個回合就必須重新寫入累積的完整前綴。在 tmux 中分離 Claude Code 工作階段在閒置時不會產生成本；但閒置期間放棄的是仍處於暖機狀態的快取。

有些操作會在你仍持續工作時捨棄快取：切換模型、在舊版模型上變更 effort level、啟用 fast mode、連線或中斷 MCP server、在工具定義預先載入時拒絕整個工具、啟用或停用會加入工具的 plugin、compact、在對話包含過多影像後移除舊影像，以及升級 Claude Code。在使用 API key 或訂閱的 Opus 5.5、Sonnet 5.5、Haiku 5.5 和 Fable 5.1 上，變更 effort level 現在會保留快取。/model 通常最令人意外，因為每個模型都有自己的快取。因此，即使內容完全相同，下一個請求仍會讀取完整歷史，而且沒有任何快取命中。這次重新讀取會依目標模型的費率計費，視為新的快取寫入。因此，在工作階段中途切換至 Fable，會將累積的完整歷史依Fable 公開的快取寫入費率計費：五分鐘生命週期為每百萬 tokens $12.50，一小時生命週期為 $20；Fable 5 和 Fable 5.1 的費率相同。

編輯檔案、編輯 CLAUDE.md、呼叫 skills 和 commands、執行 /recap、rewind，以及建立 subagent 都會保留快取。快取的範圍限於一台機器和一個目錄，因此位於不同目錄的兩個工作階段無法共用快取。這個範圍依 CLI 而非帳戶決定，因此不會延續到 Claude desktop app；在 Linux 上，Claude desktop app 是與 CLI 並存的獨立 beta 安裝。

若要確認快取是否正常運作，請讀取 current_usage。cache_creation_input_tokens 依快取寫入費率寫入；cache_read_input_tokens 則依模型的快取讀取費率提供，視模型而定，介於標準輸入費率的 2.5% 至 10%。讀取與建立的比例高是正常現象。如果建立費用逐回合維持偏高，表示前綴中的某些內容持續變動。

更大的上下文視窗能解決這個問題嗎？

部分可以。目前所有模型（Fable 5.1、Opus 5.5、Sonnet 5.5 和 Haiku 5.5）都使用 1 million token 的上下文視窗；在更大的上限下，壓縮機制的運作方式也相同。經濟效益不會改變，因為完整提示仍會在每次互動時重新傳送，且每次都會計費。更大的視窗決定何時必須採取行動；內容整理則決定成本。如果問題在於費用而非上限，哪種 Claude 方案符合你的工作方式會決定你是支付費用，還是使用方案額度。

API 中的內容編輯與壓縮是不同功能

如果您是使用 Messages API 建立自己的代理程式，API 不提供斜線指令，必須自行實作。請從一開始就編列這項工作的預算，因為API 提供的免費額度不會支付您的 token 費用。新使用者會獲得少量免費點數，用於測試 API；Anthropic 在定價頁面列出的固定額度（每個組織每天 50 個免費小時，文件中則列為每月 1,550 個小時）涵蓋的是程式碼執行容器時間，該費用與 token 分開計算。每次請求都會重新傳送未裁切的歷史記錄，並為全部內容計費：前綴已快取時，按照快取讀取費率計費；未快取時，則按照完整輸入費率或快取寫入加價計費。您選擇的服務供應商會在任何裁切發生前決定這套計算方式。因此，如果尚未決定，請在兩個 API 上分別計算相同工作負載的成本，不要只比較每個 token 的標示費率。伺服器端有兩項功能可以處理這項工作，但兩者並不相同。

內容編輯會隨著對話歷史記錄增長，選擇性清除其中的特定內容，並以預留位置文字取代每個已清除的結果，讓 Claude 知道有內容遭到移除。這是 beta 功能：傳送 anthropic-beta: context-management-2025-06-27，並在 context_management.edits 下設定策略。clear_tool_uses_20250919 會清除工具結果，clear_thinking_20251015 則管理思考區塊。其 trigger 預設為 100,000 個輸入 token，keep 預設為最近 3 次工具使用，clear_tool_inputs 預設為 false，因此會保留輸入內容，只移除結果。

壓縮會產生摘要，並以摘要取代完整的對話歷史記錄。此功能有兩種 beta。閾值壓縮會在一般請求中執行：傳送 anthropic-beta: compact-2026-01-12，並使用編輯類型 compact_20260112。觸發值預設為 {"type": "input_tokens", "value": 150000}，且必須至少為 50,000。隨選壓縮則讓您的程式碼決定執行時機：傳送 anthropic-beta: compact-2026-09-04，並在頂層設定 "compaction": {"type": "summarize"}；回應內容只有摘要區塊。Anthropic 的壓縮概覽指出，只要支援隨選壓縮，就應優先使用。

閾值壓縮有一項容易被忽略的交接規則，可能導致代理程式無法正常運作。回應會先提供包含摘要的 compaction 內容區塊，接著才是一般文字區塊。後續請求必須傳回該區塊，API 隨後會捨棄它之前的所有內容區塊。實際上，請附加完整的 response.content，不要只附加其中的文字。隨選壓縮的處理方式相反：您必須自行移除已摘要的訊息，將回傳的區塊放在 messages 的開頭，並按照原樣傳回，包括 signature。

Anthropic 的文件將伺服器端壓縮列為管理長時間對話內容的主要策略，並將內容編輯列為更細緻控制清除內容的選項。請先確認模型支援情況。目前所有模型都支援這兩種壓縮方式，包括 Haiku 5.5；較舊的 claude-haiku-4-5 不支援，而每個壓縮功能頁面都會列出最新的支援清單。這些 beta 功能都不會控制 Claude Code 自身的 /compact；其文件說明，該功能是由用戶端將歷史記錄傳送出去的獨立摘要請求。

FAQ

為什麼 Claude Code 工作階段執行越久，速度越慢、成本越高？

因為每一輪都會再次傳送完整對話，所以在工作階段開啟一整天後提出一行問題，也會連同整天的對話一起傳送。Prompt caching 在快取仍有效時可降低成本：Haiku 5.5 的讀取費率是基礎輸入費率的 0.1x，Opus 5.5 和 Sonnet 5.5 是 0.05x，Fable 5.1 是 0.025x。某一輪未命中快取後，相同前綴會以 1.25x 的費率重新寫入；若使用 one-hour lifetime，則為 2x。執行 /context 可查看哪些內容正在佔用 context window，並閱讀 Claude Code 工作階段的計費方式 了解其中機制。

Claude Code 中的 /clear 與 /compact 有何不同？

/clear 會在空白 context 下開始新的對話。它不會傳送請求，因此不會產生費用，適合用於不相關任務之間。/compact 會保留相同對話，並以摘要取代歷史記錄，因此適合在同一項長期任務中使用。請提供明確焦點，例如 /compact keep only the plan and the diff，因為該指示會決定哪些內容得以保留。

如何查看哪些內容正在耗用 Claude Code 的 context window？

執行 /context；若要查看完整的逐項明細，則執行 /context all。它會以彩色網格顯示 system prompt、工具定義、MCP servers、memory files 及歷史記錄，並針對大量使用 context 的工具與 memory 膨脹提供建議。在付費方案中，/usage 也會將近期使用量歸因至個別 skills、subagents 及 MCP servers。

我應使用 1 million token context window，而不是進行 compacting 嗎？

較大的 window 只能延後問題，無法解決問題。每個目前的模型（Fable 5.1、Opus 5.5、Sonnet 5.5 及 Haiku 5.5）都使用 1 million token context window，且 compacting 在其中的運作方式相同。每一輪仍會重新傳送完整 prompt，也仍會依此計費，因此 400,000-token 的對話無論是否能容納，成本都很高。

Claude API 中的 context editing 與 compaction 有何不同？

Context editing 會選擇性清除舊內容，主要是工具結果，並在每個結果原本的位置留下 placeholder text，讓 Claude 知道該內容已被移除。Compaction 會產生摘要，並以摘要取代完整歷史記錄。Anthropic 的文件將 compaction 稱為長時間執行對話的主要策略，並將 context editing 定位為更細緻的選項。兩者都是各自搭配 headers 的 beta 功能，也都與 Claude Code 的 /compact 分開。