SSD Nodes Learn Hosting plans →
指南 Matt Connor作者: Matt Connor · 已更新 2026-08-30

Claude Code 對話變慢與費用過高解決方案

Claude Code 對話過長導致效能下降與費用暴增?透過 /context 指令檢查佔用空間,並利用 /clear 與 /compact 優化記憶體,避免觸發 context window 限制與 API 錯誤。

如何避免 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)中。技能僅在呼叫時載入,因此每週執行兩次的流程在其他日子不會消耗成本。技能在壓縮後擁有各自的預算:內容會被重新注入,每個技能上限為 5,000 個 Token,總計上限為 25,000 個 Token,最舊的內容會優先被捨棄。截斷會保留檔案開頭,因此請將最重要的指令放在 SKILL.md 的頂端。

壓縮後留下的內容決定了指令的歸屬。

  • 系統提示詞與輸出風格不會改變,因為它們不屬於對話記錄的一部分。
  • 專案根目錄的 CLAUDE.md、未定義範圍的規則以及自動記憶體會從磁碟重新注入。
  • 帶有 paths: 前言的規則會遺失,直到再次讀取對應檔案為止。
  • 子目錄中的巢狀 CLAUDE.md 會遺失,直到再次讀取該子目錄中的檔案為止。
  • Hook 不受影響,因為 Hook 是以程式碼形式執行,不會進入內容中。

因此,您依賴的規則應放置於專案根目錄的 CLAUDE.md 中:Claude Code 會優先清除較舊的工具輸出並進行摘要,因此對話早期的指令可能會遺失。請使用 /memory 編輯記憶體。Claude Code 會保留工作階段開始時載入的副本,因此工作階段中途的修剪會保留提示詞快取,並在下一次 /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

若您每次壓縮的原因都相同,請將固定指令放入專案的 CLAUDE.md 檔案中,並置於 # Compact instructions 標題之下。在新的對話中,/compact 會顯示 Not enough messages to compact.,這僅代表目前尚無歷史記錄。

這裡容易混淆兩種成本。總結請求會共享您的前綴,因此它會讀取現有快取而非重新處理歷史記錄,大部分時間花在生成總結上。壓縮大型上下文仍屬於大型請求,因為被總結的對話本身就是輸入內容。壓縮後的下一輪對話並非慢速環節:它會為較短的提示詞重建快取。

此外還有兩個成本較低的指令。/rewind [description] 可將程式碼與對話回滾至檢查點;對於您想完全放棄的路徑,此指令優於壓縮,因為它會截斷回已快取的前綴。/recap 則是將總結作為指令輸出附加,而非替換歷史記錄,因此已快取的前綴能保持完整。

若自動壓縮反覆觸發,會顯示以下訊息:

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

壓縮已成功,但檔案或工具輸出多次填滿視窗,因此 Claude Code 停止重試。若要恢復,請透過行範圍讀取過大的檔案、執行 /compact 並聚焦於排除大型輸出、將該工作移交給子代理(subagent),或在舊對話已完成時使用 /clear

MCP 伺服器會產生固定開銷

您連接的每一個 MCP 伺服器都會增加整個對話階段中每次請求的負擔。無論您是否呼叫該伺服器,都必須支付此成本。

Claude Code 緩解了此問題。MCP 工具定義預設為延遲載入,因此只有工具名稱會進入上下文,直到 Claude 實際使用特定工具為止。執行 /context 可查看伺服器實際的成本,並執行 /mcp disable <name> 以移除今日不會用到的伺服器。若您在 VPS 上自行架設 MCP 伺服器,同樣的計算邏輯限制了單一伺服器應公開的工具數量。

請在對話階段開始時執行此操作。雖然定義保持延遲載入,但連接或中斷伺服器只會附加至對話紀錄,且快取會持續有效。若因關閉工具搜尋或伺服器豁免延遲載入,導致定義被載入至前綴(prefix)中,則同樣的變更會導致下一次請求重新讀取所有內容。

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

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

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

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

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

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

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

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

