「1小時提示快取優化微妙，寫入成本高但讀取便宜，效果依使用模式而定

「1小時提示快取優化微妙，寫入成本高但讀取便宜，效果依使用模式而定。」

Anthropic的「提示快取」功能透過重用提示前綴，優化API使用，降低重複任務的處理時間與成本，但1小時快取的寫入成本為基準輸入token的2倍，讀取僅0.1倍，效益高度依賴上下文視窗大小、主Agent或子Agent等使用模式，並非人人適用。

定價細節與成本權衡

提示快取引入新定價結構，5分鐘快取寫入為基準輸入token價格的1.25倍，1小時寫入為2倍，讀取統一為0.1倍，這些倍數會與Batch API折扣或資料駐留等其他修改器疊加。

• 快取寫入成本較高，若僅單次查詢使用1小時快取，即浪費並多付費用，例如僅呼叫Agent一次即無效益。
• 讀取雖便宜，但效果不均勻；作者測試多種啟發式方法提升訂閱者快取命中率，從而降低token用量與延遲，但遠非12倍節省，僅為小幅勝利。
• 預設快取存活期為5分鐘，重複使用時免費刷新；1小時選項需額外付費，目前尚未預設給API客戶，需更多測試確認平均淨改善。

快取啟用方式

有兩種啟用提示快取的方法，適用於所有活躍Claude模型，並支援Zero Data Retention (ZDR)，ZDR組織的資料在API回應後不儲存。

• 自動快取：在請求頂層加單一「cache_control」欄位，系統自動套用至最後可快取區塊，適合多輪對話，隨著訊息歷史成長自動前移斷點。
• 明確快取斷點：直接在個別內容區塊置「cache_control」，提供精細控制，可定義最多4個斷點，結合自動快取時自動斷點佔用1個槽位。

自動快取在多輪對話中，斷點自動移至最後可快取區塊，先前內容從快取讀取；邊緣情況包括最後區塊已有相同TTL的明確控制則無操作，不同TTL或4槽滿時回傳400錯誤，若最後區塊不可快取則後退尋找最近可快取區塊，無則略過。

運作機制與前綴檢查

系統檢查提示前綴（tools、system、messages順序）是否在近期查詢已快取，若命中則重用，否則全處理並在回應開始時快取前綴；預設5分鐘TTL，1小時需額外成本。

• 快取寫入僅在斷點發生，雜湊涵蓋至斷點為止，前綴變更即產生新雜湊。
• 讀取向後檢查最多20區塊（斷點計為第一），尋找先前寫入的匹配項目，非自動快取穩定內容。
• 成長對話範例：第1輪10區塊寫入斷點10；第2輪15區塊命中斷點10，新寫斷點15；第3輪35區塊20區塊視窗（35至16）無命中，斷點15在外，若加第二斷點於15則可命中。

常見錯誤：斷點置於每請求變更內容（如含時間戳使用者訊息），後續請求雜湊不同，看回20區塊也無先前寫入，永無命中，全付新寫入費；解決為置斷點於靜態前綴末端。

多斷點策略與限制

最多4斷點適合不同頻率變更區段（如tools少變、上下文每日更新），或成長對話超過20區塊時確保命中，預先在較近位置寫入累積。

• 關鍵限制：看回僅找先前寫入，若成長推斷點超20區塊即錯過，須從頭加第二斷點。
• 快取斷點本身無成本，僅依實際寫入（5分鐘TTL多25%）與讀取（10%）計費，多斷點不增成本。
• 最小快取長度依模型：Claude Mythos Preview等4096 token，Claude Sonnet 4.6為2048 token，Claude Sonnet 4.5等1024 token，Claude Haiku 4.5為4096 token；不足則無快取，檢查回應usage欄位確認，若cache_creation_input_tokens與cache_read_input_tokens皆0即未快取。

建議擴充至門檻，因讀取遠低於未快取輸入；並發請求需等首回應後發後續，否則無快取可用。目前僅支援「ephemeral」快取類型，預設5分鐘。

可快取與不可快取內容

大多數區塊可快取，按tools→system→messages階層，變更會無效化該層及後續。

• 可快取：
  • Tools陣列中工具定義。
  • System陣列內容區塊。
  • Messages.content陣列文字訊息（使用者與助理）。
  • 使用者回合的圖像與文件。
  • 工具使用與結果（助理與使用者回合）。
• 不可快取：
  • Thinking區塊無法直接標記，但先前助理回合中可隨其他內容快取，讀取時計入輸入token。
  • 子內容如引用無法直接快取，改快取上層區塊；文件來源可快取以支援引用。
  • 空文字區塊。

無效化規則與效能追蹤

變更無效化依階層：tools變更無效tools及後；system變更無效system及messages；messages變更僅無效messages（表格顯示✘無效、✓有效）。

• 追蹤效能用回應usage欄位：
  • cache_creation_input_tokens：新寫入token數。
  • cache_read_input_tokens：本次讀取token數。
  • input_tokens：未快取或非快取建立的token（最後斷點後）。

實際部署與作者反思

作者已預設1小時快取於多處讓訂閱者依真實模式優化，但許多查詢（如罕見恢復的子Agent）維持5分鐘，避免無益付費；API客戶尚未預設，需更多測試。實驗用客戶端快取實驗閘門，關telemetry時禁用不呼叫家，讀預設5分鐘，近期將改部分查詢客戶端預設為1小時，並提供環境變數強制1小時或5分鐘。總體token節省小幅，正在逐步推廣全體。更多細節見官方文件。

此功能特別適合含多範例、大上下文、重複指示或長多輪對話，但作者強調1小時快取微妙，非萬靈丹，單次使用即浪費，呼籲依模式選擇，避免過度樂觀預期12倍節省。自動快取簡易但陷阱多，如斷點置變動區塊即失效，明確斷點提供精控。邊緣處理如槽位滿或不可快取區塊，系統有默認行為但易忽略，開發者須監控usage確認實際命中。最小長度門檻迫使短提示擴充，但讀取0.1倍優勢明顯，值得投資靜態前綴。成長對話超20區塊需多斷點預防，凸顯快取非全自動，需策略規劃。無效化階層嚴格，任何前綴微調即重寫，強調提示結構化重要性：靜態置前、斷點精準。整體而言，提示快取是小勝而非革命，Anthropic透過測試與環境變數逐步優化使用者體驗，但忠實反映其nuanced本質。