Prompt Caching

Prompt Caching 的工作原理：什麼是「快取前綴」，為什麼能大幅降低費用？

Claude API 的計費方式是按 Token 計算的——每次 API 呼叫，輸入的 Token 數量決定了輸入費用，輸出的 Token 數量決定輸出費用。

在很多應用場景裡，每次 API 呼叫的「前半段」（System Prompt、背景文件、角色設定）是完全相同的，只有「後半段」（用戶的問題）每次不同。在沒有 Prompt Caching 的情況下，每次 API 呼叫都要把完整的 System Prompt 送到 Anthropic 的伺服器重新計算，即使內容完全一樣。

Prompt Caching 的原理是：第一次 API 呼叫時，Anthropic 的伺服器計算並儲存 System Prompt 的「中間計算狀態」（KV Cache）；後續的 API 呼叫只需要讀取這個快取，不需要重新計算。讀取快取的費用是原始計算費用的 10%——也就是快取命中時，那些 Token 的費用降低 90%。

快取有效期是 5 分鐘，每次命中都會重置計時。這意味著只要你的 API 呼叫頻率高於每 5 分鐘一次，快取就能持續有效。

一個具體的費用計算例子：System Prompt 是 3,000 tokens，用戶問題是 100 tokens，每次呼叫的輸入費用原本是 (3,000 + 100) × $0.003/1K = $0.0093。有了 Prompt Caching，快取命中時的費用是 3,000 × $0.003 × 10% + 100 × $0.003 = $0.0009 + $0.0003 = $0.0012，節省了 87%。

怎麼在 API 裡正確實作 Prompt Caching？有哪些常見的實作錯誤？

正確的實作方式：

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            "text": "你的固定 System Prompt 內容（必須超過 1,024 tokens）",
            "cache_control": {"type": "ephemeral"}  # 加這個就啟用快取
        }
    ],
    messages=[
        {"role": "user", "content": user_question}  # 每次不同的用戶問題
    ]
)

# 確認快取狀態
print(response.usage.cache_creation_input_tokens)  # 第一次：有值
print(response.usage.cache_read_input_tokens)       # 後續：有值

常見的實作錯誤：

錯誤一：System Prompt 太短（不到 1,024 tokens），加了 cache_control 也不會有快取效益——Anthropic 的快取最小要求是 1,024 tokens。解法：如果 System Prompt 很短，考慮是否需要把背景文件也加進去，讓可快取的前綴夠長。

錯誤二：快取標記加在了每次都變動的部分。cache_control 只對它標記的文字前面的所有內容有效，而且快取只在內容完全相同時才命中。如果你把 cache_control 加在包含用戶動態資訊的部分，每次內容都不同，快取永遠不會命中。

錯誤三：沒有確認快取實際是否命中。在回應的 usage 欄位裡檢查 cache_read_input_tokens，如果一直是 0，代表快取沒有命中，需要檢查設定是否正確。

Prompt Caching 最適合哪些應用場景？怎麼計算預期的費用節省？

最適合 Prompt Caching 的場景：

多輪對話應用——每輪對話的 System Prompt 相同，只有用戶訊息和 Assistant 回覆在累積。這是快取效益最大的場景之一，因為 System Prompt 在整個對話裡只需要計算一次。

知識庫問答（RAG）——把一份長篇的知識庫文件放在 System Prompt 裡，不同用戶的問題用同一個文件作為上下文。這種場景下，知識庫文件可能有 50,000-100,000 tokens，快取節省的費用非常顯著。

批次處理——對大量文件（100 份合約、1,000 封郵件）用相同的分析指令做批次分析。指令部分作為快取前綴，每個文件作為用戶輸入。

費用節省的估算公式：

預期月費用節省 = (System Prompt tokens × 呼叫次數 × 快取命中率 × 0.9 × 輸入費率)

簡化版估算：如果你的 System Prompt 是 2,000 tokens，每月 10,000 次 API 呼叫，快取命中率 90%（呼叫頻率高於每 5 分鐘一次），使用 Sonnet 4.5（$0.003/1K 輸入），月費用節省約 = 2,000 × 10,000 × 0.9 × 0.9 × $0.003 / 1,000 = $48.6。

這個計算說明：對高頻率的 API 應用，Prompt Caching 的費用節省規模很可觀，遠超它的設置成本（幾分鐘的程式碼修改）。

Prompt Caching 和其他費用優化策略（模型降級、輸出長度控制）怎麼組合使用效果最好？

Prompt Caching 是幾個主要 Claude API 費用優化工具之一，和其他工具組合使用效果更好：

組合一：Prompt Caching + 分層路由

用 Haiku 做分類路由（決定請求的複雜度），再根據複雜度選用 Sonnet 或 Opus。每個模型都分別啟用 Prompt Caching（每個模型的 System Prompt 可能不同）。這個組合通常能把費用降低 60-75%：Haiku 的低費用負責路由，Prompt Caching 降低每個模型的 System Prompt 費用，分層路由減少高費用模型的使用量。

組合二：Prompt Caching + 對話歷史管理

對長對話，把對話歷史控制在合理範圍內（用摘要壓縮舊的歷史），同時對 System Prompt 啟用快取。快取處理固定的前綴費用，歷史管理控制動態部分的增長。

組合三：Prompt Caching + 批次處理（Batch API）

Anthropic 的 Batch API 讓你一次送出大量請求，費用是即時 API 的 50%，但處理時間更長（適合不需要即時回應的任務）。配合 Prompt Caching，對批次處理任務的費用節省可以達到 80-90%。

對你的 API 費用有什麼實際影響：如果你每月的 Claude API 費用超過 $100，建議依這個順序評估優化：先檢查是否有啟用 Prompt Caching（5 分鐘設定，最快的省錢方式）；再分析請求分布，評估分層路由是否值得（開發成本更高，但節省幅度也更大）；最後考慮 Batch API（適合非即時任務）。