Claude Fable 5 Caching: gleicher Vertrag, 2,9-fache Kosten gegenüber Opus 4.6

claude-fable-5 ist jetzt über das Synthorai-Gateway verfügbar. Wer bei Claude Prompt Caching nutzt, kann die bestehende Implementierung übernehmen: dieselben cache_control-Marker, dieselben TTLs von 5 Minuten und 1 Stunde, dieselben Aufschläge für Schreibvorgänge und derselbe hohe Rabatt bei Lesezugriffen. Im Code muss nur ein String geändert werden.

Planen muss man allerdings die Kosten. Fable 5 kostet pro Token doppelt so viel wie Opus und erzeugt aus demselben englischen Text rund 45 % mehr Tokens als Opus 4.6. Es verwendet den Tokenizer ab Version 4.7, der mit dem von Opus 4.8 identisch ist. Beide Faktoren multiplizieren sich. Dieser Beitrag liefert die Messwerte dazu.

Vor der Migration gibt es noch eine Einschränkung außerhalb des Cachings zu prüfen: Fable 5 kann nicht ohne Datenspeicherung betrieben werden. In jeder verfügbaren Cloud gilt eine verpflichtende Datenspeicherung von 30 Tagen.

TL;DR

• Claude Fable 5 übernimmt Anthrophics Caching-Vertrag unverändert: dieselben cache_control-Marker, TTLs von 5 Minuten und 1 Stunde, Aufschläge von etwa 1,25x beziehungsweise 2x für Schreibvorgänge und gemessene Kosten eines warmen Lesezugriffs von etwa 6 % des Preises ohne Cache.
• Derselbe Text ergibt bei Fable 5 und Opus 4.8 jeweils 9,619 Tokens, gegenüber 6,614 bei Opus 4.6: 45 % mehr.
• Der Listenpreis von Fable 5 beträgt $10/M für Input und $50/M für Output, also das Doppelte der Opus-Klasse.
• Derselbe Prompt kostet damit 2,9x so viel wie bei Opus 4.6 (1,45 Tokens x 2,0 Preis), gemessen am 2026-06-10.

Alle folgenden Werte wurden am 2026-06-10 gegen https://synthorai.io/ über den Anthropic-nativen Endpoint /v1/messages gemessen. Verwendet wurden ein stabiler englischer System-Prompt mit rund 6,6–9,6K Tokens, ein kleiner Wert für max_tokens und ein einzelner sequenzieller Durchlauf. Die Kosten stammen aus dem Gateway-Feld usage.cost. Übertragbar sind vor allem die Verhältnisse bei Token-Anzahl, Schreibaufschlag, Leserabatt und modellübergreifenden Kosten. Die absoluten Beträge skalieren mit dem Prompt. Vor der Weitergabe sollten die Werte mit dem eigenen Prompt reproduziert werden.

Verfügbarkeit

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

Nach dem Wechsel von claude-opus-4-6 zu claude-fable-5 bleibt der gesamte Caching-Pfad unverändert. Fable 5 ist ein Anthropic-natives Modell mit einem Kontextfenster von 1M Tokens. Beim Verhalten gibt es einen Unterschied: Als Reasoning-Modell erzeugt es standardmäßig Thinking-Tokens. Selbst bei der trivialen Anweisung „reply OK“ war in unseren Durchläufen output_tokens_details.thinking_tokens > 0, während Opus 4.6/4.8 null meldete. Das muss im Budget für Output-Tokens berücksichtigt werden. Wie cache_control funktioniert, erklärt das Caching-Tutorial. Die Architektur und der Zweck des Caches werden in Teil 1 der Serie behandelt.

Die wichtigste Änderung: Fable 5 verwendet den neuen Tokenizer

In der Opus-Reihe stieg die Token-Anzahl mit Generation 4.7 deutlich an: Derselbe englische Text, der bei 4.6 rund 6,6K Tokens ergab, kommt bei 4.8 auf rund 9,6K. Fable 5 verwendet ebenfalls den neuen Tokenizer. Bei identischem Text meldet es exakt dieselbe Token-Anzahl wie Opus 4.8.

Derselbe System-Prompt hat bei Fable 5 rund 45 % mehr Tokens als bei Opus 4.6 (9,619 / 6,614 = 1,45). Das ist vor einer Migration die wichtigste Kennzahl. Alle weiteren Größen werden in Tokens berechnet: Kosten, die Mindestgröße von 1,024 Tokens für die Cache-Nutzung und das Budget pro Request.

Hier geht es um eine Messung: Identischer Text ergibt bei Fable 5 und Opus 4.8 dieselbe Token-Anzahl und liegt rund 45 % über Opus 4.6. Das passt am besten zur Aktualisierung von Tokenizer und Vokabular, die mit Generation 4.7 eingeführt wurde. Bei einer Migration von 4.6 oder älter sollten die Werte neu gemessen werden. Von 4.7/4.8 ist mit identischen Token-Anzahlen zu rechnen.

Caching-Verhalten: Der Vertrag bleibt unverändert

