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

claude-opus-4-8 ist jetzt im Synthorai-Gateway verfügbar. Wenn Sie bereits Prompt-Caching mit der Opus-Reihe betreiben, ist die Hauptnachricht beruhigend und etwas langweilig: Am Caching- oder TTL-Vertrag hat sich gegenüber 4.7 oder 4.6 nichts geändert. Dieselben cache_control-Marker, dieselben TTLs von 5 Minuten und 1 Stunde, derselbe Leserabatt, dieselben Schreibaufschläge. Ihr Caching-Code lässt sich unverändert übernehmen.

Es gibt genau eine Sache, die sich geändert hat — und zwar bereits bei 4.7, nicht bei 4.8 —, die Ihr Token-Budget betrifft. Dieser Beitrag misst sie, damit Sie es nicht müssen.

Alle nachstehenden Zahlen wurden am 2026-05-29 gegen https://synthorai.io/ (Anthropic-natives /v1/messages) mit einem englischen System-Prompt von ca. 8 K Zeichen, kleinem max_tokens und einem einzigen sequenziellen Durchlauf gemessen. Reproduzieren Sie sie mit Ihrem eigenen Prompt, bevor Sie sie zitieren.

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

Tauschen Sie claude-opus-4-7 → claude-opus-4-8 aus, und nichts anderes in Ihrem Caching-Pfad muss bewegt werden. Die Mechanik hinter cache_control wird im Caching-Tutorial behandelt; die Architektur dahinter, warum der Cache existiert, steht in Teil 1 der Serie.

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

Wir haben dieselbe Sequenz aus Cache-Schreiben / Cache-Lesen / ohne Cache über die aktuelle Opus-Reihe ausgeführt. Die Rabattstruktur ist von Anfang bis Ende identisch.

Zwei Invarianten gelten über alle vier Versionen hinweg:

• Leserabatt ≈ 89 %. Ein Lesevorgang aus einem warmen Cache kostet ca. 11 % des Eingabepreises ohne Cache. Das ist die von Anthropic dokumentierte Cache-Leserate von 10 %, unverändert.
• Schreibaufschlag ≈ 25 %. Der erste (kalte) Aufruf kostet ca. das 1,25-Fache des Preises ohne Cache, um den Cache zu füllen. Die Gewinnschwelle liegt bei einem einzigen Treffer.

Die absoluten Dollarbeträge für 4.7 und 4.8 sind höher als für 4.5/4.6, aber wie wir gleich sehen werden, ist das eine Frage der Token-Anzahl, nicht der Cache-Ökonomie — die Prozentsätze sind konstant.

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

Opus 4.8 berücksichtigt dieselben zwei TTLs wie der Rest der Reihe: einen gleitenden Standard von 5 Minuten und ein optional aktivierbares Fenster von 1 Stunde. Wir haben den TTL-Pfad mit einem eindeutigen Präfix pro Aufruf isoliert (sodass kein veralteter Cache-Eintrag das Ergebnis verfälschen konnte) und den Schreibaufschlag für jeden TTL 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 meldet den TTL-Bucket genau wie zuvor — cache_creation.ephemeral_5m_input_tokens oder ephemeral_1h_input_tokens. Das Schreiben mit 1 Stunde kostet ca. das 2-Fache des Preises ohne Cache (gegenüber ca. 1,25× beim 5-Minuten-Schreiben), und Lesevorgänge bleiben unabhängig vom TTL bei ca. 11 %. Identisch zu 4.7. Wenn Sie auf 4.7 5m für Live-Chat und 1h für Agenten mit Human-in-the-Loop-Pausen gewählt haben, behalten Sie diese Entscheidungen auf 4.8 bei.

Zeit bis zum ersten Token: konstant über die Reihe

Wir haben das TTFT beim warmen Lesen mit einem Streaming-Aufruf gemessen (5 Stichproben pro Modell nach einem Gateway-Aufwärmen, Median berichtet). Bei diesem Prompt von ca. 8–11 K Tokens liegt das TTFT in einem Band von ca. 2,2–2,8 s ohne wesentlichen Trend pro Version — die Stichprobenbereiche überschneiden sich, sodass die Unterschiede Rauschen sind und kein Versionseffekt.

