Claude Code 成本實測：/compact 指令快取溫熱時僅 $0.06，冷卻後費用暴增九倍，/clear 則零成本

在 Claude Code 2.1.289 搭配 Opus 5.5 的環境下，對一個 136k 權杖的工作階段執行 /compact 指令，其 138,344 個輸入權杖中有 136,275 個來自提示詞快取，定價成本約為 $0.056 至 $0.059 美元，相當於兩次一般對話回合的費用。

然而，若在快取過期後執行相同的壓縮，成本則高達 $0.53 至 $0.54 美元。若在讀取檔案的回合後立即執行 /compact，則需為這些檔案支付全額費用，例如 85k 權杖時約為 $0.30 至 $0.32 美元。

在 13 次測試中，/clear 指令均未發送任何 API 請求。執行 /clear 後的第一個請求為 15,303 個權杖，而溫熱快取壓縮後則為 14,254 至 14,923 個權杖。Claude Code 文件中的成本頁面列出了長時間工作階段使用量增加的原因，其中最後一項便是關於壓縮。

文件指出，/compact 會「讀取其摘要的對話內容，因此壓縮大型語境本身就是一個大型請求」，並補充道：「當您想要重新開始而非延續時，/clear 不會產生任何費用」。這兩句話都屬實，但都沒有提供具體數字。這個請求究竟有多大？是權杖多、費用高，還是兩者皆是？壓縮後的回合成本是多少？與清除後並提供簡短筆記給下一個工作階段相比又如何？我們對此進行了測量。

實驗室透過讓 Claude 讀取真實的 JavaScript 檔案，建立了三種不同大小的工作階段，然後對其進行壓縮或清除。我們從 Claude Code 可寫入磁碟的請求和回應主體中，讀取了每個 API 請求的使用量。在世界標準時間 2026 年 10 月 5 日，共執行了 38 個 claude -p 程序，使用 Claude Code 2.1.289 版本，並指定 --model opus，該模型解析為 claude-opus-5-5。

在先前的文章中，我們測量了哪些指令能在壓縮後保留下來。而本文則專注於壓縮的成本。

文件內容：在實驗當天世界標準時間 16:20 取得的成本頁面，多次提及壓縮功能。在「減少權杖使用量」的章節中提到：「Claude Code 透過提示詞快取自動優化成本，這能減少重複內容（如系統提示詞）的費用，並透過自動壓縮功能，在接近語境限制時摘要對話歷史紀錄。」

在非使用量限制的訊息列表中，它將自動壓縮視窗稱為「Claude Code 摘要舊歷史紀錄以釋放空間的閾值」。而在使用量增加的原因列表中，則引用了上述兩句話。關於 /clear，文件也指出工作階段成本會重置：「當 /clear 啟動新工作階段時，這些總計會重置，因此下一個工作階段的總成本將從 $0 開始。」

成本頁面將「壓縮大型語境」這句話連結到提示詞快取頁面，該頁面詳細描述了請求過程：為了產生摘要，Claude Code 會發送一個單獨的請求，其中包含與您的對話相同的系統提示詞、工具和歷史紀錄，並在最後附加一條摘要指令作為使用者訊息。當快取處於溫熱狀態時，該請求會從快取中讀取您的前綴內容，因此工作階段中期的 /compact 成本僅為語境大小所暗示的一小部分，且大部分時間用於生成摘要。

下一段則涵蓋了冷卻快取的情況：「在超過快取生命週期的間隔後，沒有快取可供讀取，因此摘要請求會將完整的歷史紀錄重新處理為未快取輸入。這就是為什麼在恢復舊工作階段時，/compact 成本最高的原因。」它總結道：「無論是溫熱還是冷卻情況，壓縮之後的回合僅針對較短的摘要重建對話快取，因此該回合並非緩慢的部分。」

同一頁面將壓縮歸類為快取生命週期的「其他」類別，預設為五分鐘，除了少數由伺服器控制的輔助請求。它還列出了 FORCE_PROMPT_CACHING_5M=1，「這會強制兩個類別都設定為五分鐘」，用於偵錯快取行為。我們在冷卻快取測試中使用了這個變數。

成本頁面沒有說明自動壓縮何時運行的設定；它連結到模型配置頁面，其中列出了四個設定自動壓縮視窗的位置：/autocompact 指令、autoCompactWindow 設定、單次啟動的 --autocompact 旗標，以及 CLAUDE_CODE_AUTO_COMPACT_WINDOW 環境變數，後者「優先於指令、旗標和設定」。

