Claude Fable 5 快取：相同機制，帳單卻是 Opus 4.6 的 2.9 倍

claude-fable-5 現已可透過 Synthorai 閘道使用。如果你已在 Claude 系列使用快取，好消息是快取與 TTL 機制完全沿用：相同的 cache_control 標記、相同的 5 分鐘與 1 小時 TTL、相同的寫入加價，以及相同的大幅讀取折扣。快取程式碼只要改一個字串即可切換。

需要重新編列的是預算，不是快取機制。Fable 5 的權杖牌價是 Opus 的 2 倍，而相同英文文字經過權杖化後，權杖數會比 Opus 4.6 多約 45%（它使用 4.6 之後的 tokenizer，與 Opus 4.8 相同）。這兩個倍數會疊加。本文已實測所有相關數據，方便你直接評估。

遷移前還要確認一項與快取無關的限制：Fable 5 無法在零資料保留模式下執行。所有提供 Fable 5 的雲端都強制保留資料 30 天。

TL;DR

• Claude Fable 5 完整沿用 Anthropic 的快取機制：相同的 cache_control 標記、5 分鐘與 1 小時 TTL、約 1.25x/2x 的寫入加價；實測暖快取讀取成本約為未使用快取時的 6%。
• 相同文字在 Fable 5 與 Opus 4.8 上會產生 9,619 個權杖，Opus 4.6 則是 6,614 個，多出 45%。
• Fable 5 的輸入牌價為 $10/M，輸出為 $50/M，是 Opus 級別的 2 倍。
• 因此，相同提示詞的成本是 Opus 4.6 的 2.9 倍（1.45 權杖數 x 2.0 價格），實測日期為 2026-06-10。

以下所有數據均於 2026-06-10 透過 https://synthorai.io/（Anthropic 原生 /v1/messages）實測。測試使用固定且約含 6.6–9.6K 個權杖的英文 system prompt、較小的 max_tokens，並依序單次執行。成本數據取自閘道回傳的 usage.cost 欄位；可套用到其他情境的是各項比例（權杖數、寫入加價、讀取折扣、跨模型成本），絕對金額則會隨提示詞大小變動。引用這些數據前，請用自己的提示詞重跑一次。

可用性

import os
from anthropic import Anthropic

anth = Anthropic(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/",   # SDK appends /v1/messages
)

msg = anth.messages.create(
    model="claude-fable-5",             # the only line that changes
    max_tokens=512,
    system=[
        {"type": "text", "text": SYSTEM_PROMPT,
         "cache_control": {"type": "ephemeral"}},
    ],
    messages=[{"role": "user", "content": question}],
)
print(msg.usage)   # input_tokens, cache_creation_input_tokens, cache_read_input_tokens, cost

將 claude-opus-4-6 換成 claude-fable-5，快取路徑的其他部分都不必修改。Fable 5 是 Anthropic 原生模型，context window 為 1M 個權杖。行為上有一點需要留意：它是 reasoning model，且預設會產生 thinking tokens。在我們的測試中，即使只要求「reply OK」，回傳的 output_tokens_details.thinking_tokens > 0；Opus 4.6/4.8 則為零。因此，輸出權杖的預算也要納入這項成本。cache_control 的運作方式可參考快取教學；若要了解快取存在的架構原因，請閱讀本系列第 1 篇。

重點：Fable 5 採用新版 tokenizer

Opus 系列從 4.7 世代開始，權杖數明顯增加：同一段英文文字在 4.6 約為 6.6K 個權杖，到 4.8 則約為 9.6K。Fable 5 採用新版 tokenizer，相同文字回報的權杖數與 Opus 4.8 完全一致。

相同的 system prompt 在 Fable 5 上，權杖數會比 Opus 4.6 多約 45%（9,619 / 6,614 = 1.45）。遷移前最需要掌握的就是這個數字，因為後續所有數據，包括成本、1,024 個權杖的快取最低門檻，以及每次呼叫的預算，都是按權杖計算。

