Prompt-Cache-Minimums: Die Doku untertreibt um das 1,4- bis 2,4-Fache

Ein Kunde meldete uns, dass das Prompt-Caching auf unserem Gateway nicht bei der Token-Zahl griff, die die Doku des Modells versprach. Wir haben es reproduziert und dann jedes Modell gegen einen zweiten, unabhängigen Serving-Pfad laufen lassen: eines der größten AI-Gateways. Dort traten dieselben Abweichungen bis auf das Token genau wieder auf. Zu optimistisch war die Dokumentation, nicht ein bestimmtes Gateway. Das veröffentlichte Minimum ist eine Untergrenze für die Berechtigung, nicht die Länge, ab der ein Cache-Hit zustande kommt. Bei den Familien mit automatischem Cache unterscheiden sich beide um das 1,4- bis 2,4-Fache. Der effektive Schwellenwert für den ersten Hit bei OpenAI lag gemessen bei rund 1.456 Tokens gegenüber dokumentierten 1.024; Gemini 2.5 Flash las erstmals bei etwa 5.000 Tokens aus dem Cache gegenüber dokumentierten 2.048; Claude, das nur dort cached, wo man einen expliziten Marker setzt, erreichte sein dokumentiertes Minimum pro Modell auf wenige Prozent genau.

TL;DR

• Das dokumentierte Cache-Minimum von OpenAI von 1.024 Tokens untertreibt den effektiven Schwellenwert von etwa 1.456 Tokens, gemessen auf zwei Pfaden.
• Gemini 2.5 Flash dokumentiert 2.048, las aber erstmals bei rund 5.000 Tokens, etwa das 2,4-Fache.
• Claudes explizites cache_control erreichte sein dokumentiertes Minimum auf wenige Prozent genau (Opus 1.073 gegenüber 1.024).
• GLM 5.2 und DeepSeek V4 geben kein Minimum an und lesen ab etwa 800 Tokens; MiniMax M3 meldet bei jeder Länge rund 114 gecachte Tokens.
• Automatische Caches brauchen außerdem eine Aufwärmphase von 2 bis 8 Calls vor dem ersten Read.

Wir haben jede Messung durch zwei Serving-Pfade laufen lassen, unser eigenes Gateway und eines der größten unabhängigen AI-Gateways, und ein Ergebnis nur dann als Modellverhalten gewertet, wenn beide Pfade übereinstimmten. Der zweite Pfad dient der Zuordnung: Eine Abweichung, die sich auf dem Stack eines fremden Anbieters reproduzieren lässt, geht auf das Modell zurück, nicht auf uns. Dieser Abgleich funktionierte sauber für OpenAI, Gemini und GLM, die auf beiden Pfaden bei denselben effektiven Schwellenwerten cachten. Für jedes Modell funktioniert es nicht: Auf dem zweiten Gateway werden die Open-Weight-Modelle größtenteils von GPU-Hosts bedient, die den Prompt-Cache des Anbieters nicht implementieren – die Endpoint-Metadaten des Gateways bestätigen das pro Provider –, und ungepinntes Routing driftet über diese Hosts, sodass die Cache-Affinität verloren geht. Wo der zweite Pfad nicht bestätigen konnte, stammen die Zahlen unten von dem Pfad, der die eigene Caching-API des jeweiligen Anbieters erreicht. Die Längen sind die Tokens des jeweiligen Modells, kalibriert anhand des zurückgegebenen usage, nicht Zeichen. Jeder Arm nutzte einen frischen Prefix und protokollierte den ersten Call-Index, der einen Cache-Read erzeugte, nicht einen einzelnen Treffer oder Fehlschlag.

Die Lücke zwischen dokumentiert und effektiv

Das dokumentierte Minimum sagt dir, ab wann ein Prompt gecacht werden kann. Die effektive Schwelle ist die Länge, ab der ein wiederholter Prompt tatsächlich als Read zurückkommt. Bei den automatischen Cache-Familien sind das nicht dieselben Zahlen.

Der OpenAI-Wert stimmte auf beiden Pfaden bis auf den Token: Ein Prompt mit 1.356 Token kam nie als Read zurück, einer mit 1.456 Token schon. Bei Gemini war die Lücke am größten. Ein Sweep, der bei 3.300 Token endete, zeigte null Reads und sah so aus, als wäre Caching abgeschaltet; erweiterte man den Sweep auf 5.000, kam auf beiden Pfaden bei derselben Länge ein sauberer Read. Die dokumentierten 2.048 sind ein Boden, ab dem der Cache infrage kommt, nicht einer, ab dem er Reads liefert.

