掌握 Claude API 緩存計費 3 大核心機制：5分鐘 vs 1小時緩存寫入價格對比與跨賬號緩存隔離詳解

作者注：深度解析 Claude API 緩存計費機制，對比5分鐘與1小時緩存寫入的價格差異，解答跨賬號緩存命中問題，並對比 AWS Bedrock 與 Anthropic 官方 API 的緩存計費區別

Claude API 的 Prompt Caching 是降低 API 調用成本的核心手段，但很多開發者對緩存計費的細節存在疑惑：5 分鐘緩存和 1 小時緩存到底該怎麼選？跨賬號能共享緩存嗎？AWS Bedrock 的緩存計費和官方有什麼不同？

核心價值：讀完本文，你將徹底理解 Claude API 緩存計費的 3 大核心機制，掌握最優的緩存策略選擇方法，避免不必要的成本浪費。

Claude API 緩存計費核心要點

Claude 緩存計費的基礎倍率

Claude API 的 Prompt Caching 採用統一的倍率計費體系，無論使用哪個模型（Opus 4.6、Sonnet 4.6 還是 Haiku 4.5），緩存操作的倍率規則完全一致：

• 緩存寫入（5 分鐘 TTL）：基礎輸入價格 × 1.25
• 緩存寫入（1 小時 TTL）：基礎輸入價格 × 2.0
• 緩存讀取（命中）：基礎輸入價格 × 0.1

這意味着每次緩存命中，你只需支付標準輸入價格的 10%。以 Claude Sonnet 4.6 爲例，標準輸入價格爲 $3/MTok，緩存命中價格僅爲 $0.3/MTok，節省 90% 的輸入成本。

Claude 緩存計費的回本計算

理解緩存的成本收益非常重要。緩存寫入有額外費用，但緩存讀取極其便宜，關鍵在於——緩存被命中幾次後開始「回本」？

• 5 分鐘緩存：寫入 1.25x + 讀取 0.1x = 首次寫入後，只要命中 1 次就回本（因爲正常讀取是 1x，而緩存讀取 0.1x，節省 0.9x > 額外支付的 0.25x）
• 1 小時緩存：寫入 2.0x + 讀取 0.1x = 首次寫入後，需要命中 2 次才能回本（額外支付 1.0x，每次命中節省 0.9x）

所以 5 分鐘緩存幾乎是「穩賺」的選擇，而 1 小時緩存則需要確保在有效期內至少命中 2 次。

Claude 緩存計費：5 分鐘 vs 1 小時緩存對比

5 分鐘緩存 vs 1 小時緩存的價格差異

下面以各模型爲例，列出 5 分鐘和 1 小時緩存寫入的具體價格：

Claude 緩存計費的 TTL 選擇策略

5 分鐘緩存和 1 小時緩存並非二選一的關係。你可以根據實際場景靈活選擇，甚至在同一個請求中混合使用。

5 分鐘緩存適用場景：

• 高頻 API 調用（每分鐘多次請求），緩存在 5 分鐘內持續被刷新
• 交互式對話場景，用戶持續發消息，自動續期緩存
• 對成本敏感的項目，寫入費用更低

1 小時緩存適用場景：

• 批處理任務，一批數據可能間隔幾十分鐘才跑一次
• 大型 System Prompt，寫入成本高，希望緩存存活更久
• 定時任務場景，每 15-30 分鐘執行一次

重要機制：5 分鐘緩存在每次被命中時會自動刷新 TTL，等於「續期」。所以如果你的調用頻率足夠高（5 分鐘內至少有一次請求），緩存實際上可以一直存活，無需選擇 1 小時緩存。

🎯 技術建議：大多數場景下 5 分鐘緩存已經足夠。通過 API易 apiyi.com 平臺調用 Claude API 時，緩存計費規則與官方完全一致，且支持統一接口管理多個模型的緩存策略。

Claude 緩存計費中的混合 TTL 使用

Anthropic 允許在同一個請求中同時使用 1 小時和 5 分鐘兩種緩存控制，但有一個關鍵約束：

