Claude Opus 4.8 auf Synthorai: Caching und TTL im Vergleich zu 4.7/4.6

claude-opus-4-8 ist jetzt über das Synthorai-Gateway verfügbar. Wer für die Opus-Reihe bereits Prompt Caching nutzt, bekommt eine erfreulich unspektakuläre Nachricht: Am Caching- und TTL-Vertrag hat sich gegenüber 4.7 und 4.6 nichts geändert. Dieselben cache_control-Marker, dieselben TTLs von 5 Minuten und 1 Stunde, derselbe Rabatt für Reads und dieselben Aufschläge für Writes. Der vorhandene Caching-Code kann unverändert übernommen werden.

Genau eine Sache hat sich geändert. Die Änderung kam allerdings schon mit 4.7, nicht erst mit 4.8, und wirkt sich auf das Token-Budget aus. Wir haben sie gemessen, damit ihr das nicht selbst tun müsst.

TL;DR

• Claude Opus 4.8 übernimmt den Caching-Vertrag von 4.7/4.6 unverändert: gemessene 89% Rabatt auf Reads, etwa 1.25x Aufschlag für Writes bei einer TTL von 5 Minuten und etwa 2x bei 1 Stunde.
• Derselbe Systemtext wird bei Opus 4.7/4.8 mit etwa 43% mehr Input-Tokens ausgewiesen als bei 4.5/4.6 (11,394 gegenüber 7,976 Tokens).
• Der Preis pro Token ist in der gesamten Opus-Reihe identisch: Das Kostenverhältnis zwischen 4.8 und 4.5 von 1.43 entspricht dem Token-Verhältnis von 1.429.
• Die TTFT bei warmen Reads liegt bei Opus 4.5–4.8 zwischen 2.2 und 2.8s. Die Unterschiede sind Messschwankungen.

Alle folgenden Werte wurden am 2026-05-29 über https://synthorai.io/ mit dem Anthropic-nativen Endpoint /v1/messages gemessen. Verwendet wurden ein englischer System-Prompt mit etwa 8K Zeichen, ein kleiner Wert für max_tokens und ein einzelner sequenzieller Durchlauf. Messt mit eurem eigenen Prompt nach, bevor ihr diese Zahlen zitiert.

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-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

Ersetzt claude-opus-4-7 durch claude-opus-4-8. Am restlichen Caching-Pfad muss nichts geändert werden. Die Funktionsweise von cache_control erklären wir im Caching-Tutorial. Warum der Cache überhaupt existiert und wie er aufgebaut ist, steht in Teil 1 der Serie.

Caching-Verhalten: unverändert gegenüber 4.7/4.6

Wir haben für die neueren Modelle der Opus-Reihe dieselbe Abfolge aus Cache Write, Cache Read und Request ohne Cache ausgeführt. Die Rabattstruktur ist durchgehend identisch.

Für alle vier Versionen gelten zwei Konstanten:

• Rabatt auf Reads ≈ 89%. Ein Read aus dem warmen Cache kostet etwa 11% des Input-Preises ohne Cache. Das entspricht dem von Anthropic dokumentierten Satz von 10% für Cache Reads und ist unverändert.
• Aufschlag für Writes ≈ 25%. Der erste, kalte Request kostet etwa 1.25× so viel wie ein Request ohne Cache, da er den Cache befüllt. Bereits mit einem Cache Hit ist der Break-even erreicht.

Die absoluten Kosten für 4.7 und 4.8 liegen über denen von 4.5/4.6. Der Grund ist jedoch die Anzahl der Tokens, nicht die Kostenstruktur des Caches. Die prozentualen Werte bleiben gleich.

TTL-Verhalten: unverändert gegenüber 4.7/4.6

Opus 4.8 unterstützt dieselben beiden TTLs wie die übrigen Modelle der Reihe: standardmäßig ein gleitendes Zeitfenster von 5 Minuten und optional ein Zeitfenster von 1 Stunde. Wir haben für jeden Request ein eindeutiges Präfix verwendet, damit kein alter Cache-Eintrag das Ergebnis verfälscht, und den Write-Aufschlag für beide TTLs gemessen:

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