Das Muster über die ganze Studie: Der Cache, den du explizit markierst, hat eine korrekte Spezifikation, und der automatische nicht.

Das Minimum ist nicht die einzige undokumentierte Variable

Die effektive Schwelle zu überschreiten ist notwendig, aber nicht ausreichend. Die automatischen Cache-Familien brauchen eine Aufwärmphase: Der erste Read kommt bei einem späteren Aufruf, nicht beim zweiten.

• OpenAI: erster Read bei Aufruf 2 bis 3.
• Gemini: erster Read bei Aufruf 4 bis 8.

Das ist für die Kostenmodellierung relevant. Ein Prompt mit 6.000 Token liegt über jeder dokumentierten und effektiven Gemini-Schwelle, aber ein Workload, der ihn zweimal sendet und dann aufhört, zahlt trotzdem beide Male den vollen Preis, weil der Cache nicht warm war. Kurzer oder stoßweiser Traffic zahlt den ungecachten Tarif, selbst wenn die Länge passt. Wir haben erst nach mindestens zwölf wiederholten Aufrufen mit einer Pause dazwischen auf “cacht nicht” geschlossen; ein kürzerer Sweep lieferte bei Gemini ein falsch negatives Ergebnis, das ein tieferer widerlegte.

Auch die gecachten Zählwerte rasten auf feste Blöcke ein, was man beim Abgleich einer Rechnung wissen sollte: 128-Token-Blöcke bei OpenAI, 64-Token-Blöcke bei DeepSeek. Ein Read von 4.073 gecachten Token bei einem Prompt mit 5.014 Token ist ein Teilpräfix-Hit, auf eine Blockgrenze gerundet, kein Bug.

Die Caches, die du steuerst, sind exakt

Claude cacht nur die Segmente, die du mit cache_control markierst, und diese Steuerung kommt mit einer korrekten Spezifikation. Jede Angabe von Anthropic, die wir getestet haben, hat gestimmt:

• Minimum pro Modell, auf den Token genau. Opus 4.8 und Sonnet 5 lieferten den ersten Read bei 1.073 Token gegenüber dokumentierten 1.024; Haiku 4.5 bei 4.206 gegenüber 4.096. Der kleine Überschuss ist Block-Rundung, keine Abweichung.
• Read-Rate von 0,1x Input. Wir haben den Input-Preis jedes Modells aus seinen eigenen Cold-Zeilen abgeleitet und dann die gecachte Rate aus einer Hit-Zeile berechnet. Opus 4.8 und Haiku 4.5 kamen beide auf 0,10, was dem dokumentierten Multiplikator entspricht.
• Fünf-Minuten-Refresh, kostenlos bei jedem Read. Wir haben ein Präfix gesetzt und nach zwei, vier und sechs Minuten erneut gelesen — bei jedem Read ein Hit. Ein Read innerhalb des Fünf-Minuten-Fensters hält den Eintrag am Leben, ohne einen zusätzlichen Write.
• Kaskadierende Invalidierung. Mit einem stabilen System-Präfix und einem definierten Tool erzwang schon die Änderung nur der Tool-Beschreibung eine komplette Neuberechnung des darunterliegenden System-Caches. Eine geänderte Tool-Definition invalidiert den System- und den Message-Cache, entsprechend der dokumentierten Hierarchie.

Dabei fiel ein Widerspruch zwischen zwei Dokumentationen auf. Eine Drittanbieter-Tabelle nannte für Claude Opus ein Minimum von 4.096 Token; die Messung zeigte einen Read bei 1.073, und die eigenen 1.024 von Anthropic sind der korrekte Wert.

Die Open-Weight-Familien dokumentieren meist gar nichts

Die oben genannten Familien veröffentlichen wenigstens eine Zahl, bei der man danebenliegen kann. Die Open-Weight-Modelle und die Modelle chinesischer Labs geben meist überhaupt kein Minimum an, also bleibt nur die Messung. Unser Vergleich der Provider-Caches zeigt, wie sich die veröffentlichten Raten nach einem Treffer verhalten; hier geht es nur um die Länge, ab der der erste Read auftaucht.