TTL 從長到短排列：1 小時緩存標記必須出現在 5 分鐘緩存標記之前。

實際應用中，你可以把變化頻率低的 System Prompt 設爲 1 小時緩存，把變化頻率稍高的 Few-shot 示例設爲 5 分鐘緩存：

import anthropic

client = anthropic.Anthropic（
    api_key="YOUR_API_KEY"，
    base_url="https://vip.apiyi.com"  # 通過 API易 調用
）

response = client.messages.create（
    model="claude-sonnet-4-6-20260320"，
    max_tokens=1024，
    system=[
        {
            "type": "text"，
            "text": "你是一個專業的技術文檔助手...（大量系統提示詞）..."，
            "cache_control": {"type": "ephemeral"， "ttl": "3600"}  # 1小時緩存
        }
    ]，
    messages=[
        {
            "role": "user"，
            "content": [
                {
                    "type": "text"，
                    "text": "以下是參考文檔...（大量上下文）..."，
                    "cache_control": {"type": "ephemeral"}  # 默認5分鐘緩存
                }，
                {
                    "type": "text"，
                    "text": "請基於上述文檔回答：什麼是 Prompt Caching？"
                }
            ]
        }
    ]
）

import anthropic

client = anthropic.Anthropic（
    api_key="YOUR_API_KEY"，
    base_url="https://vip.apiyi.com"
）

response = client.messages.create（
    model="claude-sonnet-4-6-20260320"，
    max_tokens=1024，
    system=[
        {
            "type": "text"，
            "text": "你的系統提示詞內容（需 >= 1024 tokens 才能觸發緩存）"，
            "cache_control": {"type": "ephemeral"}
        }
    ]，
    messages=[{"role": "user"， "content": "你好"}]
）

# 檢查緩存使用情況
usage = response.usage
print（f"輸入 tokens: {usage.input_tokens}"）
print（f"緩存寫入 tokens: {usage.cache_creation_input_tokens}"）
print（f"緩存命中 tokens: {usage.cache_read_input_tokens}"）

# 判斷緩存狀態
if usage.cache_read_input_tokens > 0:
    print（"緩存命中！節省了 90% 的輸入成本"）
elif usage.cache_creation_input_tokens > 0:
    print（"首次寫入緩存，後續請求將命中緩存"）

💡 注意：緩存最小 token 數有要求。Claude Opus 4.6 要求至少 1024 tokens，Sonnet 4.6 和 Haiku 4.5 也要求至少 1024 tokens。低於此閾值的內容不會被緩存。

Claude 緩存計費：跨賬號緩存隔離機制

這是很多開發者最關心的問題：A 賬號寫入的緩存，B 賬號能命中嗎？

Claude 緩存隔離的核心規則

答案很明確：不能。 緩存在不同組織（Organization）之間完全隔離。

自 2026 年 2 月 5 日起，Anthropic 將緩存隔離的粒度進一步從「組織級別」細化到了「Workspace 級別」。這意味着：

Claude 緩存隔離的實際影響

場景分析：假設你有兩個 Claude API 賬號（屬於不同 Organization），同時跑一批數據處理任務。

• 賬號 A 發送請求，觸發緩存寫入，支付 1.25x 的寫入費用
• 賬號 B 在 5 分鐘內發送完全相同的 prompt
• 結果：賬號 B 不會命中賬號 A 的緩存，B 也會觸發緩存寫入，再次支付 1.25x

這是出於安全和隱私考慮的設計——緩存內容可能包含敏感的 System Prompt 或業務數據，跨組織共享會帶來數據泄露風險。

優化策略：如果你需要多個服務共享緩存以降低成本，應該將它們的 API Key 放在同一個 Workspace 下，而不是使用不同的 Organization 賬號。

🎯 實踐建議：在 API易 apiyi.com 平臺上，每個用戶的請求會通過統一的上游通道處理。如果你需要在多個項目間共享緩存，建議在 Anthropic Console 中合理規劃 Workspace 結構，將需要共享緩存的項目放在同一個 Workspace 內。

Claude 緩存命中的條件

除了 Workspace 隔離外，緩存命中還有一個關鍵條件——prompt 必須 100% 完全相同。