Zwei Vorbehalte, die klar genannt werden sollten:

• Lesen Sie hier keine Rangfolge hinein. Die Bereiche überschneiden sich stark (die hohe Stichprobe von 4.8 war ein Ausreißer bei 4,38 s); bei dieser Prompt-Größe wird das TTFT von Netzwerk- und Warteschlangen-Rauschen dominiert, nicht von der Modellversion. Behandeln Sie ca. 2,2–2,8 s als das warme Band für alle vier.
• Der TTFT-Gewinn durch den Cache skaliert mit der Prompt-Länge. Bei ca. 8–11 K Tokens ist das durch einen Cache-Treffer eingesparte Prefill gering, sodass kaltes und warmes TTFT nahe beieinander liegen (beide ca. 2–3 s auf einem aufgewärmten Gateway). Die Lücke vergrößert sich erheblich bei über 100 K Tokens, wo das Prefill dominiert — dort verwandelt ein warmer Cache ein mehrsekündiges Warten in ein schnelles erstes Token. Die Mechanik steht in Teil 1: Wie KV-Cache & TTL funktionieren.

Die eine echte Änderung: Tokenisierung (seit 4.7)

Hier ist das, was Sie vor der Migration überprüfen sollten. Der gleiche System-Text meldet auf 4.7/4.8 etwa 43 % mehr Eingabe-Tokens als auf 4.5/4.6.

Die Token-Anzahl springt bei der 4.7-Generation und überträgt sich auf 4.8. Die Kosten folgen der Token-Anzahl nahezu exakt: Das Kostenverhältnis (4.8 / 4.5) beträgt 1,43 und das Token-Verhältnis 1,429. Mit anderen Worten: Der Preis pro Token ist über die gesamte Reihe gleich — die höhere Rechnung auf 4.7/4.8 kommt ausschließlich daher, dass derselbe Text als mehr Tokens zählt.

Zwei praktische Konsequenzen:

1. Budgetieren Sie über die absoluten Kosten neu, nicht über den Rabatt. Ihr Cache-Rabatt ist unverändert (~89 % beim Lesen), aber derselbe englische Prompt ist auf 4.7/4.8 in absoluten Zahlen etwa 43 % teurer als auf 4.6. Wenn Sie ein Budget pro Aufruf anhand der Token-Anzahl von 4.6 dimensioniert haben, wird es daneben liegen.
2. Überprüfen Sie die Cache-Eignungsuntergrenze von 1.024 Tokens erneut. Anthropic cacht nur Präfixe ab einer Mindestgröße. Ein Prompt, der auf 4.6 knapp unter der Grenze lag, kann sie auf 4.7/4.8 überschreiten (mehr Tokens), und ein in Tokens für den alten Tokenizer dimensionierter Prompt muss neu gemessen werden. Lesen Sie cache_creation_input_tokens / cache_read_input_tokens immer aus der Live-Antwort, anstatt aus einem lokalen Tokenizer zu schätzen, der möglicherweise nicht übereinstimmt.

Wir beschreiben eine gemessene Beobachtung — identischer Text, ca. 43 % mehr gemeldete Eingabe-Tokens auf 4.7/4.8 —, die am ehesten mit einer Tokenizer-/Vokabular-Aktualisierung bei der 4.7-Generation übereinstimmt. Die Schlussfolgerung hängt nicht von der eigentlichen Ursache ab: Messen Sie die Token-Anzahlen bei Ihrer Migration neu, denn die Cache-Mathematik basiert auf Tokens.

Migrations-Checkliste (4.6/4.7 → 4.8)

