Claude 提示快取損益兩平怎麼算？

提示快取產生節省前的成本

提示快取可讓 Claude 重複使用提示的前段內容，而不必在每次呼叫時重新讀取。整體取捨取決於模型基本輸入價格的兩個倍數。截至 August 2026，5 minute 有效期限的快取寫入費用是基本輸入價格的 1.25x，1 hour 有效期限則是 2x。快取讀取費用是 0.1x。這些倍數適用於所有模型，因此每個 token 的價格變動時，下方的損益平衡點也不會改變。

這項取捨是在現在支付附加費，換取之後享有折扣。你只需支付一次額外費用來儲存前綴。之後每個以完全相同位元組開頭的請求，該部分只需支付一般輸入價格的十分之一。如果前綴在有效期限內從未重複使用，就會平白多支付 25 percent 的費用。

單行代數表示損益兩平點

將未使用快取時傳送前綴的基本輸入成本記為 B。未使用快取時，N 個請求的成本為 N 乘以 B。使用 5 minute 快取時，第一個請求會以 1.25B 寫入前綴，其餘 N 減 1 個請求則以 0.1B 讀取。令兩者相等，可得 0.9N = 1.15，因此 N = 1.28。第二個請求的成本就已低於完全不使用快取的情況。

對 1 hour 快取的寫入成本套用 2x 倍數後，可得 0.9N = 1.9，因此 N = 2.11。長時間快取需要兩次讀取後才達到損益兩平，因此不是預設選項。

下圖以 Claude Opus 5 的 20,000 token 前綴計算成本。以 2026 年 8 月的每百萬 token $5 基本輸入費率為準。若模型費率為每百萬 token $3，所有數值乘以 0.6。曲線形狀不變。

[
  {
    "requests": 1,
    "uncached_usd": "0.10",
    "cached_5m_usd": "0.125",
    "cached_1h_usd": "0.20"
  },
  {
    "requests": 2,
    "uncached_usd": "0.20",
    "cached_5m_usd": "0.135",
    "cached_1h_usd": "0.21"
  },
  {
    "requests": 3,
    "uncached_usd": "0.30",
    "cached_5m_usd": "0.145",
    "cached_1h_usd": "0.22"
  },
  {
    "requests": 5,
    "uncached_usd": "0.50",
    "cached_5m_usd": "0.165",
    "cached_1h_usd": "0.24"
  },
  {
    "requests": 10,
    "uncached_usd": "1.00",
    "cached_5m_usd": "0.215",
    "cached_1h_usd": "0.29"
  },
  {
    "requests": 20,
    "uncached_usd": "2.00",
    "cached_5m_usd": "0.315",
    "cached_1h_usd": "0.39"
  }
]

單獨執行一次請求時，未使用快取的成本為 $0.10，使用快取的成本為 $0.125，因此對只使用一次的提示套用快取只會增加成本。執行第二個請求時，5 minute 快取的成本為 $0.135，低於未使用快取的 $0.20。此時 1 hour 快取仍然較高，為 $0.21，而未使用快取的成本仍為 $0.20。直到第三個請求，1 hour 快取才低於未使用快取的成本：$0.22，相較於未使用快取的 $0.30。執行 20 個請求後，兩者差距為未使用快取的 $2.00，相較於使用 5 minute 快取的 $0.315。

快取命中也會更新項目的有效期間，因此已發布的價格表將該欄位稱為快取命中與更新。繁忙的端點會持續以讀取價格維持 5 minute 項目，直到流量中斷。1 hour 有效期間只有在流量確實存在間隔時，才值得支付 2x 的寫入成本。

低命中率的成本

實際流量會發生未命中。請求未命中快取，但仍包含 breakpoint 時，會按寫入計費，因此應將成本建模為命中率的函數。下圖以 1,000 個請求進行計算，每個請求都包含相同的 20,000 token 前綴。

