我用的是 API key，這個功能會幫我省到錢嗎？
多半不會觸發。API key 預設的 prompt cache 壽命是五分鐘，而閒置壓縮需要一小時 TTL 才會啟動計時器。要啟用得自己設 "promptCacheTtl": "1h"，但一小時快取的寫入是基本輸入價的 2 倍，五分鐘是 1.25 倍，短時間的使用反而可能虧。所以不要預設它在幫你省錢，先用 claude -p "Reply with the single word: ok" --output-format json 看寫入落在哪一種 TTL。
我常把長 session 放著去吃飯，要不要關掉？
看工作的性質。以檔案為主的工作（寫程式、維護），摘要加上重新讀取的檔案通常帶得走大部分重點，開著問題不大；如果工作本身活在對話裡（設計討論、確切的指示、依賴檔案留在 context 裡的 orchestrator 流程），建議關掉或調高門檻。這是 nardit 的看法，不是實測。另一個保險做法是把必須保留的內容放進專案根目錄的 CLAUDE.md、沒有路徑限制的規則，或針對 compact 的 SessionStart hook，因為只在對話中說過的決定，摘要時會被改寫。
怎麼確認它真的有跑，而不是我多想了？
回到 session 時看有沒有「Compacted while idle, before the prompt cache expired」的通知；/usage 的「Prompt cache (main)」一行會顯示命中率、未命中次數與快取是否還暖，以及上次未命中的可能原因。有開 OpenTelemetry 的話，看 claude_code.api_request 事件裡 query_source 為 compact、cache_read_tokens 很大的那一筆。如果回來第一則訊息出現很大的一小時快取寫入，可能代表錯過了時間窗，但換模型或前綴改變也會留下一樣的特徵，要先排除。
我不是工程師，只負責看團隊的 AI 工具費用，這件事該注意什麼？
先問團隊用的是訂閱方案還是 API key。訂閱方案下，這個功能省的是額度，不是金額，而且 Anthropic 沒公布額度怎麼計算快取讀寫，所以很難用美元估算。API key 預設的快取壽命是五分鐘，功能多半不會啟動，不要把它列進預期的節省。另外它是預設開啟的行為變更，如果有人抱怨 AI 「忘了之前交代的細節」，這是可以先檢查的原因之一。
2026 年 10 月 14 日發布的 Claude Code v2.1.299 在更新說明裡加了一項新行為：在終端機中，超過 200K tokens 的對話如果閒置約 54 分鐘，會在一小時的 prompt cache 過期前自動壓縮，讓你回來後的第一句話不必重新處理整段對話。10 月 16 日的 v2.1.302 又在 /config 加了「Idle compaction」開關，並讓壓縮後顯示的通知說明如何關閉。這是一個預設開啟、直接影響帳單與context內容的變更。
目的是搶在prompt cache過期之前壓縮：這時摘要請求讀到的是還在快取裡的前綴，用的是便宜的 cache 讀取價，而不是冷啟動時的整段重寫。至於 54 這個數字，Developers Digest 引述 GitHub issue 裡一位留言者的二進位分析：計時器只在快取壽命為一小時時才會啟動，並在壽命走到約 90% 時觸發，60 分鐘的 90% 就是 54 分鐘。這是社群回報，不是官方說明，該文作者也沒有逐一驗證各種方案的快取行為。
max.nardit.com 的整理（引用設定參考與 prompt caching 文件）列出它真正會觸發的條件：
claude -p 與 Agent SDK 不會觸發。"promptCacheTtl": "1h"。一小時快取的寫入計價是基本輸入價的 2 倍，五分鐘是 1.25 倍，文件提醒短時間的使用反而可能虧。DISABLE_GROWTHBOOK=1 或 CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC 會關掉它。CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS 調整；低於 100,000 的值會被提高到 100,000。官方定價是 cache 讀取為基本輸入價的 0.1 倍（Opus 5.5 與 Sonnet 5.5 為 0.05 倍），五分鐘寫入 1.25 倍，一小時寫入 2 倍。nardit 的估算（作者推算，不是文件）是：200K tokens 的對話在 Opus 5.5 上，閒置壓縮的讀取約為 10K 個基本輸入單位，冷啟動回來要重寫約 400K 單位，光前綴就差約 40 倍。但真正省下的比這小，因為還要付摘要的輸出 tokens，以及重建 context（摘要、指示、還原的檔案與 skill）的成本。
Developers Digest 轉述 GitHub issue 的一位使用者資料：約 740K tokens 的 session 在 API key 上，冷啟動喚醒一次約 $9.25，暖快取壓縮約 $0.19；142 次壓縮後的內容約為原本的 20%。這是單一使用者的量測，不是基準測試。在訂閱制上，省的是額度而不是美元，而 Anthropic 沒有公布額度如何衡量 cache 讀取與寫入。
依 nardit 整理的文件內容，摘要會保留：請求與意圖、關鍵技術概念、檢視或修改過的檔案（含重要片段）、錯誤與修正、待辦事項與目前進度。完整的工具輸出與中間推理會從工作 context 移除，但磁碟上的 session 記錄還在。壓縮後會重新載入：專案根目錄的 CLAUDE.md、沒有路徑限制的規則與 auto memory、最多五個最近修改的檔案（超過 5,000 tokens 的只回傳路徑）、呼叫過的 skill 內容（每個上限 5,000 tokens，總共 25,000，最舊的先丟），以及符合 compact 來源的 SessionStart hook 輸出。帶 paths: frontmatter 的規則和巢狀 CLAUDE.md 則不會自動重載，要等 Claude 再碰到相符的檔案。背景指令在壓縮期間繼續執行。
社群的抱怨集中在「靜默丟失細節」：一份 bug 回報說摘要取代了確切的指示、決策理由與進行中的狀態，沒有任何警告；另一位跑 orchestrator 流程的人說檔案沒有被重新讀取，導致流程出錯。
"idleCompaction": false 只關閉閒置壓縮，可以放在任何 settings 檔，包括專案的 .claude/settings.local.json；v2.1.302 起也能在 /config 切換。DISABLE_AUTO_COMPACT=1 會連一般的自動壓縮一起關掉，只剩手動 /compact。CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS 可以讓功能只在更大的 session 發生。/usage 的「Prompt cache (main)」一行可看命中率；開 OpenTelemetry 的話，找 query_source 為 compact 的 api_request 事件。文件沒說執行中的背景指令或待觸發的排程喚醒，會不會推遲閒置計時器；也沒說 claude --resume 在閒置壓縮後的行為。更新說明寫兩個設定都需要 v2.1.290 以上，但功能是在 v2.1.299 才出現，nardit 建議把 2.1.299 當成最低版本。另外 Developers Digest 提到，有 GitHub issue 把這個行為放在 2.1.286 當成靜默預設，這解釋了為什麼有些人早就遇過，但屬於回報，未經驗證。