快取時鐘:分段工作

Prompt caching 是讓重新發送請求變得經濟實惠的關鍵:讀取前綴的費用僅為基礎輸入費率的 0.1 倍,相較之下,寫入費用為 1.25 倍,若以一小時為生命週期則為 2 倍。每次使用都會免費刷新項目,因此時鐘是從最後一次使用開始計算。這些倍率僅反映帳單的結構而非總額,請搭配 一百萬個 token 的實際成本,將完整的 context window 轉換為美元金額。

您獲得的生命週期取決於驗證方式,這也是為什麼「您的快取會在五分鐘後過期」這種一概而論的說法並不準確。

  • 若使用 Claude 訂閱,Claude Code 會自動請求一小時的生命週期。
  • 一旦超過方案限制並開始使用額度(usage credits),系統會針對該用量計費,生命週期將縮短為五分鐘。
  • 若使用 API key 或雲端供應商,生命週期固定為五分鐘。ENABLE_PROMPT_CACHING_1H=1 可選擇啟用一小時生命週期,而 FORCE_PROMPT_CACHING_5M=1 則會強制將其調回。

無論哪種情況,節奏建議皆相同:請進行連續的工作,因為若閒置時間超過生命週期,下一次請求時系統將會重新寫入整個累積的前綴。在 tmux 中執行的 Claude Code 離線工作階段 在閒置時不會產生費用,但閒置會導致快取失效。

某些操作會在您工作期間清除快取:切換模型、變更 effort level、開啟 fast mode、連接或中斷 MCP server、啟用或停用插件、拒絕使用工具、進行壓縮以及升級 Claude Code。/model 通常會帶來意外的費用,因為每個模型都有各自的快取,即使內容相同,下一個請求也會因為沒有快取命中而讀取整個歷史紀錄。該重新讀取的動作會以目標模型的費率計費,因此在工作階段中途切換至 Fable,將會以 Fable 5 公告的輸入費率 對您累積的完整歷史紀錄進行收費。

編輯檔案、編輯 CLAUDE.md、呼叫技能與指令、執行 /recap、倒轉(rewind)以及產生子代理(subagent)皆會保留快取。快取的範圍限於單一機器與單一目錄,因此在不同目錄下的兩個工作階段無法共用快取。此範圍依循 CLI 而非您的帳號,因此這些快取不會帶入 Claude 桌面應用程式;在 Linux 上,該程式是 與 CLI 並存的獨立 beta 安裝版本

若要確認快取是否運作,請閱讀 current_usagecache_creation_input_tokens 是以快取寫入費率寫入的;cache_read_input_tokens 則是以約標準輸入費率的十分之一進行服務。高讀取與建立比率(read-to-creation ratio)是健康的狀態。如果建立次數在每一輪請求中持續偏高,代表您的前綴中可能有內容不斷變動。

更大的 Context window 能解決這個問題嗎?

部分可以。目前已有數款模型支援 1 million token 的 context window,且壓縮機制在較大限制下運作方式相同。經濟效益並未改變,因為完整的 prompt 在每一輪對話中仍會被重新發送並計費。更大的視窗僅決定了您何時被迫採取行動;而資料清理(hygiene)才決定了成本。若問題在於帳單而非上限,哪種 Claude 方案適合您的工作方式 將決定您是直接支付美元還是消耗方案額度。

API 中的上下文編輯與壓縮是兩回事

若您正在 基於 Messages API 建構自己的 Agent,由於不存在斜線指令,您必須自行實作相關功能。請務必從一開始就將此工作納入預算,因為 該 API 除了少量的註冊抵用金外並無免費層級,未經修剪的歷史紀錄每一輪對話都會全額計費。您選擇的供應商決定了修剪前的計算方式,因此若選擇尚未定案,請務必 針對相同工作負載評估兩者的 API 成本,而非僅比較帳面上的每 Token 單價。伺服器端有兩項功能可處理此需求,但它們並非同一功能。