[
  {
    "hit_rate_percent": 0,
    "cost_5m_usd": "125.00",
    "cost_1h_usd": "200.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 25,
    "cost_5m_usd": "96.25",
    "cost_1h_usd": "152.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 50,
    "cost_5m_usd": "67.50",
    "cost_1h_usd": "105.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 75,
    "cost_5m_usd": "38.75",
    "cost_1h_usd": "57.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 90,
    "cost_5m_usd": "21.50",
    "cost_1h_usd": "29.00",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 95,
    "cost_5m_usd": "15.75",
    "cost_1h_usd": "19.50",
    "uncached_usd": "100.00"
  },
  {
    "hit_rate_percent": 99,
    "cost_5m_usd": "11.15",
    "cost_1h_usd": "11.90",
    "uncached_usd": "100.00"
  }
]

命中率為 0 percent 時，費用為 $125.00，而不是 $100.00；1 hour cache 會使帳單加倍至 $200.00。解方程式 1.25 減去 1.15h 等於 1，可得 5 minute cache 約在命中率 22 percent 時開始節省成本，因此命中率達到 25 percent 時，費用已是 $96.25。對 2x write 進行相同計算，可得 1 hour cache 約需 53 percent 的命中率，因此命中率 50 percent 時，費用仍為 $105.00，高於未快取的費用。在 90 percent 命中率時，兩者的費用分別為 $21.50 和 $29.00。在 99 percent 命中率時，短期快取的費用降至 $11.15，接近未快取價格十分之一的下限。

前綴大小固定後，應監控的數值就是命中率，因為這是唯一仍可控制的輸入值。

哪些前綴值得設定快取斷點

一次請求最多可包含 4 個快取斷點，因此問題在於哪些區塊值得設定斷點。候選區塊必須在多次呼叫中逐位元組完全相同，且規模大到足以產生影響。下圖以 5 分鐘快取、90% 命中率，計算 1,000 次請求中 4 種常見結構的成本。

[
  {
    "label": "System prompt",
    "prefix_size_tokens": "2,000",
    "uncached_usd": "10.00",
    "cached_usd": "2.15",
    "saved_usd": "7.85"
  },
  {
    "label": "System plus tools",
    "prefix_size_tokens": "8,000",
    "uncached_usd": "40.00",
    "cached_usd": "8.60",
    "saved_usd": "31.40"
  },
  {
    "label": "Policy document",
    "prefix_size_tokens": "25,000",
    "uncached_usd": "125.00",
    "cached_usd": "26.88",
    "saved_usd": "98.12"
  },
  {
    "label": "Codebase context",
    "prefix_size_tokens": "120,000",
    "uncached_usd": "600.00",
    "cached_usd": "129.00",
    "saved_usd": "471.00"
  }
]

僅含 2,000 token 的系統提示，對比未快取的 $10.00，每 1,000 次請求可節省 $7.85。大量請求時確實能省下實際成本，但這還不是快取真正有價值的原因。加入工具定義後，前綴長度達到 8,000 tokens，可節省 $31.40。每次請求都會針對其提問的 25,000 token 政策文件，可節省 $98.12。最後一列才會改變架構：120,000 tokens 的程式碼庫或逐字稿內容，未快取時成本為 $600.00，快取後為 $129.00，可節省 $471.00。

節省金額會隨前綴大小與命中率增加，除此之外不受其他因素影響。這也改變了哪些內容值得放入提示的判斷：一百萬個 Claude tokens 實際要花多少成本 對於重複傳送的內容，成本會降至標價的十分之一。

每月帳單上的實際金額

下圖以先前的 8,000 token 前綴、系統提示與工具定義為基礎，採用 90% 命中率，並將其換算為每月請求量。

[
  {
    "label": "10k requests",
    "uncached_usd": "400.00",
    "cached_usd": "86.00",
    "saved_usd": "314.00"
  },
  {
    "label": "100k requests",
    "uncached_usd": "4,000.00",
    "cached_usd": "860.00",
    "saved_usd": "3,140.00"
  },
  {
    "label": "1M requests",
    "uncached_usd": "40,000.00",
    "cached_usd": "8,600.00",
    "saved_usd": "31,400.00"
  }
]

每月 10,000 次請求可節省 $314.00，也就是 $400.00 與 $86.00 之間的差額。每月 100,000 次請求可節省 $3,140.00。每月 1,000,000 次請求時，未快取的輸入帳單為 $40,000.00，快取可從中省下 $31,400.00。以上僅計算輸入 token。輸出 token 另行計價，快取不會降低輸出費用。在向任何人承諾帳單可降低 90% 前，請記住這點。快取只是 控制 VPS 上 AI agent 帳單的整體做法之一。

