Claude Code 會話過久變慢且變貴怎麼辦？

如何避免 Claude Code 會話過久導致速度變慢且成本增加

Claude Code 會話時間過長會導致速度變慢且成本增加，因為每一次對話都會重新傳送完整的 context，且該 context 會持續增長。解決方法是依序進行維護。先執行 /context 查看哪些內容佔用視窗空間，刪除每次請求都會產生的付費項目，接著在不相關的任務之間使用 /clear，並在單一長任務中使用包含指令的 /compact。請分段進行工作，因為冷卻的 prompt cache 會將低成本的讀取變成對所有對話內容的完整重寫。

關於計費原理的詳細說明，請參閱 agent session 的 token 計費機制。

在進行任何變更前，請先閱讀 /context

請勿猜測視窗內容。Claude Code 會直接告知。

/context [all] 以彩色網格顯示目前的 context 使用量，並針對 context 負載過重的工具與記憶體膨脹提供優化建議；all 可在全螢幕模式下展開各項細節。請將結果視為五個區塊。

• The system prompt。Claude Code 自身的架構指令。在該 session 中是固定的。
• Tool definitions。Agent 可呼叫的所有工具之 schema，包含所有已連接的 MCP (Model Context Protocol) server。
• Memory files。CLAUDE.md 與自動記憶體，於 session 開始時載入。
• Files and tool results。所有讀取的檔案，以及指令回傳的所有輸出內容。
• Message history。您的提問與其回覆。

前三者是固定成本，在整個 session 期間的每次請求都會產生。後兩者會持續增長。請在開始時一次性減少固定成本；並持續管理增長的部分。

若視窗已滿，會出現兩個字串：

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。第二個是壓縮視窗，在 1 million token 模型上，其數值可能低於模型的實際 context window。超過此值時請求仍會成功，因此該訊息是警告而非拒絕。

在付費方案中，/usage 會提供另一半資訊，標記長 context 或 cache miss 等行為，並將近期使用量歸類至個別的 skills、subagents 與 MCP servers。

CLAUDE.md 是永久性的成本，請保持精簡

您的 CLAUDE.md 會在 session 開始時載入至 context 並持續存在。若其中包含詳細的部署程序，當您僅在測試檔修正拼字錯誤時，這些 tokens 仍會佔用額度。Anthropic 的建議是僅包含必要內容，並將檔案控制在 200 行以內。

請將程序移至 skills。skill 僅在被呼叫時載入，因此每週執行兩次的 workflow 在其他日子不會產生任何成本。經過 compaction 後，skill 擁有獨立的額度：內容會重新注入，每個 skill 上限為 5,000 tokens，總計上限為 25,000 tokens，並會優先刪除最舊的內容。由於 truncation 會保留檔案開頭，請將最重要的指令放在 SKILL.md 的最上方。

哪些內容會在 compaction 後保留，決定了指令應存放的位置。

• system prompt 與輸出風格不會改變，因為它們不屬於 message history。
• project-root CLAUDE.md、unscoped rules 與 auto memory 會從磁碟重新注入。
• 帶有 paths: frontmatter 的 rule 會遺失，直到再次讀取匹配的檔案。
• 子目錄中的嵌套 CLAUDE.md 會遺失，直到再次讀取該子目錄中的檔案。
• Hooks 不受影響，因為 hook 是以程式碼方式執行，不會進入 context。

因此，您依賴的 rule 應放在 project-root CLAUDE.md：Claude Code 會先清除較舊的 tool outputs，接著進行摘要，因此對話早期的指令可能會遺失。使用 /memory 編輯 memory。Claude Code 會保留 session 開始時載入的副本，因此 session 中間的修剪會保留 prompt cache，且直到下一次 /clear、/compact 或重啟後才會生效。

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

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

/clear [name] 會以空的 context 啟動新對話。它不會發送任何 request，因此不產生任何費用。傳遞一個名稱至 /resume 選擇器，以便標記先前的對話；/reset 與 /new 為其別名。當切換至不相關的任務時，請立即使用此指令，否則舊任務的內容會在每個新訊息中被重複發送並重新計費。

/compact [instructions] 在維持相同對話的同時釋放 context：它會摘要目前的歷史紀錄並取代原內容。在需要保持連續性的單一長任務中使用此指令。

務必為 /compact 提供指令。 單獨使用 /compact 會對預設 prompt 進行摘要，該 prompt 無法得知您仍需完成的工作內容。提供指令後的摘要則能保留特定需求：

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

若每次進行 compact 的原因相同，請在專案的 CLAUDE.md 的 # Compact instructions 標題下設定固定指令。在新 session 中，/compact 會印出 Not enough messages to compact.，這代表目前尚無歷史紀錄。