Das Usage-Objekt weist den jeweiligen TTL-Bucket weiterhin als cache_creation.ephemeral_5m_input_tokens oder ephemeral_1h_input_tokens aus. Ein Write mit 1 Stunde TTL kostet etwa 2× so viel wie ein Request ohne Cache, ein Write mit 5 Minuten TTL dagegen etwa 1.25×. Reads bleiben unabhängig von der TTL bei etwa 11%. Das Verhalten entspricht exakt 4.7. Wer bei 4.7 für Live-Chats 5m und für Agents mit Human-in-the-Loop-Pausen 1h gewählt hat, kann diese Einstellungen bei 4.8 beibehalten.

Time-to-first-token: über die gesamte Reihe stabil

Wir haben die TTFT bei warmen Reads mit Streaming gemessen. Nach einem Warm-up des Gateways wurden pro Modell 5 Samples genommen und der Median ermittelt. Bei diesem Prompt mit etwa 8–11K Tokens liegt die TTFT zwischen rund 2.2 und 2.8 s. Es gibt keinen relevanten Trend zwischen den Versionen. Die Wertebereiche überschneiden sich, die Unterschiede sind daher Messschwankungen und kein Effekt der Modellversion.

Dabei gelten zwei Einschränkungen:

• Daraus lässt sich kein Ranking ableiten. Die Wertebereiche überschneiden sich stark. Der höchste Wert für 4.8 war mit 4.38 s ein Ausreißer. Bei dieser Prompt-Größe wird die TTFT stärker durch Netzwerk- und Queueing-Schwankungen beeinflusst als durch die Modellversion. Für alle vier Modelle ist etwa 2.2–2.8 s ein realistischer Bereich bei warmem Cache.
• Der TTFT-Vorteil des Caches wächst mit der Prompt-Länge. Bei etwa 8–11K Tokens ist die durch einen Cache Hit eingesparte Prefill-Zeit gering. Deshalb liegen kalte und warme TTFT auf einem aufgewärmten Gateway beide bei etwa 2–3 s. Ab 100K+ Tokens wird der Abstand deutlich größer, weil dann das Prefill dominiert. Ein warmer Cache macht dort aus einer Wartezeit von mehreren Sekunden eine schnelle Ausgabe des ersten Tokens. Die Funktionsweise erklären wir in Teil 1: So funktionieren KV Cache und TTL.

Die einzige echte Änderung: Tokenisierung seit 4.7

Vor der Migration solltet ihr einen Punkt erneut prüfen: Derselbe Systemtext wird bei 4.7/4.8 mit etwa 43% mehr Input-Tokens ausgewiesen als bei 4.5/4.6.

Die Anzahl der Tokens steigt mit der Generation 4.7 und bleibt bei 4.8 auf diesem Niveau. Die Kosten folgen der Token-Anzahl nahezu exakt: Das Kostenverhältnis von 4.8 zu 4.5 beträgt 1.43, das Token-Verhältnis 1.429. Der Preis pro Token ist also über die gesamte Reihe hinweg gleich. Die höheren Kosten bei 4.7/4.8 entstehen ausschließlich dadurch, dass derselbe Text als mehr Tokens gezählt wird.

Daraus folgen zwei praktische Konsequenzen:

1. Plant anhand der absoluten Kosten neu, nicht anhand des Rabatts. Der Cache-Rabatt bleibt mit etwa 89% für Reads unverändert. Derselbe englische Prompt kostet bei 4.7/4.8 absolut aber etwa 43% mehr als bei 4.6. Ein anhand der Token-Anzahl von 4.6 kalkuliertes Budget pro Request stimmt daher nicht mehr.
2. Prüft die Mindestgrenze von 1,024 Tokens für Cache-fähige Präfixe erneut. Anthropic cached nur Präfixe ab einer bestimmten Mindestgröße. Ein Prompt, der bei 4.6 knapp unter dieser Grenze lag, kann sie bei 4.7/4.8 durch die höhere Token-Anzahl überschreiten. Auch Prompts, deren Größe in Tokens auf Basis des alten Tokenizers festgelegt wurde, müssen neu gemessen werden. Verwendet immer cache_creation_input_tokens und cache_read_input_tokens aus der Live-Response, statt mit einem lokalen Tokenizer zu schätzen, der möglicherweise nicht übereinstimmt.

Wir beschreiben hier eine Messbeobachtung: Identischer Text wird bei 4.7/4.8 mit etwa 43% mehr Input-Tokens ausgewiesen. Das spricht am ehesten für eine Aktualisierung des Tokenizers oder Vokabulars mit der Generation 4.7. Für die Konsequenz spielt die genaue Ursache keine Rolle: Messt die Token-Anzahl bei der Migration neu, da die Cache-Berechnung auf Tokens basiert.