這裡描述的是實測結果：相同文字在 Fable 5 與 Opus 4.8 上的權杖數完全一致，並且比 Opus 4.6 多約 45%。這最符合 4.7 世代推出的 tokenizer／詞彙表更新。如果目前使用 4.6 或更早版本，請重新測量；若使用 4.7/4.8，權杖數應會相同。

快取行為：機制不變

我們在各模型上執行了相同的未使用快取／冷快取寫入／暖快取讀取流程。從頭到尾的折扣結構完全一致。Fable 5 支援 cache_control，回報的 usage 欄位也相同，包括 cache_creation_input_tokens、cache_read_input_tokens，以及 ephemeral_5m／ephemeral_1h 分類。

三個模型都符合以下兩項固定規則：

• 寫入加價 ≈ 1.25x（5m）、≈ 2x（1h）。 第一次冷快取呼叫若建立 5 分鐘項目，成本約為未使用快取時的 1.25x；建立 1 小時項目則約為 2x。只要命中一次就能回本。
• 讀取折扣 ≈ 90% 以上。 Fable 5 的暖快取讀取成本約為未使用快取呼叫的 6%，相當於約 94% 的折扣，與 Anthropic 文件中約 90% 的快取讀取成本相符，甚至稍微更低。無論 TTL 多長，讀取成本都維持大幅折扣。

整個系列的百分比差異不大。就像 Opus 4.7 → 4.8 的變化一樣，Fable 5 的絕對帳單較高，原因是牌價與權杖數，而不是快取的成本模型。下一節會詳細說明。

TTL 行為：兩種期限都有效

Fable 5 與系列中其他模型一樣，支援兩種 TTL：預設為可滑動續期的 5 分鐘，也可選擇 1 小時。為避免舊快取項目干擾結果，我們在每次呼叫中使用唯一前綴，分別測試兩種 TTL，並確認 usage 物件會回報正確分類：cache_creation.ephemeral_5m_input_tokens 或 ephemeral_1h_input_tokens。

# 1-hour TTL — same marker syntax on Fable 5 as on the Opus line
"cache_control": {"type": "ephemeral", "ttl": "1h"}

1 小時快取的寫入成本約為未使用快取時的 2x，5 分鐘快取則約為 1.25x。無論 TTL 為何，讀取都維持大幅折扣，與 Opus 4.6/4.8 完全相同。如果你原本在 Opus 上為即時聊天選用 5m，為可能等待人工介入的 agent 選用 1h，切換到 Fable 5 後可維持原設定。

成本重點：2x 牌價 x 1.45x 權杖數

Fable 5 真正不同的地方在成本。有兩個因素會推高帳單，而且兩者會相乘。

1. 牌價是 Opus 級別的 2x。

2. 相同文字產生的權杖數比 4.6 多約 45%（原因是上述 tokenizer 變更）。

兩者相乘後，相同英文提示詞的成本會大幅上升。我們在各模型上使用完全相同的 system prompt，並透過閘道的 usage.cost 進行相同的單次測試，結果如下：

相較於使用相同 tokenizer 的 Opus 4.8，Fable 5 正好是 2x，差異純粹來自牌價。相較於 Opus 4.6，tokenizer 變更與價格調整疊加後，相同提示詞的成本約為 2.9x。快取的折扣比例沒有改變，但套用折扣前的絕對基數已是 4.6 的約 2.9x。如果每次呼叫的預算是以 4.6 為基準，請重新估算。

另一個實務影響是：重新確認 1,024 個權杖的快取最低門檻。 Anthropic 只會快取達到最低大小的前綴。某個提示詞以 4.6 的舊 tokenizer 計算時，可能略低於門檻；換到 Fable 5 後，由於權杖數增加約 45%，可能就會超過門檻。反過來說，沿用舊權杖數所做的大小估算也可能失準。請直接讀取即時回應中的 cache_creation_input_tokens／cache_read_input_tokens，不要依賴可能與伺服器版本不同的本機 tokenizer 估算。

遷移檢查清單（Opus → Fable 5）