如果沒有設定，我們模型的預設值是：「運行原生 1M 視窗的模型會在視窗填滿之前進行壓縮，預設約在 967K 權杖時。在 Anthropic API 上，這包括 Sonnet 5、Fable 模型以及 Opus 4.7 及更高版本。」

還有兩個環境變數與此相關。CLAUDE_AUTOCOMPACT_PCT_OVERRIDE 設定了「自動壓縮觸發時，自動壓縮視窗的百分比（1-100）」，並且「該變數不能提高閾值」。DISABLE_AUTO_COMPACT 則關閉自動壓縮功能，但「手動的 /compact 指令仍然可用」。

還有一個聲明對下一個回合很重要。語境視窗頁面指出，壓縮後，Claude Code 會「重新讀取工作階段中 Claude 已讀取或編輯的最多五個檔案，選擇最近修改的檔案。超過 5,000 權杖的檔案會以路徑參考的形式返回，不包含其內容」。

實驗室：實驗內容是真實的程式碼，即從開源套件（如 Jest 的轉換建構、Babel 的範圍追蹤器、argparse、browserslist、Handlebars 編譯器、minimatch、picomatch）複製的 31 至 41 KB JavaScript 檔案。

每個工作階段都以一條訊息開始，要求 Claude 使用 Read 工具讀取這些檔案，所有檔案都在一條訊息中，然後用十個詞描述每個檔案。

一個檔案、四個檔案和七個檔案分別產生了三種大小的工作階段。在壓縮前最後一個請求的完整輸入測量中，工作階段分別包含 34,176 至 34,185 個權杖、84,639 至 84,666 個權杖，以及 136,344 至 136,364 個權杖。其中，約 19k、69k 和 120k 權杖是檔案內容，約 15k 權杖是任何工作階段的起始內容：系統提示詞、工具定義和開場提醒。

第一個訊息之後的每個訊息都是以下之一：探測問題，一個需要先前語境的廉價問題：「不使用任何工具，在一行中回答：您在本次對話中讀取過的檔案名稱，以逗號分隔，如果無法判斷則回答 NONE。」或者 /compact 或 /clear，在交接運行中作為純提示詞字串發送，「為新工作階段寫一份交接筆記到 HANDOFF-.md... 最多 150 個字」，以及在 /clear 之後，「使用 Read 工具讀取 HANDOFF-.md，然後在一行中回答」檔案名稱。

主要的測試模式包括：建構、探測、/compact、探測（壓縮）；建構、探測、/clear、探測（清除）；以及建構、探測、寫筆記、/clear、讀筆記（交接）。每種大小都運行兩次，共十八次。指令前的探測問題有兩個原因：它測量了該大小下普通回合的成本，並使工作階段以簡短的交流結束，就像工作階段通常在自然中斷時那樣。

作為對照組，有兩個全新工作階段僅發送了探測問題。接著是各種變體，每個運行兩次：在 85k 和 136k 權杖時，於冷卻快取後進行壓縮（使用 FORCE_PROMPT_CACHING_5M=1 並在 /compact 前靜默 6.5 分鐘）；在 136k 權杖時，於相同靜默後不壓縮而發送探測問題；在 85k 權杖時，於建構回合後立即發送 /compact，中間沒有探測問題；在 85k 權杖時，使用 --autocompact 100000 進行自動壓縮；以及從 24 個 1.4 至 9.1 KB（約 90k 權杖）的小檔案重建的四檔案工作階段，以觀察小於 5,000 權杖檔案的重新讀取情況。

每個工作階段都在一個 claude -p 程序中運行，並使用 --input-format stream-json。一個小型 Node 腳本寫入一條使用者訊息，等待結果事件，然後寫入下一條。這正是 Agent SDK 文件中描述手動壓縮的方式：「將 /compact 作為提示詞字串發送，以按需觸發壓縮。」

使用的旗標包括 --model opus --setting-sources project,local --strict-mcp-config，搭配空的 MCP 配置，以及 --allowedTools Read Write，且自動記憶體功能已關閉。一個包裝器移除了從啟動運行的 Claude Code 工作階段繼承的環境變數，包括任何自動壓縮設定。

這些數據來自請求主體。透過設定 CLAUDE_CODE_ENABLE_TELEMETRY=1 和 OTEL_LOG_RAW_API_BODIES=file:<dir>，Claude Code 會將每個請求和回應寫入磁碟，並在 <dir>/index.jsonl 中為每個請求附加一行，其中包含 query_source 欄位。

摘要請求被標記為 compact；這些運行中的主要對話則被標記為 sdk。