Für jedes Modell haben wir dieselbe Abfolge aus Request ohne Cache, kaltem Schreibzugriff und warmem Lesezugriff ausgeführt. Die Rabattstruktur ist durchgängig identisch. Fable 5 berücksichtigt cache_control und liefert dieselben Usage-Felder (cache_creation_input_tokens, cache_read_input_tokens sowie die Buckets ephemeral_5m und ephemeral_1h).

Bei allen drei Modellen gelten zwei Konstanten:

• Schreibaufschlag ≈ 1,25x (5m), ≈ 2x (1h). Der erste kalte Request kostet beim Anlegen eines Eintrags mit 5 Minuten TTL rund 1,25x so viel wie ohne Cache. Bei 1 Stunde TTL sind es rund 2x. Ab einem Cache-Treffer rechnet sich der Eintrag.
• Leserabatt ≈ 90 %+. Ein warmer Cache-Lesezugriff kostete bei Fable 5 rund 6 % eines Requests ohne Cache. Das entspricht etwa 94 % Rabatt und liegt damit im Bereich der von Anthropic dokumentierten Cache-Konditionen, sogar leicht darüber. Lesezugriffe bleiben unabhängig von der TTL stark vergünstigt.

Die prozentualen Werte sind über die gesamte Modellreihe hinweg stabil. Wie beim Wechsel von Opus 4.7 auf 4.8 entstehen die höheren absoluten Kosten bei Fable 5 durch Preis und Token-Anzahl, nicht durch andere Cache-Konditionen. Darum geht es im nächsten Abschnitt.

TTL-Verhalten: Beide Zeitfenster funktionieren

Fable 5 unterstützt dieselben beiden TTLs wie die übrige Modellreihe: standardmäßig ein gleitendes Zeitfenster von 5 Minuten und optional 1 Stunde. Wir haben jede TTL mit einem eindeutigen Präfix pro Request isoliert, damit kein alter Eintrag das Ergebnis verfälscht. Das Usage-Objekt meldete jeweils den korrekten Bucket: cache_creation.ephemeral_5m_input_tokens oder ephemeral_1h_input_tokens.

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

Ein Schreibzugriff mit 1 Stunde TTL kostet rund 2x so viel wie ohne Cache, gegenüber rund 1,25x bei 5 Minuten. Lesezugriffe bleiben bei beiden TTLs stark vergünstigt, genau wie bei Opus 4.6/4.8. Wer bei Opus 5m für Live-Chats und 1h für Agents mit Human-in-the-Loop-Pausen verwendet hat, kann diese Auswahl für Fable 5 beibehalten.

Die Kosten: 2x Preis x 1,45x Tokens

Hier unterscheidet sich Fable 5 tatsächlich. Zwei Faktoren treiben die Rechnung nach oben und multiplizieren sich.

1. Der Listenpreis ist doppelt so hoch wie in der Opus-Klasse.

2. Derselbe Text erzeugt rund 45 % mehr Tokens als bei 4.6 (aufgrund des oben beschriebenen Tokenizer-Wechsels).

Zusammen führt das bei demselben englischen Prompt zu deutlich höheren Kosten. Gemessen wurde jeweils derselbe System-Prompt in einem einzelnen Durchlauf pro Modell, anhand von usage.cost des Gateways:

Gegenüber Opus 4.8 mit demselben Tokenizer kostet Fable 5 exakt 2x so viel. Der Unterschied stammt ausschließlich aus dem Preisaufschlag. Gegenüber Opus 4.6 verstärkt der Tokenizer-Wechsel den Preisunterschied auf rund 2,9x für denselben Prompt. Der Cache-Rabatt bleibt unverändert, gilt aber für eine etwa 2,9x höhere Ausgangsbasis als bei 4.6. Ein auf 4.6 basierendes Budget pro Request muss daher neu berechnet werden.

Eine praktische Folge: Die Mindestgröße von 1,024 Tokens für die Cache-Nutzung muss neu geprüft werden. Anthropic speichert nur Präfixe ab einer bestimmten Mindestgröße im Cache. Ein Prompt, der bei 4.6 nach alter Tokenisierung knapp unter der Grenze lag, kann sie bei Fable 5 mit rund 45 % mehr Tokens überschreiten. Umgekehrt stimmen Größenabschätzungen auf Basis der alten Token-Anzahl nicht mehr. Statt Schätzungen mit einem möglicherweise abweichenden lokalen Tokenizer sollten immer cache_creation_input_tokens und cache_read_input_tokens aus der Live-Response verwendet werden.

Checkliste für die Migration (Opus → Fable 5)

