Prompt-Cache-Schreibkosten: Wann lohnt sich der Faktor 1.25x?

Ein Prompt-Cache-Write rechnet sich bereits nach einem einzigen erneuten Read innerhalb der TTL: Der Write wird mit dem 1.25x-fachen Input-Preis abgerechnet, der Read mit 0.1x. Damit wird aus einem Aufpreis von 25% über zwei Calls schon bei einem Hit eine Ersparnis von 32.5%. Trotzdem führte derselbe Aufpreis in einem der fünf Szenarien unserer Agent-Suite zu einem gemessenen Verlust von 6%. Entscheidend ist allein das Read:Write-Verhältnis deines Traffics. Dieser Beitrag zeigt, wie du es vor der nächsten Rechnung misst. Alle folgenden Werte wurden über das Synthorai Gateway anhand realer Billing-Daten ermittelt. Die Agent-Zahlen stammen aus einer Suite mit 150 Episoden, die TTL- und Clustering-Ergebnisse aus separaten Probes mit zufälligen Salts.

TL;DR

• Explizite Cache-Writes werden mit 1.25x bei 5 Minuten TTL oder 2x bei 1 Stunde abgerechnet. Die Breakpoints von GPT-5.6 folgen demselben Modell aus 1.25x für Writes und 0.1x für Reads. Ein erneuter Read reicht für den Break-even.
• In unserer Agent-Suite reichte der Nettoeffekt des Aufpreises von +6% bei RAG mit einem Read:Write-Verhältnis von 0.2 bis zu -83% bei Batch mit 15.7.
• Cache-Hits verlängern die TTL von Claude kostenlos. Bei kontinuierlichem Traffic fällt der Write einmal pro Leerlaufphase an, nicht einmal pro TTL-Fenster.
• Implizites Caching liefert sehr unterschiedliche Ergebnisse: GPT-5.5 erreichte nach einem primenden Call dauerhaft 7/8 Hits, Gemini selbst mit Clustering nur 1-3 Hits pro 12 Calls. Einen Aufpreis gibt es in beiden Fällen nicht.

Was kostet ein Cache-Write tatsächlich?

Bei den von uns verglichenen Providern gibt es drei Preismodelle, von denen zwei Writes berechnen. Beim expliziten Caching von Claude kostet die Cache-Erstellung mit der standardmäßigen TTL von 5 Minuten das 1.25x-Fache des Input-Preises. Für die 1-Stunden-Stufe gilt 2x, Reads kosten 0.1x. GPT-5.6 ist auf explizite Breakpoints umgestiegen und verwendet ebenfalls die Multiplikatoren 1.25x für Writes und 0.1x für Reads. Damit rechnen die beiden größten expliziten Implementierungen der Branche identisch ab. Das dritte Modell ist implizites Caching, wie bei Gemini, Kimi und OpenAI-Modellen vor 5.6. Hier gibt es keinen Aufpreis für Writes, sondern nur günstigere Reads, wenn der Provider einen Hit erzielt.

Die Break-even-Rechnung für explizite Writes ist einfach. Ein Prefix mit P Tokens kostet ohne Cache P zum normalen Preis. Mit Cache kostet der erste Call 1.25P. Jeder erneute Read innerhalb der TTL kostet 0.1P statt P. Nach einem Read liegen die Gesamtkosten für zwei Calls bei 1.35P statt 2P ohne Cache, also 32.5% weniger. Jeder weitere Hit spart 90% der Prefix-Kosten. Das Risiko ist nicht der Aufpreis selbst. Problematisch sind Cache-Blöcke, die nie erneut gelesen werden. Ob das passiert, hängt vom Workload ab.

Wann verursacht der Write-Aufpreis Mehrkosten?

Wenn sich das Prefix schneller ändert, als es wiederverwendet wird. Wir haben das Read:Write-Verhältnis der Tokens in fünf Agent-Szenarien gemessen. Modelle und Marker-Strategie waren dabei identisch. Anschließend haben wir den Nettoeffekt des Cachings mit Preisen von 1.25x für Writes und 0.1x für Reads berechnet:

