platform.claude.com/docs/en/build-with-claude/prompt-caching),並按 API易 的接入方式給出可直接複製的示例。
一句話理解
把一段反覆使用的長 prompt(系統說明 / 長文件 / few-shot 示例)打上cache_control 標記,伺服器會把它存起來。下次相同字首的請求來,伺服器跳過重複處理,便宜約 10 倍、也更快。一段時間內沒人再用就會過期。
為什麼要用 —— 看賬單倍率
以模型原始輸入 token 價為 1× 計:
回本點:
- 5 分鐘 TTL:只需 2 次複用同一字首即可回本(1.25 + 0.1 = 1.35,比兩次不快取的 2.0 便宜)。
- 1 小時 TTL:需要 3 次才回本(2 + 0.2 = 2.2,比 3.0 便宜)。
TTL 是滑動視窗:每次命中都會把過期時間重置,因此活躍的會話不會平白過期。只有真正閒置超過 TTL 才會失效。
適合場景
- 同一份長系統提示詞被多次呼叫(Agent、客服機器人)
- 多輪對話(每加一輪,前面的歷史都能複用)
- 批次處理同一份文件(一份合同問 50 個問題)
- RAG 把檢索到的穩定文件塊作為字首
不適合場景
- 每次 prompt 從第一個字開始都不一樣
- 整體很短,根本到不了最小 token 閾值(見下)
- 聊天客戶端裡每輪都重新組織上傳附件的對話(原因見下方「圖片和檔案也能快取」)
觸發快取的三個硬條件
缺一不可。1. 必須顯式打標記 cache_control
content 不能是純字串,必須是 content block 陣列,在要快取的那一塊上加 cache_control:
2. 長度必須達到最小閾值
短於閾值的內容,就算打了標記也不會快取(不報錯,靜默忽略)。按模型不同:實測校驗(2026-07-29,API易 站內)。 我們用逐檔遞增的固定字首實測了寫入起點:
claude-opus-5 在 301 tokens 時不產生快取寫入、614 tokens 時產生,落點與官方 512 一致;claude-sonnet-5 在 612 tokens 時不寫入、1250 tokens 時寫入,落點與官方 1024 一致。兩者均與上表吻合。3. 字首必須逐位元組相同
快取按字首匹配:從請求開頭一直到cache_control 標記位置,這段位元組流必須和上一次完全一樣。改任何一個字元——哪怕是空格、JSON 欄位順序、時間戳——都算”新字首”,會重新寫入而不是命中。
實踐含義:穩定的東西放前面,易變的東西放後面。
最小可執行示例
跑兩次同一段長文 + 不同問題,第一次寫入快取,第二次命中:read ≈ 第 1 次的 write,說明同一段字首被命中複用了。
怎麼判斷命中沒命中 —— 看三個欄位
每次響應的usage 裡:
輸入總量 = 三者之和。 只要
cache_read_input_tokens > 0,你就在省錢。
最常見的踩坑
圖片和檔案也能快取 —— 但附件場景命中會不穩
先澄清一個常見誤解:不是 Claude 對圖片/檔案的快取”有問題”。Anthropic 官方明確說明文本、圖片、文件都可以進入 Prompt Cache,三者一視同仁。 真正的原因還是上面那條硬條件:快取匹配的是請求的完整字首,而圖片和檔案的那串位元組同樣算在字首裡。只要客戶端每輪對附件的組織方式有任何變化,字首就斷了。官方還特別提到一點:改變 prompt 裡是否包含圖片,會讓對應的快取失效。兩類場景的差別
Claude Code、Cline、Cursor 這類編碼客戶端屬於前一類,命中通常很穩。Chatbox、Cherry Studio 這類 GUI 客戶端在純文本對話時同樣穩,只有在對話裡夾了上傳檔案或較大圖片附件時,才容易出現命中率掉下去的情況。
附件場景怎麼把命中率救回來
- 附件放最前面、順序固定 —— 它們是最大塊也最穩定的內容,天然該佔據字首
- 同一份附件只編碼一次,之後複用同一份 base64,不要每輪重新讀檔案重新編碼(重新編碼出來的位元組不保證完全一致)
- 不要每輪重排 content block,尤其不要”這輪圖在前、下輪圖在後”
cache_control打在附件之後,讓附件整體落進快取- 對話中途儘量不增刪附件 —— 加一張圖、去一張圖,都會讓它之後的整段字首失效
進階:多輪對話怎麼打
把cache_control 打在最近一條 user 訊息的最後一個 content block 上。每加一輪,快取讀取範圍會自動延伸到上一輪結束的位置:
- 單次請求最多 4 個
cache_control斷點。 - 每個斷點的字首查詢只回溯最近 20 個 content block——超出 20 個 block 的更久遠內容不會再被檢索去拼命中。換言之:很長的多輪對話靠”最末一次打標記”是兜不住前面所有歷史的。
API易 關於快取的說明
API易完整透傳快取欄位。 你在請求裡寫的
cache_control 會原樣轉發給上游 Claude(AWS Claude 或 Claude Official),響應裡的 cache_creation_input_tokens / cache_read_input_tokens 也會原樣回吐給你——所以你的程式碼無需為中轉層做任何額外適配。- 第一次傳送時觀察響應
usage.cache_creation_input_tokens > 0(寫入成功)。 - 幾秒後用相同字首再發一次,應看到
usage.cache_read_input_tokens > 0(命中)。 - 後臺賬單裡會單獨顯示快取寫入 / 快取讀取兩類計費項,倍率與官方一致(1.25× / 2× / 0.1×)。
要點回顧
1. 打標記
cache_control: {"type": "ephemeral"} 加在 content block 上,純字串 content 永不快取。2. 夠長度
Opus 5 ≥ 512、Sonnet 5 / Sonnet 4.6 ≥ 1024、Opus 4.7 ≥ 2048、Opus 4.6 / Haiku 4.5 ≥ 4096 tokens,否則靜默忽略。
3. 穩字首
穩定內容在前、易變內容在後;任何一個字元變化都會讓快取失效。
4. 看 usage
cache_read_input_tokens > 0 才說明真的省錢了;它應約等於上一輪的 cache_creation_input_tokens。5. 附件要固定
圖片和檔案同樣能快取,但每輪重新組織附件會讓字首失效——附件放前面、順序固定、只編碼一次。
相關連結
- 父頁面:Claude API 呼叫基礎說明
- 客戶端配置教程:Claude Code 接入指南 · Cherry Studio 接入指南
- 獲取 / 管理令牌:
https://api.apiyi.com/token - Anthropic 官方文件:
platform.claude.com/docs/en/build-with-claude/prompt-caching