• ✅ Der Caching-Code kann unverändert übernommen werden. cache_control-Marker, Anzahl der Breakpoints (bis zu 4), ttl: "1h" und die Namen der Usage-Felder sind identisch.
• ✅ Die TTL-Auswahl bleibt bestehen. 5m für Live- und Session-Workloads, 1h für unregelmäßige Agents oder Agents mit Pausen.
• ✅ Die Cache-Konditionen bleiben bestehen. Mehr als rund 90 % Rabatt beim Lesen, rund 1,25x für Schreibzugriffe bei 5m und rund 2x bei 1h.
• ⚠️ Die absoluten Kosten müssen neu kalkuliert werden. Fable 5 kostet pro Token rund 2x so viel wie Opus und für denselben Prompt rund 2,9x so viel wie Opus 4.6. Der prozentuale Rabatt bleibt gleich, die Berechnungsbasis nicht.
• ⚠️ Bei einer Migration von 4.6 oder älter müssen die Token-Anzahlen neu gemessen werden. Für denselben Text sind rund 45 % mehr zu erwarten. Von 4.7/4.8 ist mit identischen Werten zu rechnen.
• ⚠️ Die standardmäßigen Thinking-Tokens müssen berücksichtigt werden. Fable 5 erzeugt standardmäßig Reasoning-Tokens. Sie werden zum Output-Preis von $50/M abgerechnet. Wenn sie nicht benötigt werden, sollte Thinking begrenzt oder deaktiviert werden.

Fazit

Für Teams, die bereits Prompt Caching mit Claude einsetzen, ist claude-fable-5 einfach zu integrieren: Die gesamte Caching- und TTL-Schnittstelle bleibt stabil. Es gibt nichts neu zu lernen und keinen Code umzuschreiben. Beim Budget ist der Wechsel von Opus 4.6 dagegen erheblich. Durch den doppelten Token-Preis und rund 45 % mehr Tokens kostet derselbe Prompt etwa 2,9x so viel. Die eigenen Werte sollten anhand des Live-Objekts usage geprüft werden. Außerdem ist zu entscheiden, ob die standardmäßigen Thinking-Tokens benötigt werden. Cache-Breakpoints müssen anhand der neuen Token-Anzahlen dimensioniert werden.

Der vollständige Leitfaden zum Prompt Caching behandelt Prompt-Struktur, Fehlersuche bei der Hit-Rate und TTL-spezifische Patterns. Ergänzend gibt es den Auftakt der Serie Funktionsweise von KV Cache und TTL sowie das ausführbare Python-Tutorial.

FAQ

Muss ich meinen cache_control-Code für Fable 5 ändern? Nein. Marker-Syntax, Breakpoint-Limit und TTL-Optionen sind mit der Opus-Reihe identisch. Nur das Feld model muss geändert werden; der restliche Caching-Pfad bleibt unverändert.

Hat sich der Rabatt für Cache-Lesezugriffe bei Fable 5 geändert? Nein. Ein warmer Lesezugriff kostet nur einen kleinen einstelligen Prozentsatz des Input-Preises ohne Cache, also mehr als rund 90 % weniger. Bei Fable 5 haben wir rund 94 % gemessen. Das entspricht den von Anthropic dokumentierten Cache-Konditionen.

Unterstützt Fable 5 die TTL von 1 Stunde? Ja. {"type": "ephemeral", "ttl": "1h"} funktioniert genau wie bei Opus. Der Schreibzugriff mit 1 Stunde TTL kostet rund 2x so viel wie ohne Cache, bei 5 Minuten sind es rund 1,25x. Lesezugriffe bleiben bei beiden stark vergünstigt.

Warum ist derselbe Prompt bei Fable 5 so viel teurer als bei Opus 4.6? Zwei Faktoren multiplizieren sich: Fable 5 kostet pro Token doppelt so viel, und derselbe englische Text ergibt rund 45 % mehr Tokens, weil das Modell den Tokenizer ab Generation 4.7 verwendet. Zusammen kostet ein identischer Prompt etwa 2,9x so viel. Der Cache-Rabatt bleibt unverändert.

Ist Fable 5 ein Drop-in-Ersatz für Opus 4.8? Bei Caching, TTL und Token-Anzahl ja. Die Token-Anzahlen sind identisch. Unterschiede sind der doppelte Preis und die standardmäßigen Thinking-Tokens von Fable 5. Wir veröffentlichen keine nicht selbst durchgeführten Capability-Benchmarks. Aussagen zu Qualität und Reasoning enthält Anthrophics Model Card.

Verifizierung: Alle Werte zu Token-Anzahl, Kosten, Schreibaufschlägen und Leserabatten wurden am 2026-06-10 mit dem offiziellen anthropic SDK gegen https://synthorai.io/ gemessen, mit einem einzelnen Tenant und einem einzelnen sequenziellen Durchlauf. Die Kosten stammen aus dem Gateway-Feld usage.cost. Modellübergreifende Verhältnisse sowie Aufschläge und Rabatte wurden aus diesen Messwerten berechnet und sind unabhängig von möglichen Rabatten auf Account-Ebene. Die Rabatt- und Aufschlagsverhältnisse wurden mit der Anthropic-Dokumentation zum Prompt Caching abgeglichen. Die Latenz warmer Lesezugriffe (TTFT) wurde in unserem Durchlauf vom Netzwerk-Jitter dominiert und wegen mangelnder Aussagekraft nicht angegeben. Die eigenen Werte variieren je nach Prompt, Region und Last.

← Zurück zum Blog