• ✅ 快取程式碼可原封不動沿用。 cache_control 標記、最多 4 個 breakpoint、ttl: "1h"、usage 欄位名稱，全都相同。
• ✅ TTL 選擇可以沿用。 即時／session 工作負載使用 5m；間歇執行或可能暫停的 agent 使用 1h。
• ✅ 折扣成本模型可以沿用。 讀取折扣約 90% 以上；5m 寫入約 1.25x，1h 寫入約 2x。
• ⚠️ 按絕對成本重新編列預算。 Fable 5 每個權杖的價格約為 Opus 的 2x，相同提示詞相較 Opus 4.6 則約為 2.9x。折扣比例沒變，但套用折扣的基數已經不同。
• ⚠️ 如果從 4.6 或更早版本遷移，請重新測量權杖數，相同文字預期會增加約 45%。從 4.7/4.8 遷移則應相同。
• ⚠️ 將預設的 thinking tokens 納入成本。 Fable 5 預設會產生 reasoning tokens，並按輸出費率（$50/M）計費。如果不需要，請限制或停用 thinking。

結論

對已在 Claude 上使用快取的團隊來說，整合 claude-fable-5 很容易：整套快取與 TTL 介面維持不變，不必重新學習，也不用重寫程式碼。但若要從 Opus 4.6 切換，預算就不能直接照搬。權杖牌價提高 2x，再加上 tokenizer 使權杖數增加約 45%，相同提示詞的成本約為原本的 2.9x。請透過即時回傳的 usage 物件確認數據、判斷是否需要預設的 thinking tokens，並按新的權杖數設定快取 breakpoint。

完整的快取實作指南，包括提示詞結構、命中率除錯與考量 TTL 的設計模式，可參考完整提示詞快取指南、系列首篇 KV Cache 與 TTL 如何運作，以及可直接執行的 Python 教學。

常見問題

使用 Fable 5 時，需要修改 cache_control 程式碼嗎？ 不需要。標記語法、breakpoint 數量上限與 TTL 選項都和 Opus 系列相同。只要變更 model 欄位，快取路徑的其他部分無須調整。

Fable 5 的快取讀取折扣有變嗎？ 沒有。暖快取讀取只占未使用快取時輸入價格的低個位數百分比，折扣約為 90% 以上。我們在 Fable 5 上實測約為 94%，與 Anthropic 文件中的快取讀取成本模型一致。

Fable 5 支援 1 小時 TTL 嗎？ 支援。{"type": "ephemeral", "ttl": "1h"} 的運作方式與 Opus 完全相同。1 小時快取的寫入成本約為未使用快取時的 2x，5 分鐘則約為 1.25x。兩者的讀取都維持大幅折扣。

為什麼相同提示詞在 Fable 5 上的成本比 Opus 4.6 高這麼多？ 因為兩個倍數會疊加：Fable 5 的每權杖牌價是 2x，而相同英文文字會產生約多 45% 的權杖（使用 4.6 之後的 tokenizer）。兩者合計後，相同提示詞的成本約為 2.9x。快取的折扣比例沒有改變。

Fable 5 可以直接取代 Opus 4.8 嗎？ 就快取／TTL 介面與權杖數而言，可以。兩者權杖數完全相同，因此差異只有 2x 的價格，以及 Fable 5 預設產生的 thinking tokens。我們不會發布未實際執行過的能力 benchmark；品質與 reasoning 能力請參閱 Anthropic 的 model card。

驗證方式：所有權杖數、成本、寫入加價與讀取折扣數據，均於 2026-06-10 使用官方 anthropic SDK，透過 https://synthorai.io/ 實測；測試採單一 tenant，依序單次執行。成本取自閘道的 usage.cost 欄位；跨模型比例及加價／折扣比例均由實測成本計算，不受任何帳戶層級促銷影響。折扣／加價比例另與 Anthropic 提示詞快取文件交叉核對。本次測試的暖快取讀取延遲（TTFT）主要受網路抖動影響，可信度不足，因此未列入。實際數據會隨提示詞、區域與負載而異。

← 返回部落格