緩存鍵（Cache Key）是通過對 prompt 內容進行加密哈希生成的。匹配範圍包括：

• tools（工具定義）
• system（系統提示詞）
• messages（消息歷史）

以上三個部分按順序拼接，直到 cache_control 標記位置。如果任何一個字符不同（包括空格、換行符），都不會命中緩存。

Claude 緩存計費：AWS Bedrock vs Anthropic 官方對比

AWS Bedrock 與 Anthropic API 的緩存計費差異

很多企業通過 AWS Bedrock 使用 Claude，其緩存計費與 Anthropic 官方 API 存在以下差異：

AWS Bedrock Claude 緩存計費的關鍵差異

差異一：1 小時緩存的模型支持範圍

截至 2026 年 1 月，AWS Bedrock 僅對 Claude Haiku 4.5、Sonnet 4.5 和 Opus 4.5 支持 1 小時緩存 TTL。最新的 Opus 4.6 和 Sonnet 4.6 在 Bedrock 上可能尚未支持 1 小時緩存選項。如果你需要最新模型 + 1 小時緩存的組合，建議直接使用 Anthropic 官方 API。

差異二：緩存隔離粒度

AWS Bedrock 維持 Organization 級別的緩存隔離（即 AWS Account 級別），而 Anthropic 官方 API 已經細化到 Workspace 級別。這意味着在 Bedrock 上，同一個 AWS 賬號下的所有調用可以共享緩存，粒度比官方 API 更粗。

差異三：區域定價差異

AWS Bedrock 的區域端點（如 us-east-1、eu-west-1）可能會比全球端點有約 10% 的價格溢價。這個溢價也會體現在緩存寫入和讀取的費用上。

💰 成本優化建議：如果你主要使用 Claude API 且對緩存策略有精細控制需求，通過 API易 apiyi.com 調用 Anthropic 原生 API 是更靈活的選擇。平臺支持完整的緩存控制參數傳遞，且提供更優惠的價格。

常見問題

總結

Claude API 緩存計費的核心要點：

1. 5 分鐘緩存寫入 1.25x，1 小時寫入 2.0x：大多數場景選 5 分鐘緩存即可，高頻調用下緩存自動續期，效果等同長期緩存
2. 緩存讀取僅 0.1x：命中緩存後節省 90% 輸入成本，5 分鐘緩存命中 1 次即回本
3. 緩存 Workspace 級別隔離：不同組織、不同 Workspace 之間無法共享緩存，需合理規劃 Workspace 結構

對於需要大量調用 Claude API 的開發者，合理使用緩存策略可以顯著降低成本。推薦通過 API易 apiyi.com 平臺進行 Claude API 調用，支持完整的緩存參數傳遞、統一接口管理，並提供免費測試額度幫助你驗證緩存策略效果。

參考資料

1. Anthropic Prompt Caching 官方文檔：Claude API 緩存功能完整說明

   • 鏈接：platform.claude.com/docs/en/build-with-claude/prompt-caching
   • 說明：包含緩存定價倍率、TTL 設置、最小 token 要求等核心參數

2. Anthropic API 定價頁面：所有 Claude 模型的最新價格

   • 鏈接：platform.claude.com/docs/en/about-claude/pricing
   • 說明：包含基礎輸入/輸出價格以及緩存操作的詳細定價

3. AWS Bedrock Prompt Caching 文檔：AWS 平臺上的 Claude 緩存使用指南

   • 鏈接：docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html
   • 說明：Bedrock 特有的緩存配置方式和支持模型列表

4. AWS Bedrock 1 小時緩存公告：1 小時緩存 TTL 功能發佈說明

   • 鏈接：aws.amazon.com/about-aws/whats-new/2026/01/amazon-bedrock-one-hour-duration-prompt-caching/
   • 說明：Bedrock 支持 1 小時緩存的模型範圍和使用方式

作者：APIYI 技術團隊
技術交流：歡迎在評論區討論 Claude 緩存計費相關問題，更多 API 使用技巧可訪問 API易 docs.apiyi.com 文檔中心