Die RAG-Zeile ist entscheidend. Die abgerufenen Dokumente unterscheiden sich je nach Query. Deshalb schrieb jeder Call ein Prefix neu, das der nächste Call nicht wiederverwenden konnte: Auf jedes erneut gelesene Token kamen fünf geschriebene Tokens. Durch den Aufpreis von 1.25x entstand daraus ein Nettoverlust. Es lag keine Fehlkonfiguration vor. Der Workload kann einen Write schlicht nicht amortisieren. Die Lösung ist ein Schichtenmodell, nicht der vollständige Verzicht auf Caching: Markiere den System-Prompt und die Tool-Definitionen, die über mehrere Queries stabil bleiben. Die abgerufenen Dokumente stehen unmarkiert hinter dem letzten Breakpoint. Dasselbe gilt für alle volatilen Inhalte wie Zeitstempel, Benutzernamen und Request-spezifischen Kontext sowie für Einstellungen, die das Prefix unbemerkt ungültig machen. Wird output_config.effort zwischen Turns geändert, rendert das System den Prompt neu und invalidiert den Cache. Deshalb sollte der Effort innerhalb einer gecachten Session konstant bleiben. Unsere LangChain-Analyse zeigte denselben Fehler auf Framework-Seite: Builder machen es genauso einfach, alles zu markieren, wie gezielt nur die richtigen Teile zu markieren.

Wie oft fällt der Write tatsächlich erneut an?

Einmal pro Leerlaufphase, nicht einmal pro TTL-Fenster, denn Hits starten den Timer kostenlos neu. Wir haben das mit einem 4,981-Token-Prefix und zufälligem Salt auf Claude Opus 4.8 nachgewiesen:

Call 4 liegt deutlich außerhalb der ursprünglichen TTL von 5 Minuten und liest trotzdem vollständig aus dem Cache. Die Calls 2 und 3 haben das Fenster jeweils kostenlos verlängert. Erst die Pause von 7 Minuten erzwingt einen erneuten Write. Für jede Route, deren Inter-Arrival-Zeit unterhalb der TTL bleibt, ist der Write-Aufpreis damit eine einmalige Ausgabe. Die 5-Minuten-Stufe verhält sich dann praktisch wie ein Cache ohne Ablaufzeit. Die 1-Stunden-Stufe wird mit 2x für Writes abgerechnet. Über das Gateway haben wir bestätigt, dass die Abrechnung in einem eigenen ephemeral_1h_input_tokens-Bucket erfolgt. Sie eignet sich für anderen Traffic: Einmal 2x zu zahlen ist günstiger, als wiederholt 1.25x zu zahlen, sobald dadurch auch nur ein erneuter Write vermieden wird. Sie passt daher zu Routen mit Leerlaufphasen zwischen 5 Minuten und 1 Stunde. Nach mehr als 1 Stunde ohne Traffic kann keine der beiden Stufen den Cache über mehrere Runs hinweg erhalten. Bei einem geplanten Job zählt deshalb nur, was innerhalb eines einzelnen Runs passiert. Ein Cronjob mit genau einem Request profitiert nicht vom Schreiben. Verteilt er dagegen viele Requests mit demselben Prefix, verhält er sich wie ein Batch und kann genauso cachen.

Lässt sich implizites Caching durch Traffic-Shaping verbessern?

Das hängt vollständig vom jeweiligen impliziten Cache ab, denn Best-Effort-Caching deckt ein breites Spektrum ab. Am guten Ende verhielt sich das automatische Caching von GPT-5.5 wie ein verlässlicher Mechanismus: Nach einem primenden Call war der Eintrag 2 Sekunden später lesbar. Der erste Probe war bei beiden getesteten Salts ein Hit. In einem anschließenden Burst wurden bei sieben von acht Probes jeweils 4,864 der 5,170 Prompt-Tokens aus dem Cache gelesen, ohne dass dafür ein Aufpreis anfiel. Das sind reale Einsparungen, für die lediglich dasselbe Prefix zweimal gesendet werden muss. Am anderen Ende steht Gemini 3.6 Flash: In derselben Agent-Suite, in der explizites Caching 77-78% der Input-Tokens von Claude aus dem Cache bediente, erreichte Geminis impliziter Cache bei Workloads mit tatsächlich wiederkehrenden Prefixes nur 4%.

