Claude Fable 5 のキャッシュ：契約は同じでも請求額は Opus 4.6 の 2.9 倍

claude-fable-5 が Synthorai gateway で利用可能になりました。Claude 系でキャッシュを使っている場合、キャッシュと TTL の契約はそのまま引き継がれます。cache_control marker、5 分と 1 時間の TTL、書き込み時の割増率、キャッシュ読み取り時の大幅な割引はすべて同じです。キャッシュ処理側は文字列を 1 つ変更するだけで移行できます。

予算に影響するのはキャッシュの仕組みではなく、請求額です。Fable 5 の token 単価は Opus の 2 倍 です。さらに、同じ英文でも Opus 4.6 より 約 45% 多く token 化 されます。Fable 5 は 4.6 より後の tokenizer を採用しており、Opus 4.8 と同じです。この 2 つの倍率が掛け合わされます。本記事では、その影響をすべて実測しました。

移行前に確認すべきキャッシュ以外の制約が 1 つあります。Fable 5 は zero data retention では実行できません。提供されるすべての cloud で 30 日間のデータ保持が必須です。

TL;DR

• Claude Fable 5 でも Anthropic のキャッシュ契約は変わりません。cache_control marker、5 分と 1 時間の TTL、約 1.25x/2x の書き込み割増、実測でキャッシュなし価格の約 6% となる warm read はすべて同じです。
• 同じテキストは、Fable 5 と Opus 4.8 では 9,619 token、Opus 4.6 では 6,614 token になります。45% 増です。
• Fable 5 の定価は input が $10/M、output が $50/M で、Opus tier の 2 倍です。
• したがって、同じ prompt のコストは Opus 4.6 の 2.9 倍になります（1.45 token x 2.0 price）。2026-06-10 の実測値です。

以下の数値はすべて、2026-06-10 に https://synthorai.io/ の Anthropic-native /v1/messages で測定しました。約 6.6～9.6K token の固定された英文 system prompt を使い、max_tokens は小さく設定し、1 回ずつ順番に実行しています。コストは gateway の usage.cost field から取得しました。token 数、書き込み割増、読み取り割引、model 間のコストといった 比率 には汎用性がありますが、絶対額は prompt に応じて変わります。数値を引用する前に、自分の prompt でも再現してください。

利用方法

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 は 1M-token のコンテキストウィンドウを持つ Anthropic-native model です。動作上の注意点が 1 つあります。Fable 5 は reasoning model であり、デフォルトで thinking token を出力します。単純な「reply OK」という指示でも、実行結果では output_tokens_details.thinking_tokens > 0 になりました。Opus 4.6/4.8 では 0 でした。output token の予算にはこの差も含めてください。cache_control の仕組みは キャッシュのチュートリアル で説明しています。キャッシュが存在する理由を含むアーキテクチャについては、シリーズ第 1 回 を参照してください。

要点：Fable 5 は新しい tokenizer を採用

Opus 系では 4.7 世代で token 数が増えました。同じ英文でも、4.6 では約 6.6K token だったものが、4.8 では約 9.6K token になります。Fable 5 は新しい tokenizer 側です。同じテキストを入力すると、Opus 4.8 と完全に同じ token 数が報告されます。

同じ system prompt でも、Fable 5 では Opus 4.6 より 約 45% 多い token 数 になります（9,619 / 6,614 = 1.45）。移行前に最も重視すべき数値です。コスト、キャッシュ対象になる最低 1,024 token という条件、call 単位の予算など、後続の数値はすべて token 数を基準に計算されるためです。

ここで説明しているのは実測結果です。同じテキストの token 数は Fable 5 と Opus 4.8 で一致し、Opus 4.6 より約 45% 多くなりました。これは 4.7 世代で導入された tokenizer と vocabulary の更新によるものと考えるのが最も自然です。4.6 以前から移行する場合は再測定してください。4.7/4.8 からの移行なら、同等になると見込めます。

キャッシュの動作：契約は変更なし

各 model で、キャッシュなし、cold write、warm read の順に同じテストを実行しました。割引の仕組みは最初から最後まで同じです。Fable 5 は cache_control に対応し、同じ usage field（cache_creation_input_tokens、cache_read_input_tokens、ephemeral_5m / ephemeral_1h bucket）を返します。

3 つの model すべてで、次の 2 点は変わりません。

• 書き込み割増 ≈ 1.25x（5m）、≈ 2x（1h）。 5 分の cache entry を作成する最初の cold call は、キャッシュなし価格の約 1.25x です。1 時間なら約 2x になります。1 回 cache hit すれば元が取れます。
• 読み取り割引 ≈ 90% 以上。 Fable 5 の warm cache read はキャッシュなし call の約 6% で、約 94% の割引でした。Anthropic が公開している約 90% の cached-read 料金と同等か、それよりわずかに有利です。TTL に関係なく、読み取りには大幅な割引が適用されます。

割合は model 間でほぼ一定です。Opus 4.7 から 4.8 への移行と同様、Fable 5 の 絶対的な 請求額が増える理由は、キャッシュ料金の仕組みではなく、価格と token 数です。次の section で説明します。

TTL の動作：両方の期間に対応

Fable 5 は他の model と同じ 2 種類の TTL に対応しています。デフォルトは sliding 方式の 5 分で、明示的に指定すれば 1 時間も利用できます。call ごとに一意の prefix を使って各 TTL を個別に検証し、古い entry が結果に混入しないようにしました。usage object が正しい bucket、つまり 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 で live chat に 5m、人間の確認待ちが入る agent に 1h を選んでいたなら、Fable 5 でもそのまま使えます。

コスト：2x の価格 x 1.45x の token 数