每個回應都帶有 API 的使用量區塊：未快取輸入權杖 (uncached input_tokens)、快取讀取輸入權杖 (cache_read_input_tokens)、分為五分鐘和一小時寫入的快取建立輸入權杖 (cache_creation_input_tokens)，以及輸出權杖 (output_tokens)。

另外兩項紀錄與主體一致。每個 --debug-file 日誌都有一行關於壓縮的紀錄，例如 Forked agent [reactive-compact] finished: 1 messages, types=[assistant], totalUsage: input=2069 output=1168 cacheRead=136275 cacheCreate=0，這與 19 次壓縮中的 19 次回應主體相符。

/compact 步驟中 total_cost_usd 的變化與主體使用量按照 Opus 5.5 定價計算的結果相符：每百萬輸入權杖 $4 美元，五分鐘和一小時快取寫入分別為 $5 和 $8 美元，快取讀取 $0.20 美元，輸出 $20 美元（定價頁面於世界標準時間 16:36 取得）。

工作階段對話紀錄是唯一沒有這些數據的地方：它包含摘要和帶有 preTokens 和 postTokens 的 compact_boundary 紀錄，但沒有摘要請求的使用量紀錄，其權杖僅出現在結束的成本狀態紀錄中的工作階段總計內。

以下每個美元數字都是該定價估算值，與 Claude Code 顯示的相同。主要對話的快取寫入是一小時寫入，提示詞快取頁面指出這是 Claude 訂閱的預設值。溫熱快取壓縮請求的數據如下表所示：當語境大小為 34.2k 權杖時，普通回合成本約 $0.0078，壓縮成本約 $0.037 至 $0.044，是普通回合的 4.7 到 5.7 倍。

在 84.7k 權杖時，普通回合成本約 $0.019，壓縮成本約 $0.045 至 $0.046，是普通回合的 2.3 到 2.4 倍。而當語境達到 136.4k 權杖時，普通回合成本約 $0.031，壓縮成本約 $0.056 至 $0.059，約為普通回合的 1.8 到 1.9 倍。

這顯示文件中的描述，即請求在權杖方面很大，但在快取溫熱時費用不高，是完全符合的。

該請求在權杖方面確實很大：它攜帶了整個對話內容，除了最後的簡短回覆，還加上了大約 2,000 個權杖，是其摘要語境的 1.01 到 1.06 倍。然而，當快取溫熱時，其費用並不高，因為除了 2,069 個權杖外，其餘都是快取讀取。這 2,069 個權杖包括探測問題、摘要指令和一行權杖預算提醒。在每次運行中，該指令都是相同的 6,361 個字元。

該指令以「CRITICAL: Respond with TEXT ONLY. Do NOT call any tools.」開頭，並要求提供一個包含九個部分的區塊，從「主要請求與意圖」到「可選的下一步」。它作為最後一個使用者訊息中的第二個文字區塊發送，並帶有與對話相同的十三個工具定義和系統提示詞。

在 136k 權杖時，一次壓縮的 $0.0589 美元費用分為 $0.027 的快取讀取、$0.023 的摘要輸出和 $0.008 的 2,069 個新權杖。

如果以未快取輸入計價，相同的語境處理一次將花費 $0.545 美元，因此溫熱快取壓縮的成本僅為其 10% 到 11%。在 34k 權杖時，這個比例為 27% 到 32%，因為指令和摘要不會隨工作階段縮小。這就是文件所說的「語境大小所暗示的一小部分」，經測量：在 136k 時約為十分之一，在 34k 時約為三分之一。

摘要內容幾乎沒有隨工作階段增長。Claude Code 記錄了在 34k 到 136k 權杖壓縮後，postTokens 為 1,549 到 1,977，摘要長度為 3,183 到 3,676 個字元。所有六次測試都列出了所有已讀取的檔案，壓縮後的探測問題在 6 次運行中都回答了完整的列表。壓縮本身耗時 9.3 到 12.7 秒。

冷卻快取壓縮請求：冷卻快取運行重複了壓縮模式，所有快取寫入設定為五分鐘，並在 /compact 前靜默 6.5 分鐘。數據顯示：當語境大小為 84.8k 權杖時，溫熱快取壓縮成本約 $0.045 至 $0.046，而冷卻快取壓縮成本約 $0.326 至 $0.333，是溫熱快取的 7.0 到 7.4 倍。

在 136.5k 權杖時，溫熱快取壓縮成本約 $0.056 至 $0.059，而冷卻快取壓縮成本約 $0.529 至 $0.542，是溫熱快取的 9.0 到 9.8 倍。文件中的描述在此也得到了驗證。