上下文編輯 (Context editing) 會在對話歷史增長時,選擇性地清除特定內容,並以預留位置文字取代,讓 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,因此輸入內容會保留,僅清除執行結果。

壓縮 (Compaction) 會產生摘要並取代完整的對話歷史。此功能同樣為 Beta 版:請發送 anthropic-beta: compact-2026-01-12 並使用編輯類型 compact_20260112。觸發條件預設為 {"type": "input_tokens", "value": 150000},且數值必須至少為 50,000。

壓縮功能有一項交接規則,若未處理會導致 Agent 無法運作。回應會以包含摘要的 compaction 內容區塊開頭,隨後才是正常的文字區塊。您必須在後續請求中將該區塊傳回,API 隨後會捨棄該區塊之前的所有內容區塊。實務上:請附加整個 response.content,而不僅僅是文字部分。

Anthropic 的文件將伺服器端壓縮視為管理長期對話上下文的主要策略,而將上下文編輯視為針對清除內容進行精細控制的選項。請先確認模型支援度。目前的 Opus、Sonnet 與 Fable 模型支援壓縮;claude-haiku-4-5 則不支援,請參閱壓縮功能頁面以獲取即時清單。這兩項 Beta 功能皆不會驅動 Claude Code 自身的 /compact,該功能在文件中被描述為客戶端發送的一次性摘要請求。

FAQ

為什麼 Claude Code 的對話時間越長,速度越慢且費用越高?

因為每一輪對話都會重新發送整個對話紀錄,因此當對話視窗開啟一整天後,即便只問一個簡單的問題,也會包含整天的對話內容。Prompt caching 能在快取有效時降低成本,讀取費用僅為基礎輸入費率的 0.1 倍;一旦發生快取未命中(miss),相同的字首就會以 1.25 倍的費率重新寫入。請執行 /context 查看佔用視窗的內容,並閱讀 Claude Code 對話計費方式 以了解其運作機制。

Claude Code 中的 /clear 與 /compact 有什麼區別?

/clear 會開啟一個內容為空的全新對話。此操作不會發送任何請求,因此不會產生費用,適合在處理不相關的任務之間使用。/compact 則會保留當前對話,並將歷史紀錄替換為摘要,適合在處理單一長期任務時使用。請為其設定重點(例如 /compact keep only the plan and the diff),因為指令將決定哪些內容會被保留。

如何查看是什麼佔用了我的 Claude Code 上下文視窗?

請執行 /context,或執行 /context all 查看每個項目的完整明細。它會以彩色網格顯示系統提示詞、工具定義、MCP servers、記憶體檔案與歷史紀錄,並針對佔用大量上下文的工具與記憶體膨脹問題提供建議。若使用付費方案,/usage 還能將近期使用量歸類到個別技能、子代理(subagents)與 MCP servers。

我應該使用 100 萬 token 的上下文視窗,而不是進行壓縮嗎?

更大的視窗只是延後問題,而非解決問題。目前有多種模型支援 100 萬 token 的上下文視窗(包含 Opus 4.8 與 Sonnet 5),但壓縮機制在這些模型上的運作方式相同。每一輪對話仍會重新發送並計費完整的提示詞,因此無論 40 萬 token 的對話是否塞得進視窗,其費用依然昂貴。

Claude API 中的上下文編輯(context editing)與壓縮(compaction)有什麼區別?

上下文編輯會選擇性地清除舊內容(主要是工具執行結果),並在移除處留下佔位文字,讓 Claude 知道該內容已被移除。壓縮則會產生摘要並以此替換完整的歷史紀錄。Anthropic 的文件將壓縮視為長期對話的主要策略,並將上下文編輯定位為更精細的選項。兩者皆為測試版功能,擁有各自的標頭,且皆與 Claude Code 的 /compact 不同。