Wir versuchten, das schlechte Ende durch Traffic-Shaping zu verbessern. Dazu wurden Calls mit identischem Prefix gebündelt, damit der Provider-Cache warm bleibt. Zwölf direkt aufeinanderfolgende Calls mit Gemini 3.6 Flash erzeugten genau einen Hit, bei Call 10. Call 11 war bereits wieder ein Miss. Acht Calls im Abstand von jeweils 3 Minuten ergaben keinen einzigen Hit. Um einen Zufall auszuschließen, wiederholten wir den gebündelten Test über einen zweiten, unabhängigen Request-Pfad sowie mit Gemini 3.5 Flash. Dabei gab es drei beziehungsweise einen Hit von zwölf. Die Hits folgten nie lange direkt aufeinander. Der einzige Block, der gecacht wurde, kam auf beiden Pfaden mit denselben 4,073 Tokens zurück. Der Mechanismus ist konsistent, die Wahrscheinlichkeit nicht.

Ein Teil der Misses entsteht durch Ingestion-Latenz, deren Dauer vom Provider abhängt. Der Eintrag von GPT-5.5 war 2 Sekunden nach dem Priming lesbar. Gemini benötigt dagegen mehrere 10 Sekunden zum Aufbau. Bursts direkt nach dem ersten Call sind deshalb schneller als der Cache. In keinem unserer Gemini-Tests gab es vor dem vierten Call einen Hit. Wurde das Prefix einmal geprimt und vor dem Burst 45 Sekunden gewartet, stieg die Zahl der Hits auf 3 von 8. Das war das beste Ergebnis aller Traffic-Shaping-Varianten. Nach einer Wartezeit von 90 Sekunden lagen die Hits wieder bei 0 von 8. Zu diesem Zeitpunkt war der Eintrag bereits abgelaufen. Einige Tage zuvor hatte ein längerer Warm-up-Test auf demselben Modell kontinuierliche Hits geliefert. Die Trefferquote schwankt also zusätzlich mit Zeit und Last. Wegen der Aufbauverzögerung, kurzen Lebensdauer und schwankenden Trefferquote hilft Clustering am schlechten Ende nur insofern, als drei Hits besser sind als einer. (Hinweis für Tests: Prüfe implizite Caches mit zeitlich verteilten Calls und einer Prime-and-Wait-Variante. Ermittle die Aufbauverzögerung selbst mit gestaffelten Probes nach dem Priming. Direkt aufeinanderfolgende Probes messen vor allem deine Request-Rate, nicht den Cache.)

Die belastbare Regel gilt daher pro Provider, nicht pro Mechanismus: Miss, ob sich der implizite Cache deines Providers wie der von GPT-5.5 verhält, den du einmal primst und anschließend nutzen kannst, oder wie der von Gemini, bei dem jeder Hit nur ein unverhoffter Rabatt ist. Kimi K3 liegt dazwischen: kein Aufpreis, ein kleines Minimum und 57-62% der Inputs aus dem Cache ohne Konfiguration. Ein weiteres Ergebnis zeigt, welches Ende sich durchsetzt: OpenAI hatte den besten impliziten Cache in unseren Messungen und stellte GPT-5.6 trotzdem auf explizite Breakpoints um. Damit wurde aus einem vom Zufall unabhängigen Rabatt des Providers ein vom Kunden steuerbares Markierungsmodell.

Welche Workloads amortisieren den Aufpreis?

Die Entscheidung richtet sich nach dem Read:Write-Verhältnis und der Leerlaufphase. Beide Werte lassen sich vorab aus den eigenen Nutzungsdaten ablesen:

Aus den Messdaten folgen zwei abschließende Regeln. Bewerte Caching erstens anhand von cache_read und cache_creation in deinen eigenen detaillierten Nutzungsdaten, nicht danach, wie häufig sich Hits anfühlen. Das RAG-Szenario wirkte cachefreundlich, lag gemessen aber bei 0.2. Bei einem guten Verhältnis fällt der Aufpreis zweitens kaum noch ins Gewicht. Beim Read:Write-Verhältnis von 3.5 für die gesamte Suite sanken die Prefix-Kosten einschließlich sämtlicher Writes um 64%.

