1. 先釐清：大家口中的「Token 快取」其實有四種
第一種是模型推論期間的 KV Cache，保存 Transformer attention 已算出的 Key／Value 張量，避免生成下一個 token 時重算先前所有 token。第二種是本文主角 Prompt Cache／Prefix Cache：服務商把一段相同提示前綴的 prefill 中間狀態保留，供後續 API 請求重用。第三種是 conversation state，例如 Responses API 的 previous_response_id；它能讓客戶端少搬運或由服務端串接狀態，但不等於保證計費上的 prompt cache hit。第四種是 compaction／摘要，把歷史改寫成較短的新上下文，降低未來輸入量，但會建立一條新的前綴。另有本機 auth.json 等登入憑證快取，和模型 token 成本完全無關。
2. KV Cache 與 Prefix Cache 到底省了哪一段運算
自回歸模型每產生一個新 token，都要讓新 token 對先前 token 做 attention。KV Cache 將過去 token 的 Key／Value 留在記憶體，只計算新增 token 的狀態。Prompt／Prefix Cache 則把這個概念跨 API 請求延伸：若下一個請求開頭與先前完全相同，服務端可以直接取回已完成的 prefill 狀態，從差異處繼續運算。PagedAttention 等研究進一步改善 KV 記憶體配置與共享效率。這也是為什麼快取通常同時降低輸入成本與 time-to-first-token，但不會免除新輸入、模型輸出、工具執行或網路延遲。
3. 命中的本質：不是語意相似，而是相同前綴
Prompt Cache 一般不是向量資料庫，也不會因兩段文字意思相近就命中。模型、工具定義、system instructions、圖片內容與 detail 參數、訊息順序、JSON schema，甚至某些推理或 effort 設定，都可能參與快取鍵或改變 token 序列。只要前綴中途有一處不同，該位置之後的內容就必須重算；仍可能命中更短的共同前綴。最可靠的心智模型是：把請求視為一條從左到右的 token 序列，服務端尋找已存在的最長共同開頭。
4. 成本公式：快取不是免費，但通常第二次或第三次就回本
設穩定前綴為 S tokens、重複 N 次、一般輸入單價為 P、寫入倍率為 w、讀取倍率為 r。未快取成本是 N×S×P；有快取成本約為［w＋(N−1)×r］×S×P。OpenAI GPT-5.6 與 Anthropic 5 分鐘快取皆可用 w=1.25、r=0.1 估算，因此同一前綴使用兩次通常已比完全不快取便宜；Anthropic 1 小時寫入為 2 倍，通常第三次開始淨省。以 10 萬個穩定 tokens 重複 10 次為例，1.25 倍寫入加 0.1 倍讀取只相當於 21.5 萬個一般輸入 token 成本，比原本 100 萬降低 78.5%。這只計算穩定前綴，動態尾端與輸出仍照常收費。
5. 提高命中率的第一原則：Static First，Dynamic Last
將最穩定、最長、最常重複的內容放在前面：system prompt、角色規則、安全政策、工具定義、輸出 schema、few-shot examples、程式庫文件與大型參考資料。把每次都會變動的內容放在最後：時間戳、request ID、使用者問題、臨時檢索結果、當次 git diff、隨機 nonce。不要在前綴中插入「目前時間」或每次重新排序工具 JSON；也不要讓格式化程式產生不穩定的空白、欄位順序或版本標記。對應同一 canonical prefix 的請求，應使用固定序列化與固定版本號。
6. 第二原則：設計穩定的 Cache Key，而不是一個 Key 打天下
OpenAI 建議相同長前綴持續使用相同 prompt_cache_key；GPT-5.6 之後要取得更可靠的匹配必須設定它。Key 適合對應 tenant、workflow 與 prompt-version，例如 tenant:acme:code-review:v3，而不是每個 request 都生成新 UUID。OpenAI 目前建議每個 key 的總流量約 15 RPM，超過時應用穩定映射分片，避免熱門 key 因路由壓力而 miss。Cache key 是路由與重用提示，不是權限或資料隔離機制；多租戶安全仍須依組織、workspace、憑證與資料治理設計。
7. 第三原則：把 TTL、並行與預熱納入工作流
快取只有在有效期限內才有價值。若工作負載是密集互動，短 TTL 足夠；若使用者常隔 10 至 40 分鐘才回覆，較長 TTL 才能避免每次冷啟動。Anthropic 明確提醒：新的 cache entry 要等第一個回應開始後才可供其他並行請求讀取，因此大量 fan-out 前應先完成一次預熱；目前也支援 max_tokens:0 的預熱請求。預熱不是免費，它仍會產生 cache write，應只用在已知即將有多次重用、且首包延遲重要的工作。
8. OpenAI API：自動快取、GPT-5.6 Breakpoint 與 30 分鐘 TTL
OpenAI 預設對至少 1,024 tokens 的 prompt 啟用自動快取，並回報 cached_tokens；GPT-5.6 起另外回報 cache_write_tokens，寫入按一般輸入的 1.25 倍計價。GPT-5.6 的 prompt_cache_options.ttl 目前只有 30m，代表至少可重用 30 分鐘，服務端可能保留更久。Responses API 可在文字、圖片與檔案 block 放 explicit breakpoint，也可沿用 implicit 模式；每個請求最多建立 4 個新寫入，讀取時會考慮最近 50 個 breakpoint 並採最長匹配。GPT-5.6 之前的模型通常在閒置 5 至 10 分鐘後淘汰、離峰最長可能約 1 小時，部分模型另有 extended retention。
9. OpenAI 的重要限制：快取 token 仍計入 TPM
OpenAI 官方明確表示 prompt caching 不改變 rate limits，因此 cached tokens 仍計入 tokens-per-minute。換言之，它可以顯著降低輸入費用與延遲，卻不能被當成突破 TPM 上限的方法。監控時至少同時記錄 cached_tokens、cache_write_tokens、總 input tokens、TTFT 與每個 prompt_cache_key 的流量；若 cache_write_tokens 長期很高、cached_tokens 很低，通常代表前綴持續變動、TTL 已過、key 分流不穩定或最小長度不足。
10. Anthropic API：自動 cache_control、4 個斷點與 20-block Lookback
Anthropic 可在 request 頂層加入 cache_control，讓快取點隨多輪對話向前移，也可在 individual block 放 explicit breakpoint。其前綴順序固定為 tools、system、messages。最多使用 4 個 breakpoint；每個 breakpoint 讀取時最多向前檢查 20 個 block，因此若一個 turn 新增超過 20 個細碎 block，舊 entry 可能不在 lookback 範圍內。對具有動態尾端的 prompt，應把 breakpoint 放在最後一個完全不變的 block，而不是 timestamp 或當次問題上。不同 Claude 模型與雲端平台的最低可快取長度不同，低於門檻時可能靜默地不快取，必須用 usage 欄位確認。
11. Anthropic 的 TTL、價格與 Rate Limit 差異
Anthropic 預設 TTL 為 5 分鐘，命中會刷新期限且不另收寫入費；5 分鐘寫入為一般輸入的 1.25 倍，1 小時寫入為 2 倍，讀取為 0.1 倍。若兩次請求間隔常超過 5 分鐘但小於 1 小時，或長時間 side agent 重用大型前綴，1 小時 TTL 才有價值。與 OpenAI 最大的營運差異之一是 Anthropic 官方指出 cache hits 不會從 rate limit 扣除，因此大型重複前綴除了省費用，也能顯著改善吞吐額度。混用 TTL 時，1 小時區段必須放在 5 分鐘區段之前。
12. Claude Code：官方已把快取視為完整產品行為
Claude Code 每一 turn 都會重新送出 system prompt、專案 context、既有訊息與工具結果，再把新訊息附在最後；模型本身不會跨請求記憶。它將罕變內容排在前面：system prompt 與 tool definitions、CLAUDE.md／auto memory／rules、最後才是持續成長的 conversation。官方文件明確列出命中與失效原因，並指出沒有「每個檔案各自快取」；檔案被讀取後只是 conversation 中的 block。模型與 effort 也屬於快取鍵，因此工作中途切換會讓下一 turn 重新處理整段歷史。
13. Claude Code 哪些操作會讓快取失效
切換 model、effort 或 fast mode，連接／中斷 MCP、啟用／停用 plugin、完全移除某個 tool、執行 /compact，以及升級 Claude Code，都可能造成局部或完整 miss。相反地，編輯一般 repo 檔案、呼叫 skill／command、執行 /recap 與 /rewind 通常保留前綴。特別容易誤解的是 CLAUDE.md：session 開始時載入後，中途編輯不會立刻改變已送入模型的內容，所以既不失效，也不會生效；要到 /clear、/compact 或重新啟動才載入新版本。
14. Claude Code 的 /compact：先命中舊快取，再建立較短的新歷史
/compact 不是把舊 cache 壓縮，而是以摘要取代 conversation history。產生摘要的那次請求在舊歷史後附加 summarization instruction，因此能讀取既有 prefix cache；摘要完成後，下一 turn 改用較短的新歷史，conversation layer 必須重新建立快取。這通常是有利的，因為未來每次輸入都變短。最佳時機是在工作階段自然分界，而不是複雜任務正中央；若只是要放棄最近走錯的路徑，/rewind 回到既有前綴通常比 compact 更省。
15. Claude Code 的 TTL、跨 Session 與 Subagent
使用 Claude 訂閱登入時，主 conversation 預設要求 1 小時 TTL；超過方案額度而改用 usage credits 時會降為 5 分鐘。API key 或 Bedrock、Google Cloud、Microsoft Foundry 等按 token 計費的路徑預設 5 分鐘，可用 ENABLE_PROMPT_CACHING_1H=1 改為 1 小時，也可用 FORCE_PROMPT_CACHING_5M=1 強制短 TTL。Claude Code 的前綴包含工作目錄、平台、shell、OS、auto-memory path 與啟動時 git snapshot，所以實務上快取約束於同一機器與目錄；不同 worktree 通常 miss。同目錄平行 session 可互相命中。Subagent 有自己的 system prompt 與工具集，第一次呼叫為冷啟動，且即使訂閱登入也使用 5 分鐘 TTL。
16. Codex：依賴 OpenAI Prompt Cache，但目前以 Session 為中心
Codex 沒有一份像 Claude Code 那樣完整的使用者向快取行為表，但 OpenAI 的開源 Codex client 顯示：ModelClient 以 session 為生命週期；每個 turn 建立 ModelClientSession，能重用 Responses WebSocket、sticky routing state 與 previous_response_id。更關鍵的是，現行程式碼的 prompt_cache_key 預設取 responses metadata 的 session_id，除非內部呼叫另行 override；compaction request 也沿用 prompt cache key。這讓同一 Codex session 的增量對話非常適合 prefix reuse，但它不等於所有新 session 都會共用相同 key。
17. Codex 使用時最需要注意的三件事
第一，不要把 fresh session 當成一定能延續舊 session 的完整快取。OpenAI 服務端仍可能依相同前綴自動命中，但 GPT-5.6 官方把一致 prompt_cache_key 視為可靠匹配的重要條件，而 Codex 一般設定目前沒有公開的 prompt cache key 控制項。第二，模型、reasoning effort、AGENTS.md／instructions、MCP 與 tool definitions 改變，都應視為可能冷啟動；在長 session 中途切換模型尤其可能重新計算大量歷史。第三，ChatGPT 登入與 API key 的成本表現不同：API key 是直接按 API token 計費；ChatGPT 登入則消耗方案額度或 credits，但 Codex 的 token-based rate card仍把 cached input 以約一般 input 的十分之一計算。
18. Claude Code 與 Codex：實務差異總結
兩者底層都是 exact-prefix reuse，而非答案快取。Claude Code 的優勢是產品層規則透明：TTL 可控、同目錄跨 session 行為有官方說明、statusline 可讀 cache_creation_input_tokens 與 cache_read_input_tokens、哪些操作失效也有明確清單。Codex 的優勢是 Responses API session、WebSocket 與 previous_response_id 的整合緊密，同一 thread 連續工作時可自然增量重用；但跨新 session 的命中可預測性與使用者可控性較低。若工作是長時間在同一 repo 反覆修改，兩者都應固定模型、effort、工具集合與專案規則；若需要大量平行 agent，Claude Code 要預期每個 subagent 首次冷啟動，Codex 則要避免假設 fork 或新 thread 自動承接父 session 的 prompt cache lineage。
19. 可直接落地的監控指標
至少建立兩個比例。Cache coverage＝cache read tokens ÷ total input tokens，用來看整體輸入有多少由快取供應；read-to-creation ratio＝cache read tokens ÷ cache creation tokens，用來看每次寫入是否被充分攤提。再按 model、workflow、prompt version、project directory、session 與 cache key 分組。理想狀況是 read tokens 隨多輪工作快速上升、creation tokens 只在冷啟動或合理版本變更時出現。若每一 turn 都大量 creation，優先檢查 system prompt、tool list、模型／effort、目錄與 git snapshot、動態 timestamp，以及是否超過 TTL。
20. 最終操作清單：真正能省成本的做法
先將大型穩定內容整理成可版本化的 canonical prefix，再把動態資料全部移到尾端；固定 model、effort、tool schema 與 JSON 順序；確保前綴超過模型最低門檻；用穩定 cache key 對應 workflow version，並依流量做一致性分片；在高併發前只預熱真正會重複使用的 prefix；選擇符合人類回覆間隔的 TTL；在自然任務邊界 compact，而不是頻繁改寫前綴；最後以 read、creation、uncached input、TTFT 與實際費用持續驗證。最重要的判斷不是「有沒有開快取」，而是「同一筆寫入之後，究竟被讀了幾次」。