閒置壓縮會不會讓我丟掉重要的上下文？
會有風險。壓縮把細節換成摘要，精確的程式碼片段、錯誤訊息與早期決策可能被簡化。是否會發生、損失多少，取決於摘要的品質，我沒有看到官方量化的數據。
如果某個長任務對細節很敏感，可以調高 CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS 或關閉，並在離開前自己用 /compact 指定要保留的內容。
我用 API key，快取只有五分鐘，閒置壓縮還有用嗎？
不確定。changelog 的描述是在一小時快取到期前壓縮，對五分鐘快取的行為我沒有查到說明。
建議用 /usage 的 Prompt cache 行觀察 miss 次數與快取冷熱，再決定要不要依賴這個功能，必要時自己控制壓縮時機。
門檻 20 萬 token 該調高還是調低？
沒有標準答案。調低會讓更多對話被自動壓縮，省下的重算成本增加，但資訊損失的機會也變多；調高則相反。
比較穩妥的做法是先維持預設，觀察一週內 /usage 顯示的 miss 與重新快取量，再依你的任務對細節的敏感度微調。
閒置壓縮跟自己手動 /compact 有什麼差別？
最大的差別是控制權。手動 /compact 可以寫明要保留什麼，閒置壓縮是在你不在的時候自動發生，沒有機會指定。
如果你要離開的原因是一段重要工作的中途，離開前手動壓縮並寫清楚保留重點，會比依賴自動壓縮更可控。
Claude Code v2.1.299（2026 年 10 月 14 日）在終端機新增閒置壓縮（idle compaction）：一段 20 萬 token 以上的對話，如果閒置約 54 分鐘，會在它一小時的 prompt cache 到期之前先被壓縮，這樣你回來送下一則訊息時，就不用把整段對話重新處理一遍。v2.1.302 又在 /config 加了 Idle compaction 一列，閒置壓縮後的提示也會說明怎麼關掉。
官方成本文件說得很清楚：休息超過快取有效期之後的第一則訊息會 miss 快取，並重新處理你的完整上下文。快取有效期在訂閱方案上是一小時，一旦開始動用 usage credits 就降到五分鐘；用 API key 或雲端供應商時預設是五分鐘。也就是說，午休回來或開完一場會的長對話，第一句話往往最貴。閒置壓縮的做法是趁快取還熱的時候先把對話縮小，等你回來時，要重新處理的只是壓縮後的摘要，而不是 20 萬 token 的原文。
預設最小門檻是 20 萬 token，可以用環境變數 CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS 調整；想完全關掉，在 settings.json 寫 "idleCompaction": false。這兩個設定都需要 v2.1.290 或更新版本。另一個細節是 v2.1.296 起 Sonnet 5.5 的快取讀取價格改為每百萬 token $0.10（原本 $0.20），照這個價格，讀取一段 20 萬 token 的熱快取約 $0.02。壓縮本身也是一次大型請求（官方文件提醒壓縮大型上下文本身就是大請求），所以它划算的前提，是在快取還熱的時候做。
最大的代價是資訊損失：壓縮會把細節換成摘要，如果你的工作依賴對話裡精確的程式碼片段、錯誤訊息或早期的決策脈絡，回來後模型看到的是摘要而不是原文。另外，changelog 把它描述為「在一小時快取到期前」壓縮，我沒有查到在五分鐘快取（API key 或動用 usage credits）的情況下它如何運作，這部分請自行用 /usage 的 Prompt cache 那一行驗證，那一行會顯示快取目前是熱還是冷、有幾次 miss。
如果你習慣讓長對話整夜或整個午休開著，閒置壓縮可能替你省下回來那一則訊息的重算成本，但前提是你的快取有效期是一小時。先用 /usage 看自己的 miss 次數與重新快取的 token 量，再決定要不要把門檻調高、或對重要的長任務直接關掉並改成自己手動 /compact 並寫明要保留什麼。真正省錢的習慣仍然是不相關的任務之間用 /clear，那一步不花任何成本。