昨天 Claude Code 發了 v2.1.299。更新說明裡有一條：終端機裡超過約 20 萬 token 的對話，閒置大約 54 分鐘後，會在一小時的 prompt cache 過期前先做壓縮，讓你下一則訊息不必把整段歷史當未快取輸入重算。設定鍵是 idleCompaction，要關就在 settings.json 寫 "idleCompaction": false；門檻可用環境變數 CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS 改。兩者都要 v2.1.290 或更新。

這條我讀完，第一個想到的是 harness 開始在時間軸上動手：你人走開、對話還掛著，它搶在快取涼掉之前，先把長對話壓成摘要。

貴的通常不是壓縮本身

官方 prompt caching 文件寫得很直：壓縮會讓對話層的快取失效，下一個請求要面對一段新的、比較短的歷史。產生摘要時，如果快取還熱，系統可以便宜地讀既有的前段，再花時間生摘要；如果你休息超過快取壽命才回來壓縮，摘要請求要把整段歷史當未快取輸入重算。文件自己的結論是：回來才壓縮，最貴。

Idle compaction 針對的就是這個時段。訂閱方案還在方案額度內時，主對話預設常要一小時 TTL；一旦用到 usage credits、API key 或雲端供應商，主對話預設是五分鐘。文件也寫明：若在一小時 TTL 內把長對話閒置在終端機，Claude Code 可以在快取過期前先壓縮。一小時那條線，剛好卡在你去吃飯、開會、回訊息的長度附近。54 分鐘這個數字，看起來就是刻意留在 TTL 結束前。

壓縮之後，下一則請求要重建的是比較短的摘要快取，文件說那一拍通常不是最慢的部分。真正貴的是摘要請求本身碰上冷掉的前段。我還沒開過這版去量下一輪實際差多少。數字不寫，是因為我沒量過。官方把機制講清楚了，帳單上的差額要自己測才算數。

動的是離開之後那一段成本曲線

我對用量變敏感，是付過學費之後。雲端 agent 那一輪只顧主 session 不要爆，工作全派給子代理，結果一輪花了大約 90 美元（〈我只管主 session 不要爆掉，雲端 agent 那一輪花了 90 美元〉）。後來 Projects 把平行雲端對話串放進來，我也寫過自己對這類帳比較小心（〈Claude Code Projects 把等候名單全放進來了，平行雲端 thread 我早就付過學費〉）。

那些經驗讓我看更新說明時，會先問：這次改的是哪一段成本曲線。Idle compaction 動的是「你離開很久之後，回來得付哪一種輸入價」。我自己的畫面很常見：終端機裡一場偵錯或重構已經超過 20 萬 token，人去倒水、回訊息，session 還掛著。快取一過期，回來打的第一個字，整段歷史就當未快取輸入重算。它選在過期前壓短，等於把昂貴的那一下，從你回來的那一拍，挪到快取還熱的時候先做完。

這跟叫模型「省著用」不是同一件事。模型還是照樣讀、照樣回；變的是 harness 什麼時候替你把歷史壓短。這是產品自動做的時間軸行為，我也沒在設定檔裡親手寫這條規則。要關可以關，門檻也可以調。我目前不會急著關，但我也不會假裝自己已經用帳單證明它省了多少。

我在意的是誰決定時機

自動壓縮本來就有：上下文撐不住時會觸發。Idle compaction 不一樣的地方，是觸發條件換成「人離開多久」加上「快取還剩多久」。決策主體還是 harness，只是它開始盯鐘。文件也說，壓縮主要換掉的是對話層；系統提示詞那一層通常還在，專案上下文則依 CLAUDE.md 有沒有變而定。它動刀的位置很明確，時機卻改成跟人不在場綁在一起。

對我這種常把長對話掛著、人去忙別的事情的人來說，這比再多一個「請記得手動 /compact」的提醒實用。提醒要我在場；這個功能假設我不在場。人一離開，終端機還亮著，快取的倒數卻沒停。以前那一小時過完，回來第一則訊息最痛；現在產品選在倒數結束前先動手。

我還沒試過，也不打算為了它特地去測。哪天長對話掛著、我剛好走開一陣子，回來自然就會碰到。在那之前，這篇只記機制：它搶在快取過期前動手，避開的是回來時的冷啟動重算。