Claude Code 長任務裡，Prompt Cache 命中率會直接影響成本和速度。很多人只知道「快取能省 Token」，但不清楚哪些操作會讓快取突然失效。
理解它並不難：每次請求都可以看成一條從左到右的上下文鏈條：
|
|
越靠左的內容越穩定，快取收益越大；越靠左的內容一變，後面的快取也更容易跟著失效。反過來，越靠右的內容變化，影響範圍越小。
所以優化 Claude Code 的 Prompt Cache，不是靠玄學，而是靠一個原則：任務開始前把模型、MCP、Skills、CLAUDE.md 等基礎上下文準備好，任務中途盡量不要改。
Prompt Cache 快取的不是文字本身
Prompt Cache 不是簡單地把提示詞字串存起來。對 Transformer 模型來說，更關鍵的是前綴上下文經過注意力層計算後的 Key/Value 狀態，也就是常說的 KV cache。
這意味著兩個事實：
- 同一段上下文，只要前綴保持穩定，就可以在後續請求中複用一部分計算結果。
- 如果模型、工具定義、系統提示詞或前綴訊息發生變化，之前的快取就可能無法複用。
Anthropic 官方文件也把失效層級概括為 tools -> system -> messages。工具定義變化會影響整段快取，系統層變化會影響 system 和 messages，messages 層變化則主要影響訊息快取。
Claude Code 裡還會額外涉及 CLAUDE.md、Skills、MCP、外掛和子代理等上下文，所以實際使用時更容易踩到快取失效點。
快取殺手一：中途切換模型
切模型是影響最大的操作。
Prompt Cache 是按模型隔離的。Opus、Sonnet、Haiku 這類模型的結構和權重不同，同一段文字算出來的 KV cache 也不同。你在 Opus 裡跑了很長上下文，再切到 Sonnet，並不能讓 Sonnet 複用 Opus 的快取。
這會帶來一個反直覺結果：中途為了省錢切模型，可能反而讓前面已經累積的快取全部失效。原本可以按 cache read 價格讀取的上下文，需要重新寫入和計算。
更穩妥的做法是：
- 主對話盡量固定一個模型。
- 需要便宜模型處理支線任務時，用 subagent 隔離出去。
- 讓支線代理完成搜尋、探索、整理，再把結果摘要交回主對話。
這樣主對話的長上下文盡量不動，快取命中率更穩定。
快取殺手二：中途新增 MCP 或重載外掛
MCP 會向 Claude Code 提供工具。新增 MCP 伺服器後，工具列表會變化，而工具定義處在上下文鏈條最左側。
從 Prompt Cache 的角度看，工具列表一變，後面的 system 和 messages 都可能需要重新計算。尤其是 MCP 很多時，工具定義本身就可能占用大量 Token，快取失效的代價會很明顯。
不過有一個細節：Claude Code 通常在會話啟動時讀取 MCP 配置。你中途改了配置，當前 session 不一定立刻受影響。真正需要小心的是觸發重新載入的動作，例如重啟、恢復會話、重新載入外掛或讓工具列表重新組裝。
建議是：
- 開始長任務前，一次性裝好需要的 MCP。
- 不要做一半才發現缺工具，再安裝並重載。
- 對大型 MCP 工具集，優先考慮按需載入或減少預設啟用數量。
- 不常用的 MCP 不要長期掛在預設配置裡。
如果工具定義穩定，Prompt Cache 才有長期命中的基礎。
快取殺手三：中途修改 CLAUDE.md
CLAUDE.md 是 Claude Code 的專案記憶文件，適合放構建命令、測試命令、架構約定、程式碼風格和專案注意事項。
它對 Claude Code 很有用，但也會進入上下文。官方說明指出，CLAUDE.md 會在 session 開始時讀取，並作為使用者訊息提供給 Claude；它也會使用 Anthropic 的 Prompt Cache。首次請求會按完整輸入計費，後續請求如果在快取有效期內命中，就按更低的 cache read 成本處理。
問題在於：CLAUDE.md 是內容定址的。你一改文件內容，舊快取就對不上了。
所以不要在長任務中途頻繁改 CLAUDE.md。更好的方式是：
- 任務開始前先檢查
CLAUDE.md是否夠用。 - 把穩定規則寫進去，把臨時指令放在目前對話裡。
- 如果只是一次性任務，不要為了臨時需求修改長期記憶文件。
- 如果必須改，最好在一個階段結束後再開始新 session。
CLAUDE.md 應該是穩定的專案說明，而不是每輪任務都改的便條。
快取殺手四：中途安裝或更新 Skills
Skills 也是上下文的一部分。安裝新 Skill、更新 Skill，或者讓 Skill 列表發生變化，都會讓注入到會話裡的上下文不同。
這類變化通常不會在目前 session 裡立刻完整生效，而是在重新載入、恢復會話或新開會話時體現出來。問題是，一旦重新組裝 messages，舊快取就可能命中不了。
建議和 MCP 類似：
- 開始任務前先確認需要哪些 Skills。
- 同一類任務盡量固定 Skill 集合。
- 不要在一個長任務中途邊做邊裝 Skill。
- 如果安裝了新 Skill，最好把它當成新階段的開始。
對經常做內容生產、程式碼審查、部署、翻譯的工作流，可以把常用 Skills 固定下來，讓上下文結構盡量穩定。
快取殺手五：空閒時間超過 TTL
Prompt Cache 不是永久保存。常見預設有效期是幾分鐘級別，Anthropic 文件和 Claude Code 相關說明裡都提到過 5 分鐘左右的快取窗口。超過 TTL 後，即使你發送完全一樣的請求，服務端也可能已經清掉快取。
這也是很多長任務使用者的體感來源：剛才還很省，去喝杯咖啡回來，再發下一步，Token 又突然漲上去了。
長任務尤其容易遇到這個問題。你可能要看 Claude Code 的輸出、檢查文件、跑測試、思考下一步，這些操作一不小心就超過 5 分鐘。
如果你的使用環境支援，可以在長任務前啟用 1 小時 Prompt Cache TTL：
|
|
在 Windows PowerShell 裡可以寫成：
|
|
需要注意的是，1 小時快取寫入成本通常會高於 5 分鐘快取寫入成本。它不適合所有短任務，但對大型程式碼庫、長對話、複雜多步驟開發任務，往往比頻繁快取過期更划算。
怎麼安排一次更省 Token 的 Claude Code 長任務
比較穩的流程可以這樣做：
- 任務開始前選定模型，不要中途頻繁切換。
- 提前啟用需要的 MCP，不用的 MCP 先關掉。
- 檢查
CLAUDE.md，只保留穩定、關鍵、長期有效的規則。 - 提前準備好本次任務需要的 Skills。
- 如果是複雜任務，考慮啟用 1 小時 TTL。
- 把大任務拆成幾個階段，但每個階段內部盡量保持上下文結構穩定。
- 需要探索支線問題時，用 subagent 或單獨 session，不要污染主對話。
這套做法的目標不是絕對不讓快取失效，而是避免那些代價最高、最容易被忽略的失效。
一個簡單判斷標準
你可以用一句話判斷某個操作是否危險：
這個操作會不會改變模型、工具定義、系統上下文或會話開頭的固定訊息？
如果答案是會，那它大概率會影響 Prompt Cache。越靠近上下文鏈條左側，影響越大。
常見操作可以這樣理解：
- 切模型：高風險，模型快取隔離。
- 新增 MCP 或重載外掛：高風險，工具列表變化。
- 修改
CLAUDE.md：中高風險，專案記憶變化。 - 安裝 Skills：中高風險，注入上下文變化。
- 普通對話繼續追問：低風險，主要追加 messages。
- 空閒超過 TTL：高風險，服務端快取過期。
小結
Claude Code 的 Prompt Cache 優化，關鍵不是背參數，而是讓會話前綴穩定。
模型不要隨便切，MCP 和 Skills 不要邊做邊裝，CLAUDE.md 不要當臨時草稿頻繁改，複雜任務盡量延長 TTL。只要這些基礎動作穩定下來，Claude Code 在長任務裡的 Token 成本和回應速度都會更可控。
最實用的一句話是：開始前配好，開始後少動。