如何確認快取正在運作

不要只相信設計。請讀取回應中的 usage 區塊。每個 Messages API（應用程式設計介面）回應都會回報寫入的快取 token、讀取的快取 token，以及必須處理的新 token 數量。

from anthropic import Anthropic

client = Anthropic()

resp = client.messages.create(
    model="claude-opus-5",
    max_tokens=512,
    system=[
        {
            "type": "text",
            "text": POLICY_DOCUMENT,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": question}],
)

u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)

使用相同文件和不同問題執行兩次。第一次呼叫會回報非零的 cache_creation_input_tokens，而 cache_read_input_tokens 為 0。第二次則相反，因為系統已找到前綴。input_tokens 只計算最後一個 breakpoint 之後的 token，因此健康的第二次呼叫通常很小，通常只有新的使用者訊息。兩次呼叫都會計費，因為 Claude API 沒有免費方案；不過，以前述定價計算，20,000 token 的前綴每組呼叫約為 14 美分。

從 shell 執行相同檢查時，可針對已儲存至 request.json 的請求本文：

curl -s https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d @request.json | jq '.usage'

健康的第二次呼叫會輸出類似以下內容：

{
  "input_tokens": 42,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 20143,
  "output_tokens": 187
}

其中一行會顯示實際情況。如果 cache_read_input_tokens 在多次呼叫中都維持為 0，代表每次都支付 1.25x 的寫入費用，卻完全沒有取得任何快取內容。

若要設定 1 hour 的存留時間，breakpoint 會帶有存留時間（TTL）：

{
  "type": "text",
  "text": "your stable prefix",
  "cache_control": {"type": "ephemeral", "ttl": "1h"}
}

另外也可使用自動快取：在請求最上層加入單一 cache_control 欄位，之後由 API 隨對話增長自動管理 breakpoint。這會占用 4 個 breakpoint slot 其中之一。請先從這個方式開始。需要精確決定邊界位置時，再改用明確的 breakpoint。

會摧毀命中率的排序規則

快取會從請求開頭逐一比對前綴位元組，而請求的組成順序固定為：tools、system，接著是 messages。任一層發生變更，都會使該層及其後的所有內容失效。即使未修改 system prompt 或整段訊息歷程，只要編輯一項工具描述，這些內容也會一併失效。

因此只有一項毫無例外的規則：每次請求都會變動的內容，必須排在所有不會變動的內容之後。

最常見的問題是時間戳記。在 system prompt 頂端放入一行 Current time: 2026-08-03T14:07:11Z，會使命中率固定為 0%，因為每次請求的前綴雜湊都不同，先前的項目永遠無法與它相符。請將它移至 user message 的末尾。工作階段識別碼或每次請求產生的 nonce 也會造成相同問題，修正方式相同。每次請求都不同的擷取文件，也應放在快取區塊之後；否則它們會將所有穩定 token 推到會移動的邊界後方。

第二個問題是將斷點放在會變動的區塊上。快取會在斷點寫入，因此如果該區塊每次都不同，就不會儲存任何穩定內容；回溯查找時，只會找到先前請求在各自變動的斷點寫入的項目。請將 cache_control 放在跨請求內容完全相同的最後一個區塊上。

第三個問題是變更了你未視為 prompt 內容的參數。不同的 model 會使用不同的快取。變更 tool choice 會從 system 層開始使內容失效。新增或移除工具則會使所有內容失效。

最小前綴與靜默無操作

短於模型最小長度的前綴不會建立快取，而且不會顯示任何提示。沒有錯誤，也沒有警告。請求會成功，但兩個計數器都會顯示 0。截至 2026 年 8 月，已公布的最小長度如下：

• Claude Opus 5 和 Claude Fable 5 為 512 個 token
• Claude Sonnet 5 和 Claude Opus 4.8 為 1,024 個 token
• Claude Haiku 4.5 為 4,096 個 token

如果您認為請求應使用快取，但兩個計數器都顯示 0，請先檢查前綴長度。這也是最便宜的模型不一定最適合快取工作負載的原因。Claude Haiku 4.5 需要比 Claude Opus 5 長 8 倍的前綴，快取才會啟用。因此，2,000 個 token 的系統提示會在其中一個模型建立快取，卻在另一個模型遭到靜默忽略。

Claude Code 會快取哪些內容，以及哪些內容無法快取

Claude Code 會快取自己的前綴。系統提示與工具定義位於每個請求的開頭，且不會變動，因此只需寫入一次，之後在本次工作階段中讀取即可。這就是為什麼長時間工作階段的每回合成本，遠低於內容大小所顯示的數值；相關資訊也會出現在Claude Code 回報 token 使用量的方式所述的計數器中。

如果是在內容開頭附近進行編輯，快取就無法提供協助。對話記錄只能附加內容，因此一般的新回合會延伸已快取的前綴。在工作階段早期讀取的檔案若遭到修改，前綴中間的內容就會改變，變更後的每個 token 都必須重新寫入。長時間閒置也會造成相同結果，因為項目會過期，下一回合必須完整寫入。這兩種情況都不是錯誤，而是前綴規則依照設計運作的結果。

如果你改為撰寫自己的 client，應從第一個請求就套用正確的配置，而不是事後調整。請依照在 VPS 上建立第一個 Claude API 應用程式的方式建構呼叫，先放置穩定區塊，最後再放置易變區塊。

失敗模式與可觀察到的現象

每次呼叫都是寫入。 每個請求的 cache_creation_input_tokens 都是非零，而 cache_read_input_tokens 維持 0。斷點所在位置或之前的內容在各次呼叫之間發生變化。連續送出兩個請求，分別列印組合後前綴的前 200 個字元，再直接比較。

兩個計數器都是 0。 前綴短於模型的最低要求，或 cache_control 欄位從未送達 API。先計算前綴的 token 數，再記錄實際送出的請求本文。

讀取有效，之後停止。 先連續命中，接著發生一次寫入，之後又恢復命中。請求之間的間隔超過了存留時間。接受這次寫入；確認命中率超過 53 percent 後，再改用 1 hour TTL。

部署後命中率下降。 工具說明遭到修改，或模型有所變更。這兩種情況都會使整個前綴失效。每次部署只要涉及提示，就應預期會先出現一輪成本較高的寫入。

啟用快取後帳單增加。 命中率低於損益平衡點。使用 5 minute 快取時，低於約 22 percent，未快取而直接傳送前綴的成本較低；使用 1 hour 快取時，低於約 53 percent 也是如此。

FAQ

提示必須重複使用幾次，快取才划算？

在 5 分鐘快取中，使用 1 次就划算。寫入成本是基礎輸入成本的 1.25 倍，讀取成本是 0.1 倍。因此，N 次未快取請求的成本為 N，而 N 次已快取請求的成本為 1.25 加上 0.1 乘以 N 減 1。兩者在 N = 1.28 時相等，因此第 2 次請求就已經較划算。1 小時快取的寫入成本為 2 倍，並在 N = 2.11 時達到損益平衡，因此需要 2 次讀取。

為什麼 cache_read_input_tokens 始終是 0？

先檢查前綴長度：截至 August 2026，若低於模型最低長度，Claude Opus 5 的最低長度為 512 tokens，Claude Haiku 4.5 的最低長度為 4,096 tokens，系統會靜默略過快取，兩個計數器都會顯示 0。如果前綴長度足夠，請檢查斷點所在位置或之前是否有每次呼叫都會變動的內容，例如 system prompt 中的時間戳記或工作階段識別碼。如果計數器原本正常，後來停止增加，表示請求之間的間隔超過了快取存留時間。

Prompt caching 會改變 Claude 的回答嗎？

不會。快取儲存的是您已傳送之 tokens 的處理後形式，模型看到的 prompt 並未改變。這是計費與延遲功能，不會改變模型行為。因此，您可以在現有 prompt 上啟用此功能，而不必重新執行評估。

我應該付費使用 1 小時快取嗎？

只有在您的流量間隔會超過 5 分鐘，且命中率仍可達到約 53% 以上時，才值得使用。未命中時，2 倍的寫入成本是不使用 1.25 倍寫入時的 2 倍代價。5 分鐘快取項目會在每次命中時重新整理，因此穩定的流量可用讀取價格維持快取，而不必支付較長存留時間的成本。