此處容易混淆兩種成本。摘要 request 會共用您的 prefix，因此它會讀取現有的 cache 而非重新處理歷史紀錄，大部分時間花在生成摘要上。壓縮大型 context 仍屬於大型 request，因為被摘要的對話即為輸入內容。壓縮後的下一輪對話不會很慢：它會為大幅縮減後的 prompt 重建 cache。

還有兩個較便宜的指令。/rewind [description] 會將程式碼與對話回溯至檢查點；若要完全放棄某條路徑，此指令優於 compact，因為它會截斷至已快取的 prefix。/recap 會將摘要作為指令輸出附加在後，而非取代歷史紀錄，因此快取的 prefix 會保持完整。

自動執行 compact 若反覆觸發會印出此訊息：

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

Compaction 已成功，但檔案或工具輸出連續多次填滿了視窗，因此 Claude Code 已停止重試。解決方法包括：以行範圍讀取過大的檔案、使用 /compact 並指定排除大型輸出的 focus、將該工作移至 subagent，或是若先前的對話已結束則使用 /clear。

MCP servers 會產生固定開銷

連接的每個 MCP server 都會增加整個 session 中每次請求的負擔。無論是否呼叫該工具，都會產生開銷。

Claude Code 緩解了此問題。預設情況下，MCP tool definitions 會延遲載入，因此在 Claude 使用特定工具前，context 中僅包含工具名稱。執行 /context 可查看伺服器的實際成本，執行 /mcp disable <name> 則可移除今日不使用的伺服器。若您在 VPS 上執行自己的 MCP servers，同樣的計算邏輯也會限制單一伺服器應提供的工具數量。

請在 session 開始時執行此操作。雖然 definitions 會保持延遲載入，但連接或斷開伺服器僅會附加於對話中，且 cache 會保留。若因為關閉工具搜尋或伺服器豁免延遲載入，導致 definitions 直接載入至 prefix，則相同的變動會導致下一次請求必須重新讀取所有內容。

在進入 context 前過濾冗長的工具輸出

工具結果會作為輸入，且每次後續對話都會重新傳送該輸入。若測試執行產生 20,000 tokens 的輸出，這並非一次性成本：在該輸出移出 context 視窗前，每次對話都必須重複支付其費用。

請從來源端進行過濾。在 Claude 讀取之前，使用 hook 將測試結果縮減至僅包含失敗項目，這能將大量的輸出轉化為僅數百 tokens 的內容，無論是本次對話或後續重新傳送時皆然：

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

由於 hook 是以程式碼形式執行，因此本身不會進入 context。對於任何輸出量會超出螢幕範圍的工具，都應採用此做法。同樣的邏輯也適用於 3,000 行的文件：請僅要求所需的行數範圍，因為文件一旦載入，就會一直保留在 context 視窗中。

限定 Agent 的讀取範圍，並委派繁瑣工作

若 Prompt 中指定了檔案名稱與症狀，Agent 就會讀取該檔案。若要求整理專案，Agent 會讀取其認為相關的所有內容，且每一次讀取都會佔用 Context Window。

將繁瑣工作委派給 Subagent。測試執行與 Log 處理都會消耗大量 Context；使用 Subagent 可以將輸出保留在自身的 Window 中，僅回傳摘要。權衡點在於：Subagent 會建立自己的 Cache，首次呼叫時不會命中，且即使是訂閱用戶也會使用 5 分鐘的 Cache 有效期。委派機制能可靠地保護主 Context，但不一定能降低總 Token 消耗。

快取時鐘：分段作業

Prompt caching 是降低重傳成本的關鍵：讀取 prefix 的費用僅為基礎輸入費率的 0.1x，寫入費用為 1.25x；若使用一小時的有效期，寫入費用則為 2x。每次使用都會在不增加額外成本的情況下刷新該項目，因此時鐘從最後一次使用時開始計算。

有效期的長短取決於您的驗證方式，這也是為什麼「您的快取會在五分鐘後過期」這種籠統說法並不準確的原因。

• 若使用 Claude 訂閱方案，Claude Code 會自動請求一小時的有效期。
• 一旦超過方案額度並開始使用 usage credits，該用量會被計費，因此有效期會降回五分鐘。
• 使用 API key 或雲端供應商時，有效期維持在五分鐘。ENABLE_PROMPT_CACHING_1H=1 可選擇使用一小時的有效期，而 FORCE_PROMPT_CACHING_5M=1 會強制將其降回五分鐘。

無論哪種方式，作業節奏的建議皆相同：請進行連續的作業段落，因為若閒置時間超過有效期，下一次作業將必須重新寫入整個累積的 prefix。在 tmux 中的 detached Claude Code session 閒置時不會產生任何費用，而閒置時間所犧牲的就是預熱後的快取。