Checkliste für die Migration (4.6/4.7 → 4.8)

• ✅ 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 gültig. 5m für Live- und Session-Workloads, 1h für unregelmäßige Workloads und Agents mit Pausen.
• ✅ Die Kostenstruktur der Rabatte bleibt gleich. Etwa 89% Rabatt auf Reads, ~1.25× für Writes (5m) und ~2× für Writes (1h).
• ⚠️ Messt die Token-Anzahl neu. Bei einer Migration von 4.5/4.6 solltet ihr für denselben Text mit über 40% mehr Input-Tokens rechnen. Diese Änderung kam mit 4.7. Bei einer Migration von 4.7 bleibt die Anzahl gleich.
• ⚠️ Validiert die Kosten-Dashboards erneut. Verwendet usage.cost und die *_input_tokens-Felder aus der Live-Response, nicht zwischengespeicherte Schätzwerte der vorherigen Generation.

Fazit

Für Engineering-Teams, die mit Opus bereits Prompt Caching nutzen, ist claude-opus-4-8 ein unkompliziertes Upgrade. Die gesamte Caching- und TTL-Schnittstelle bleibt stabil. Es gibt weder neue Konzepte noch Codeänderungen. Wer von 4.6 oder älter wechselt, muss die geänderte Tokenisierung im Budget berücksichtigen. Prüft die Werte mit dem Live-Objekt usage und rollt das Upgrade aus.

Der vollständige Leitfaden zu Prompt-Struktur, Debugging der Hit Rate und TTL-bewussten Patterns beginnt mit So funktionieren KV Cache und TTL. Dazu gibt es ein ausführbares Python-Tutorial.

FAQ

Muss ich meinen cache_control-Code für Opus 4.8 ändern? Nein. Marker-Syntax, Breakpoint-Limit und TTL-Optionen sind identisch zu 4.7/4.6. Ändert nur das Feld model.

Hat sich der Rabatt für Cache Reads bei 4.8 geändert? Nein. Bei 4.5 bis 4.8 kostet ein warmer Read etwa 11% des Input-Preises ohne Cache, also rund 89% weniger. Das entspricht dem von Anthropic dokumentierten Satz.

Hat sich der Aufschlag für die TTL von 1 Stunde geändert? Nein. Ein Write mit 1 Stunde TTL kostet etwa 2× so viel wie der Input-Preis ohne Cache, bei 5 Minuten sind es etwa 1.25×. Reads liegen unabhängig von der TTL bei etwa 11%. Das entspricht 4.7.

Warum ist derselbe Prompt bei 4.8 teurer als bei 4.6? Der Preis pro Token ist gleich, aber der Prompt wird als mehr Tokens gezählt. In unseren Messungen hatte identischer Text bei 4.5/4.6 etwa 8.0K Tokens und bei 4.7/4.8 etwa 11.4K. Das ist ein Anstieg von rund 43% und spricht am ehesten für eine Änderung des Tokenizers mit der Generation 4.7. Der Cache-Rabatt bleibt unverändert.

Ist 4.8 ein Drop-in-Replacement für 4.7? Beim Caching und bei den TTLs ja. Token-Anzahl und Kostenstruktur lagen bereits bei 4.7 auf demselben Niveau, daher bleibt bei der Migration von 4.7 alles gleich. Wir veröffentlichen keine Capability-Benchmarks, die wir nicht selbst durchgeführt haben. Aussagen zu Qualität und Reasoning findet ihr in der Model Card von Anthropic.

Verifizierung: Alle Werte zu Caching, TTL, Token-Anzahl, Kosten und TTFT wurden am 2026-05-29 mit dem offiziellen anthropic SDK über https://synthorai.io/ und innerhalb eines einzelnen Tenants gemessen. Die Kosten- und Token-Werte stammen aus einem einzelnen sequenziellen Durchlauf. Für die TTFT wurde nach einem Gateway-Warm-up pro Modell der Median aus 5 Samples verwendet. Die Rabatt- und Aufschlagsverhältnisse wurden mit der Anthropic-Dokumentation zu Prompt Caching abgeglichen. Eure Werte hängen von Prompt, Region und Auslastung ab.

← Zurück zum Blog