• ✅ Caching-Code lässt sich wortwörtlich übernehmen. cache_control-Marker, Anzahl der Breakpoints (bis zu 4), ttl: "1h", usage-Feldnamen — alle identisch.
• ✅ TTL-Entscheidungen lassen sich übernehmen. 5 Min für Live-/Session-Workloads, 1 Std für stoßweise/Agenten mit Pausen.
• ✅ Rabatt-Ökonomie lässt sich übernehmen. ~89 % beim Lesen, ~1,25× beim Schreiben (5 Min), ~2× beim Schreiben (1 Std).
• ⚠️ Messen Sie die Token-Anzahlen neu. Wenn Sie von 4.5/4.6 kommen, rechnen Sie mit ca. 40 %+ mehr Eingabe-Tokens für denselben Text (das geschah bei 4.7). Wenn Sie von 4.7 kommen, rechnen Sie mit Parität.
• ⚠️ Validieren Sie Kosten-Dashboards neu. Vertrauen Sie usage.cost und den *_input_tokens-Feldern aus der Live-Antwort, nicht einer gecachten Schätzung der alten Generation.

Fazit

Für ein Engineering-Team, das bereits gegen Opus cacht, ist claude-opus-4-8 die einfache Art von Upgrade: Die gesamte Caching- und TTL-Oberfläche ist stabil, es gibt also nichts neu zu lernen und keinen Code umzuschreiben. Planen Sie die Tokenizer-Änderung ein, wenn Sie von 4.6 oder früher springen, bestätigen Sie Ihre Zahlen anhand des Live-usage-Objekts und gehen Sie live.

Das vollständige Caching-Handbuch — Prompt-Struktur, Hit-Rate-Debugging, TTL-bewusste Muster — finden Sie in der vierteiligen Serie, beginnend mit Wie KV-Cache & TTL funktionieren und dem funktionierenden Python-Tutorial.

FAQ

Muss ich meinen cache_control-Code ändern, um Opus 4.8 zu nutzen? Nein. Die Marker-Syntax, das Breakpoint-Limit und die TTL-Optionen sind identisch zu 4.7/4.6. Ändern Sie das Feld model und sonst nichts.

Hat sich der Cache-Leserabatt bei 4.8 geändert? Nein. Ein warmer Lesevorgang beträgt ca. 11 % des Eingabepreises ohne Cache (~89 % günstiger) von 4.5 bis 4.8, entsprechend der von Anthropic dokumentierten Rate.

Hat sich der Aufschlag für den 1-Stunden-TTL geändert? Nein. Das Schreiben mit 1 Stunde kostet ca. das 2-Fache des Eingabepreises ohne Cache; das Schreiben mit 5 Minuten kostet ca. 1,25×. Lesevorgänge liegen unabhängig vom TTL bei ca. 11 %. Wie bei 4.7.

Warum ist derselbe Prompt auf 4.8 teurer als auf 4.6? Der Preis pro Token ist derselbe — der Prompt zählt einfach als mehr Tokens. Identischer Text meldete in unseren Messungen ca. 8,0 K Tokens auf 4.5/4.6 und ca. 11,4 K auf 4.7/4.8 (eine Steigerung von ca. 43 %), was am ehesten mit einer Tokenizer-Änderung bei der 4.7-Generation übereinstimmt. Der Cache-Rabatt ist unverändert.

Ist 4.8 ein direkter Ersatz für 4.7? Auf der Caching-/TTL-Oberfläche ja — Token-Anzahlen und Ökonomie lagen bereits auf 4.7-Niveau, sodass die Migration von 4.7 Parität bedeutet. Wir veröffentlichen keine Fähigkeits-Benchmarks, die wir nicht durchgeführt haben; für Aussagen zu Qualität und Reasoning siehe die Modellkarte von Anthropic.

Verifizierung: Alle Zahlen zu Caching, TTL, Token-Anzahl, Kosten und TTFT wurden am 2026-05-29 gegen https://synthorai.io/ mit dem offiziellen anthropic-SDK, Single-Tenant, gemessen. Kosten-/Token-Zahlen stammen aus einem einzigen sequenziellen Durchlauf; das TTFT ist ein Median aus 5 Stichproben pro Modell nach dem Gateway-Aufwärmen. Rabatt-/Aufschlagsverhältnisse wurden mit der Anthropic-Dokumentation zum Prompt-Caching abgeglichen. Ihre Zahlen variieren je nach Prompt, Region und Last.

← Zurück zum Blog