Synthorai で使う Claude Opus 4.8：キャッシュと TTL を 4.7／4.6 と比較

claude-opus-4-8 が Synthorai gateway で利用できるようになりました。すでに Opus 系で prompt cache を運用しているなら、結論は安心できる一方で目新しさはありません。キャッシュと TTL の仕様は 4.7／4.6 から何も変わっていません。 cache_control marker、5 分と 1 時間の TTL、読み取り時の割引、書き込み時の割増率はすべて同じです。既存のキャッシュ処理をそのまま使えます。

変わった点は 1 つだけです。ただし変更されたのは 4.8 ではなく 4.7 で、token budget に影響します。この記事では、その差を実測結果で確認します。

TL;DR

• Claude Opus 4.8 のキャッシュ仕様は 4.7／4.6 と同じです。実測した読み取り割引率は 89%、書き込み時の割増率は 5 分 TTL で約 1.25 倍、1 時間 TTL で約 2 倍でした。
• 同じ system text でも、Opus 4.7／4.8 では 4.5／4.6 より input token が約 43% 多く報告されます。11,394 token に対して 7,976 token です。
• Opus 系の token 単価は共通です。4.8／4.5 のコスト比 1.43 は、token 数の比率 1.429 と一致します。
• warm read の TTFT は Opus 4.5～4.8 のすべてで 2.2～2.8 秒の範囲に収まっています。差は jitter です。

以下の数値はすべて、2026-05-29 に https://synthorai.io/ の Anthropic native /v1/messages で計測しました。約 8K 文字の英語 system prompt を使い、max_tokens を小さく設定した単一の逐次実行です。数値を引用する前に、自分の 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-opus-4-8",            # 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)   # cache_creation_input_tokens, cache_read_input_tokens, cost

claude-opus-4-7 を claude-opus-4-8 に差し替えるだけで、キャッシュ処理のほかの部分は変更不要です。cache_control の仕組みはキャッシュのチュートリアルで説明しています。キャッシュが必要な理由とアーキテクチャについては、シリーズ第 1 回を参照してください。

キャッシュの挙動：4.7／4.6 から変更なし

最近の Opus 系に対し、同じ順序で cache write、cache read、no-cache を実行しました。割引の仕組みはすべてのバージョンで同じです。

4 つのバージョンすべてで、次の 2 点が共通しています。

• 読み取り割引率は約 89% です。 warm cache からの読み取りコストは、no-cache の input 価格の約 11% です。Anthropic が公表している cached read 率の 10% と一致しており、変更はありません。
• 書き込み時の割増率は約 25% です。 キャッシュを作成する最初の cold call は、no-cache 価格の約 1.25 倍です。1 回 hit すれば元が取れます。

4.7 と 4.8 の金額は 4.5／4.6 より高くなっています。ただし後述するように、これは token 数の違いによるものであり、キャッシュの料金体系が変わったわけではありません。割引率は一定です。

TTL の挙動：4.7／4.6 から変更なし

Opus 4.8 で使える TTL は、ほかの Opus 系と同じ 2 種類です。デフォルトは sliding 方式の 5 分で、明示的に指定すれば 1 時間にできます。古い cache entry が結果に影響しないよう call ごとに一意の prefix を使い、各 TTL の書き込み時の割増率を計測しました。

# 1-hour TTL — same marker syntax on 4.8 as on 4.7/4.6
"cache_control": {"type": "ephemeral", "ttl": "1h"}

usage object が返す TTL bucket も従来どおりで、cache_creation.ephemeral_5m_input_tokens または ephemeral_1h_input_tokens です。1 時間 TTL の書き込みコストは no-cache の約 2 倍で、5 分 TTL では約 1.25 倍です。読み取りコストは TTL に関係なく約 11% のままです。4.7 と違いはありません。4.7 で live chat に 5m、human-in-the-loop による中断がある agent に 1h を選んでいたなら、4.8 でも同じ設定を使えます。

Time-to-first-token：全バージョンで同水準

streaming call を使い、warm read の TTFT を計測しました。gateway の warm-up 後に model ごとに 5 回実行し、中央値を記載しています。この約 8～11K token の prompt では、TTFT は約 2.2～2.8 秒の範囲です。バージョンごとの明確な傾向はありません。計測範囲が重なっているため、差はバージョンによるものではなく jitter です。

注意点は 2 つあります。

• この結果から性能順位を付けることはできません。 計測範囲は大きく重なっています。4.8 の最大値 4.38 秒は外れ値でした。この規模の prompt では、TTFT は model version よりもネットワークや queueing の jitter に強く左右されます。4 つの model すべてで、warm 時の目安は約 2.2～2.8 秒と考えてください。
• キャッシュによる TTFT の短縮幅は prompt が長いほど大きくなります。 約 8～11K token では、cache hit によって省略できる prefill が少ないため、cold と warm の TTFT はほぼ同じです。warm-up 済みの gateway では、どちらも約 2～3 秒でした。100K token を超えると prefill が支配的になり、差が大きくなります。この条件では、warm cache によって最初の token まで数秒かかる処理を大幅に短縮できます。詳しい仕組みは第 1 回：KV Cache と TTL の仕組みで説明しています。