某些操作會在您工作時清除快取：切換模型、更改 effort level、開啟 fast mode、連接或斷開 MCP server、啟用或停用 plugin、拒絕整個 tool、進行 compacting 以及升級 Claude Code。/model 是常見的驚訝點，因為每個模型都有各自的快取，即使內容完全相同，下一個請求仍會讀取整個歷史紀錄且沒有任何 cache hits。

編輯檔案、編輯 CLAUDE.md、呼叫 skills 與 commands、執行 /recap、rewind 以及啟動 subagent 皆會保留快取。快取的範圍僅限於單一機器與單一目錄，因此不同目錄下的兩個 session 無法共用彼此的快取。

若要確認快取是否運作，請閱讀 current_usage。cache_creation_input_tokens 是以快取寫入速率生成的；cache_read_input_tokens 則是以約為標準輸入速率十分之一的速度提供服務。高讀取與建立比率（read-to-creation ratio）代表狀態良好。如果建立率持續維持在高點，代表您的 prefix 中有部分內容不斷在變動。

擴大 context window 能解決此問題嗎？

部分可以。目前有數款模型支援 1 million token 的 context window，且在較大的限制下，compaction 的運作方式並無改變。成本結構不會改變，因為每次對話仍需重新傳送完整的 prompt 並進行計費。較大的 window 決定了您被迫採取行動的時間點；而 hygiene 則決定了成本。若問題在於帳單而非容量限制，請參考 哪種 Claude 方案符合您的工作方式，以決定您是在支付費用或消耗方案額度。

API 中的 Context editing 與 compaction 是不同的功能

若您正在 使用 Messages API 建立自己的 agent，系統中不存在 slash commands，您必須自行實作。有兩項伺服器端功能可達成此目的，但兩者並非同一功能。

Context editing 會在對話紀錄增長時，有選擇性地清除特定內容。清除的結果會被 placeholder text 取代，以便 Claude 辨識內容已被移除。此功能目前為 beta 版本：請傳送 anthropic-beta: context-management-2025-06-27 並在 context_management.edits 下設定策略。clear_tool_uses_20250919 用於清除 tool results，clear_thinking_20251015 用於管理 thinking blocks。其 trigger 預設值為 100,000 input tokens，keep 預設為最後 3 次 tool uses，clear_tool_inputs 預設為 false，因此輸入內容會保留，僅清除結果。

Compaction 會生成摘要，並用該摘要取代完整的對話紀錄。此功能亦為 beta 版本：請傳送 anthropic-beta: compact-2026-01-12 並使用 edit type compact_20260112。觸發條件預設為 {"type": "input_tokens", "value": 150000}，且數值必須至少為 50,000。

Compaction 有一項會導致 agent 失效的交接規則。回應會以一個包含摘要的 compaction content block 開頭，隨後才是正常的 text block。您必須在後續請求中將該 block 傳回，API 隨後會捨棄該 block 之前的所有 content block。實際操作時：請附加整個 response.content，而不僅是 text。

Anthropic 的文件將伺服器端 compaction 稱為管理長對話 context 的主要策略，而 context editing 則是針對清除內容進行精細控制的選項。請先檢查模型支援度。目前的 Opus、Sonnet 與 Fable 模型支援 compaction；claude-haiku-4-5 不支援， compaction 頁面提供最新的支援列表。這兩項 beta 功能皆不驅動 Claude Code 的 /compact，其文件將其描述為由 client 發送的一次性 summarization request。

FAQ

為什麼我的 Claude Code 會話執行時間越長，速度越慢且成本越高？

因為每一輪對話都會重新傳送整個對話內容，因此在開啟一整天的會話中，僅僅問一個問題也會包含整天的對話內容。Prompt caching 在快取有效時能降低成本，讀取成本僅為基礎輸入費率的 0.1x；一旦快取失效，相同的內容會以 1.25x 的費率重新計算。請執行 /context 查看佔用視窗的內容，並閱讀 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、tool definitions、MCP servers、memory files 與 history，並針對佔用大量 context 的 tools 或 memory 提供建議。在付費方案中，/usage 還能將近期使用量歸類至個別的 skills、subagents 與 MCP servers。

我應該使用 1 million token 的 context window 而非進行 compaction 嗎？

使用較大的 window 只是延緩問題，而非解決問題。目前有數款模型支援 1 million token context window（包含 Opus 4.8 與 Sonnet 5），其 compaction 的運作方式相同。每一輪仍會重新傳送完整 prompt 並產生費用，因此 400,000-token 的對話無論是否超出限制，成本都會很高。

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

Context editing 會選擇性地清除舊內容（主要是 tool results），並在原位置保留 placeholder text，讓 Claude 知道該內容已被移除。Compaction 則會生成摘要並用其替換完整的歷史紀錄。Anthropic 的文件將 compaction 定義為長對話的主要策略，並將 context editing 定義為精細化控制的選項。兩者目前皆為 beta 版本，且皆獨立於 Claude Code 的 /compact。