摘要： Firecrawl 在 2026 年 10 月 18 日發表一篇 prompt caching 的完整整理，涵蓋運作原理、三大 API 的定價差異，以及讓快取持續命中的實務做法。對任何在跑 agent 或長對話的人來說，這直接決定 token 帳單是別人的幾分之一還是幾倍。
為什麼快取救的是 agent
模型 API 是無狀態的。每一輪對話都會重送 system prompt、工具定義和整段歷史，模型全部重算一次。Longju Bai 等人在 2026 年 4 月對八個前沿模型做 SWE-bench Verified 研究時發現，agentic coding 任務消耗的 token 是程式對話的一千倍，而且大宗在輸入端。
Prompt caching 的做法是把 prompt 前綴的 KV 張量存在供應商的伺服器上。因為注意力是因果的，token 500 的向量只取決於前面 1 到 499 個 token，所以重用只對「前綴」成立——改了第 12 個 token，從那之後的快取全部作廢。這也代表：把永不變的內容放最前面、常變的放最後，是所有供應商通用的第一原則。另外注意，prompt caching 不會改變輸出，Anthropic 文件明言結果與不用快取完全相同。
定價：寫入要付費，讀取才省錢
依 Firecrawl 在 2026 年 10 月 18 日彙整的清單價：Anthropic 的快取讀取是原輸入價的 0.05x 到 0.1x（Fable 5.1 更低到 0.025x），寫入則要 1.25x（5 分鐘）或 2x（1 小時）。OpenAI GPT-5.6 之後讀取 0.1x（特定型號 0.05x），寫入 1.25x。Gemini 對 2.5 以後的型號做隱式快取，寫入不加價，但不保證命中。
換算下來，1.25x 的寫入只要重用一次就回本；1 小時檔要兩次。所以判斷標準很簡單：這段前綴會不會在快取存活時間內出現第二次？會，就該標斷點。
命中率是設定問題，不是運氣
這篇最有說服力的數據來自 AI gateway Requesty 在 2026 年 4 月的流量統計：同一批 Claude 模型，走 Anthropic 自己 API 的請求有 77% 的輸入 token 讀自快取，走 Google Vertex 的只有 24%。模型一樣，Requesty 把差距歸因於設定。之前我寫過 Amazon Bedrock prompt caching 壓低成本的做法，結論相同——快取效益幾乎完全由你怎麼組織請求決定。
Firecrawl 列出的失效清單值得貼在團隊 wiki 上：斷點之前任何位元組改動都會打掉快取，包括時間戳、工具定義變動、模型或 effort 切換、不穩定的 JSON 序列化，以及閒置超過存活時間。Anthropic 還有兩個容易踩的細節：5 分鐘的壽命從請求「開始」起算，一個串流 4 分鐘的回應結束後只剩約 1 分鐘；同時 fan-out 十個相同前綴的請求，十個都會寫入快取——先發一個、等它開始回應再放行其餘。
把命中率當成要監控的指標
Anthropic 的 Claude Code 團隊對快取命中率設了告警，掉下來視為事故處理；團隊成員 Thariq Shihipar 的說法是「Cache Rules Everything Around Me」。OpenAI 也在 2026 年 9 月推出了命中率 dashboard 和 miss 診斷欄位（Anthropic 對應的是 diagnostics.cache_miss_reason）。如果你的 agent 框架還沒把 cache_read_input_tokens 之類的欄位記進觀測系統，這是本週就能做的小改動：先量，再談優化。
一個務實的邊界提醒：Gemini 目前型號的最低門檻是 4,096 tokens，短 prompt 根本進不了快取；而隱式快取沒有命中保證。工具覆蓋越多供應商差異，越要在自己這層統一量測。