実際に変わった点：tokenization（4.7 以降）

移行前に再確認すべき点があります。同じ system text でも、4.7／4.8 では 4.5／4.6 より input token が約 43% 多く報告されます。

token 数は 4.7 世代で増え、その傾向が 4.8 にも引き継がれています。コストは token 数にほぼ正確に連動しています。コスト比（4.8／4.5）は 1.43、token 数の比率は 1.429 です。Opus 系全体で token 単価は同じです。 4.7／4.8 の料金が高いのは、同じ text がより多くの token として数えられるためです。

実運用では、次の 2 点に影響します。

1. 割引率ではなく絶対額で予算を見直してください。 キャッシュの割引率は約 89% のままですが、同じ英語 prompt の絶対コストは 4.7／4.8 で 4.6 より約 43% 高くなります。4.6 の token 数を基準に call 単位の予算を設定している場合、実際のコストと合わなくなります。
2. キャッシュ対象となる最小値 1,024 token を再確認してください。 Anthropic でキャッシュできるのは、prefix が最小サイズ以上の場合だけです。4.6 で最小値をわずかに下回っていた prompt が、token 数の増加によって 4.7／4.8 では対象になる可能性があります。旧 tokenizer の token 数を基準に調整した prompt も再計測が必要です。一致しない可能性がある local tokenizer で推定せず、live response の cache_creation_input_tokens／cache_read_input_tokens を必ず確認してください。

ここで示しているのは実測結果です。同じ text でも、4.7／4.8 では報告される input token が約 43% 増えました。4.7 世代で tokenizer または vocabulary が更新されたと考えるのが最も自然です。原因が何であっても対応は変わりません。キャッシュ料金は token 数を基準に計算されるため、移行時には token 数を再計測してください。

移行チェックリスト（4.6／4.7 → 4.8）

• ✅ キャッシュ処理はそのまま引き継げます。 cache_control marker、breakpoint 数の上限 4、ttl: "1h"、usage field 名はすべて同じです。
• ✅ TTL の選択もそのままです。 live／session workload には 5m、断続的に処理する agent や中断を伴う agent には 1h を使います。
• ✅ 割引と割増の仕組みも変わりません。 読み取りは約 89% 割引、書き込みは 5m で約 1.25 倍、1h で約 2 倍です。
• ⚠️ token 数を再計測してください。 4.5／4.6 から移行する場合、同じ text でも input token が 40% 以上増えると見込んでください。この変更は 4.7 で発生しています。4.7 から移行する場合は同水準です。
• ⚠️ コスト dashboard を再検証してください。 旧世代の見積もりをキャッシュした値ではなく、live response の usage.cost と *_input_tokens field を使ってください。

まとめ

すでに Opus で prompt cache を運用しているチームにとって、claude-opus-4-8 への upgrade は簡単です。キャッシュと TTL に関する仕様はすべて安定しており、新たに覚えることもコードを書き直す必要もありません。4.6 以前から移行する場合は tokenizer の変更を予算に反映し、live の usage object で数値を確認したうえでリリースしてください。

prompt の構成、hit rate のデバッグ、TTL を考慮した pattern まで含むキャッシュ運用の詳細は、KV Cache と TTL の仕組みから始まる prompt cache シリーズと、実行可能な Python チュートリアルを参照してください。

FAQ

Opus 4.8 を使うために cache_control のコードを変更する必要はありますか？ ありません。marker の構文、breakpoint の上限、TTL の選択肢は 4.7／4.6 と同じです。model field だけを変更してください。

4.8 で cache read の割引率は変わりましたか？ 変わっていません。4.5～4.8 のすべてで、warm read は no-cache の input 価格の約 11%、つまり約 89% 割引です。Anthropic が公表している料率とも一致します。

1 時間 TTL の割増率は変わりましたか？ 変わっていません。1 時間 TTL の書き込みは no-cache の input 価格の約 2 倍、5 分 TTL では約 1.25 倍です。読み取りは TTL に関係なく約 11% です。4.7 と同じです。

同じ prompt なのに、4.8 では 4.6 より高くなるのはなぜですか？ token 単価は同じですが、prompt の token 数が増えるためです。実測では、同じ text が 4.5／4.6 で約 8.0K token、4.7／4.8 では約 11.4K token と報告されました。約 43% の増加です。4.7 世代で tokenizer が変更されたと考えるのが最も自然です。キャッシュの割引率は変わっていません。

4.8 は 4.7 の drop-in replacement ですか？ キャッシュと TTL に関しては、そのまま置き換えられます。token 数と料金体系は 4.7 の時点ですでに現在と同じため、4.7 からの移行で差はありません。実施していない capability benchmark は公開していません。品質や reasoning に関する情報は Anthropic の model card を参照してください。

検証情報：キャッシュ、TTL、token 数、コスト、TTFT の全数値は、2026-05-29 に公式 anthropic SDK を使い、single tenant で https://synthorai.io/ に対して計測しました。コストと token の数値は単一の逐次実行、TTFT は gateway の warm-up 後に model ごとに 5 回計測した中央値です。割引率と割増率は、Anthropic の Prompt Caching ドキュメントと照合しています。実際の数値は prompt、region、load によって変動します。

← ブログに戻る