Fable 5 が実際に異なるのはここです。請求額を押し上げる要因が 2 つあり、両者は掛け合わされます。

1. 定価は Opus tier の 2x です。

2. 同じテキストでも 4.6 より token 数が約 45% 増えます（前述の tokenizer 変更によるものです）。

この 2 つを掛け合わせると、同じ英文 prompt のコストは大きく増えます。各 model に同じ system prompt を渡して測定した結果は次のとおりです。gateway の usage.cost を使い、それぞれ同じ条件で 1 回実行しています。

Opus 4.8 との比較では tokenizer が同じなので、Fable 5 は単純に 2x です。価格差だけが反映されます。Opus 4.6 と比べると、tokenizer の変更と価格差が重なり、同じ prompt のコストは約 2.9x になります。キャッシュの 割引率 は変わりませんが、割引前の絶対額は 4.6 の約 2.9x です。4.6 を基準に call 単位の予算を決めていた場合は、計算し直してください。

実務上は、キャッシュ対象になる最低 1,024 token という条件も再確認してください。 Anthropic がキャッシュするのは、prefix が最低サイズ以上の場合だけです。4.6 の古い tokenizer では最低値をわずかに下回っていた prompt が、Fable 5 では token 数が約 45% 増えることで条件を満たす場合があります。古い token 数を前提にサイズを見積もっていた場合も同様です。実際の tokenizer と一致しない可能性があるローカルの tokenizer で推測せず、live response の cache_creation_input_tokens / cache_read_input_tokens を必ず確認してください。

移行チェックリスト（Opus → Fable 5）

• ✅ キャッシュコードはそのまま使えます。 cache_control marker、breakpoint 数（最大 4）、ttl: "1h"、usage field 名はすべて同じです。
• ✅ TTL の選択もそのまま使えます。 live/session workload には 5m、断続的に実行される agent や待機を挟む agent には 1h が適しています。
• ✅ 割引の仕組みも変わりません。 read は約 90% 以上の割引、write は約 1.25x（5m）、約 2x（1h）です。
• ⚠️ 絶対コストを基準に予算を組み直してください。 Fable 5 は token 単価が Opus の約 2x で、同じ prompt のコストは Opus 4.6 の約 2.9x です。割引率は同じでも、割引対象となる元の金額は異なります。
• ⚠️ 4.6 以前から移行する場合は、token 数を再測定してください。同じテキストで約 45% 増える見込みです。4.7/4.8 からなら同等と見込めます。
• ⚠️ デフォルトの thinking token をコストに含めてください。 Fable 5 はデフォルトで reasoning token を出力し、output rate（$50/M）で課金されます。不要なら thinking を制限または無効化してください。

まとめ

Claude で既にキャッシュを使っているチームにとって、claude-fable-5 の integration は簡単です。キャッシュと TTL の interface はすべて維持されているため、新しく覚えることも、書き直すコードもありません。ただし、Opus 4.6 からの 予算上の 置き換えは簡単ではありません。token 単価が 2x になり、tokenizer の変更で token 数も約 45% 増えるため、同じ prompt のコストは約 2.9x になります。live の usage object で数値を確認し、デフォルトの thinking token が必要か判断したうえで、新しい token 数に合わせて cache breakpoint のサイズを決めてください。

prompt 構造、hit rate の debug、TTL を考慮した pattern を含むキャッシュ運用の全体像は、prompt caching 完全ガイド、シリーズ第 1 回の KV Cache と TTL の仕組み、動作確認済みの Python チュートリアル を参照してください。

FAQ

Fable 5 を使うには cache_control のコードを変更する必要がありますか？ いいえ。marker の構文、breakpoint の上限、TTL option は Opus 系と同じです。model field だけを変更すれば、キャッシュ処理側にほかの変更は不要です。

Fable 5 では cache read の割引率が変わりましたか？ いいえ。warm read はキャッシュなしの input 価格に対して 1 桁台前半の割合で、90% 以上の割引になります。Fable 5 では約 94% の割引を実測しました。Anthropic が公開している cached-read 料金と一致しています。

Fable 5 は 1 時間の TTL に対応していますか？ はい。{"type": "ephemeral", "ttl": "1h"} は Opus とまったく同じように機能します。1 時間の書き込みコストはキャッシュなしの約 2x、5 分では約 1.25x です。どちらも読み取りには大幅な割引が適用されます。

同じ prompt でも、Fable 5 が Opus 4.6 より大幅に高いのはなぜですか？ 2 つの倍率が重なるためです。Fable 5 の token 単価は 2x で、同じ英文でも token 数が約 45% 増えます。4.6 より後の tokenizer を使っているためです。合わせると、同一 prompt のコストは約 2.9x になります。キャッシュの 割引率 は変わりません。

Fable 5 は Opus 4.8 の drop-in replacement ですか？ キャッシュ、TTL、token 数についてはそうです。token 数は同じなので、差分は 2x の価格と、Fable 5 がデフォルトで出力する thinking token です。実施していない capability benchmark は公開していません。品質と reasoning に関する主張は、Anthropic の model card を参照してください。

検証情報：token 数、コスト、書き込み割増、読み取り割引はすべて、2026-06-10 に https://synthorai.io/ で公式 anthropic SDK を使い、single tenant で 1 回ずつ順番に実行して測定しました。コストは gateway の usage.cost field から取得しています。model 間の比率と割増率／割引率は、その実測コストから算出しており、account 単位の promotion には依存しません。割引率と割増率は Anthropic の Prompt Caching ドキュメント と照合しました。今回の warm-read latency（TTFT）は network jitter の影響が大きく、信頼できないため掲載していません。数値は prompt、region、load によって変わります。

← ブログに戻る