FAQ

Lohnt sich Prompt-Caching für RAG?

Nicht für die abgerufenen Dokumente. In unserer Messung schrieb RAG fünf Tokens für jedes erneut gelesene Token. Dadurch wurde aus dem Aufpreis von 1.25x ein Nettoverlust von 6%. Cache nur die stabilen Schichten, also den System-Prompt und die Tool-Definitionen. Abgerufene Inhalte bleiben hinter dem letzten Breakpoint. Der vollständige Leitfaden zum Caching beschreibt die Schichtung von Prompts ausführlich.

Sollte ich die Cache-TTL von 5 Minuten oder 1 Stunde verwenden?

Entscheidend ist die Leerlaufphase, nicht die Session-Länge. Hits verlängern die TTL von 5 Minuten kostenlos. Eine Route mit einer Inter-Arrival-Zeit unter 5 Minuten schreibt daher nie erneut, und die günstigere Stufe funktioniert praktisch unbegrenzt. Der Write-Aufpreis von 2x für die 1-Stunden-Stufe lohnt sich nur bei Pausen zwischen 5 Minuten und 1 Stunde. Sobald dadurch ein erneuter Write mit 1.25x vermieden wird, ist sie günstiger. Bei Pausen von mehr als 1 Stunde solltest du ohne Cache kalkulieren.

Fällt beim impliziten Caching eine Write-Gebühr an?

Nein. Strukturell ist das auch nicht möglich: Ein Write-Aufpreis ergibt nur dann Sinn, wenn der Caller Caching explizit aktiviert. Solche Aufpreise gibt es daher ausschließlich bei expliziten Varianten, etwa den Multiplikatoren 1.25x/2x von Anthropic, den Breakpoints von GPT-5.6 und dem Speichermietmodell expliziter Cached-Content-APIs wie Geminis Gebühr pro Token-Stunde. Alle von uns gemessenen impliziten Implementierungen, also Gemini, Kimi und OpenAI vor 5.6, sowie alle großen veröffentlichten Preislisten von DeepSeek, Qwen und Grok berechnen implizites Caching ausschließlich als vergünstigte Reads. Unterschiede gibt es bei der Zuverlässigkeit: Der implizite Cache von GPT-5.5 erzielte in geprimten Probes 7 von 8 Hits. Gemini bediente in unserer Agent-Suite dagegen nur 4% des Inputs aus dem Cache, und auch Clustering änderte daran kaum etwas. Kein Aufpreis für einen zuverlässig gewährten Rabatt ist unschlagbar. Kein Aufpreis für einen zufälligen Rabatt ist dagegen weniger wert als ein kleiner Aufpreis für einen steuerbaren Cache.

Gemessen vom 2026-07-25 bis 2026-07-29 über das Synthorai Gateway: Read:Write-Verhältnisse der Szenarien aus 150 Agent-Episoden mit Claude und detaillierter Cache-Aufschlüsselung pro Call (Gemini- und Kimi-Anteile aus den jeweiligen Suite-Runs); Probes zur TTL-Verlängerung und zum 1-Stunden-Bucket auf claude-opus-4-8 (Prefixes mit zufälligen Salts und 4,981 beziehungsweise 3,742 Tokens); Probes zum impliziten Cache auf gemini-3.6-flash und gemini-3.5-flash (Prefixes mit zufälligen Salts und ~6,800 Tokens; gebündelte, verteilte und Prime-and-Wait-Varianten) sowie auf gpt-5.5 (Prompt mit zufälligem Salt und 5,170 Tokens, geprimter Burst). Die Nettoeffekte wurden aus den gemessenen Verhältnissen mit Multiplikatoren von 1.25x für Writes und 0.1x für Reads berechnet. Preise und Cache-Verhalten können sich ändern. Prüfe daher deine eigenen Nutzungsdaten.

← Zurück zum Blog