GLM 5.2 gibt keine Mindestlänge an und cachte auf beiden Pfaden ab etwa 800 Tokens mit einer Granularität von 64-Token-Blöcken – ein niedrigerer Boden als bei allen dokumentierten Familien. DeepSeek V4 gibt ebenfalls kein Minimum an und lieferte ab etwa 800 Tokens Reads mit derselben 64-Token-Granularität, aber nur über die eigene Caching-API. Die DeepSeek-Docs bezeichnen den Cache als Best-Effort ohne Garantie für die Trefferquote, und genau das legt ein Intermediary offen: Das andere Gateway bedient DeepSeek über eine Reihe von GPU-Hosts, bei denen nur der eigene DeepSeek-Endpunkt den Cache implementiert. Routing, das nicht an diesen Endpunkt gebunden ist, liefert also gar keine Reads.

Bei MiniMax M3 führt schon die gemeldete Zahl selbst in die Irre. Das Modell dokumentiert ein Minimum von 512 Tokens, meldet aber ab dem ersten Aufruf einen konstanten Wert um 114 cached Tokens bei jeder Länge von 200 bis 5.000 Tokens. Diese Zahl folgt nicht der Prompt-Länge und taucht auch auf Pfaden auf, die gar nichts cachen. Sie ist also die eigene Buchführung des Modells und kein Signal dafür, was wiederverwendet wurde. Das ist dieselbe Lektion, die die neueren OpenAI-Modelle aus der anderen Richtung erteilen: Die Token-Felder in der Usage und das tatsächliche Caching können auseinanderlaufen. Wenn die Ersparnis zählt, gleiche gegen usage.cost ab, nicht gegen den Token-Count.

Die neuesten Modelle verschieben die Regeln

Zwei Änderungen auf Doku-Ebene sind einen Hinweis wert, bevor du annimmst, dass altes Verhalten weiterhin gilt. Für die GPT-5.6-Familie schreibt OpenAIs Guide, dass Cache-Writes das 1,25-fache der ungecachten Input-Rate kosten, während frühere Familien kostenlos schrieben. Derselbe Guide beschreibt implizites Caching so, dass ein Breakpoint auf die letzte Nachricht gesetzt wird – eine andere Form als das Prefix-Caching eines stabilen System-Blocks über mehrere Turns hinweg. Wenn du bei diesen Modellen ein stabiles Prefix über unterschiedliche User-Turns hinweg wiederverwenden willst, markiere es mit einem expliziten Breakpoint, statt dich auf den impliziten Pfad zu verlassen. Prüfe den Write-Multiplikator und das Minimum pro Modell, denn beide variieren mittlerweile je nach Familie so, wie es eine einzelne Doku-Seite verwischt.

Was du damit anfängst

• Miss deinen eigenen effektiven Schwellenwert. Variiere die Prompt-Länge in deinen eigenen Tokens und notiere die erste Länge, bei der ein Cache-Read zurückkommt. Geh nicht davon aus, dass Hits beim dokumentierten Minimum einsetzen.
• Plane Aufwärmzeit ein. Bei Providern mit automatischem Cache solltest du die ersten zwei bis acht Calls auf einem neuen Präfix in deinem Kostenmodell als ungecacht behandeln.
• Bevorzuge explizite Marker, wo der Provider sie anbietet. Claudes cache_control lieferte eine präzise, testbare Spezifikation: ein bekanntes Minimum, eine bekannte Read-Rate, ein bekanntes TTL und eine bekannte Invalidierungsregel. Diese Vorhersehbarkeit ist mehr wert als ein niedrigerer dokumentierter Grenzwert, auf den du dich nicht verlassen kannst.
• Setze bei neuen Modellfamilien eine neue Baseline. Minima, Write-Preise und Breakpoint-Verhalten haben sich während dieser Untersuchung sogar innerhalb der Lineup eines einzelnen Anbieters verschoben.

Die Read-Raten, TTLs und Keying-Regeln hinter diesen Schwellenwerten samt der Mechanik pro Provider findest du in unserem Prompt-Caching-Guide.

Kurz gesagt: Das dokumentierte Minimum ist eine Eligibility-Grenze, kein Hit-Schwellenwert, und bei automatischen Caches unterscheiden sich beide um den Faktor 1,4 bis 2,4. Prüf die Zahl, die deine Rechnung bestimmt, in deinen eigenen Tokens und gegen deinen eigenen Traffic.

← Zurück zum Blog