DR
Die Preisgestaltung für zwischengespeicherte Eingaben kann die Kosten für Workloads mit einem großen, unveränderten Prompt-Präfix erheblich senken, aber die Einsparungen hängen von modellspezifischen Regeln für Cache-Lesen, Cache-Schreiben, Speicherung, Routing und Aufbewahrung ab. Ein allgemeines „Caching unterstützt“-Label reicht nicht zur Kostenschätzung; verwenden Sie den aktuellen, für das genaue Modell und die Route veröffentlichten Preis.
TL;DR
- GPT-5.6 Terra hat explizite Preise für Cache-Lesen und Cache-Schreiben von OpenAI, CometAPI und OpenRouter, obwohl Gateway-Routen und Long-Context-Tarife die Höhe verändern können.
- Google veröffentlicht einen Satz von $0.15 pro 1M-Token für Context-Caching im Standard-Tier für Gemini 3.6 Flash plus eine Speichergebühr; CometAPI veröffentlicht derzeit die Standardpreise für Eingabe und Ausgabe des Modells ohne separate Zeile für zwischengespeicherte Eingaben.
- Der relevante Vergleich ist nicht nur Standard-Eingabe versus Cache-Lesen. Er umfasst auch den ersten Cache-Schreibvorgang, etwaige Speichergebühren, Cache-Lebensdauer, Routen-Konsistenz und die Anzahl späterer Cache-Treffer.
Kernaussagen
- Preise auf Modell- und Service-Tier-Ebene prüfen statt einen gatewayweiten Multiplikator anzuwenden.
- Cache-Lesen, Cache-Schreiben, Speicherung und Response-Caching in der Kostenrechnung getrennt halten.
- Tatsächliche Cache-Nutzung in den API-Antwort-Metadaten verifizieren, bevor man Einsparungen anhand des veröffentlichten Satzes prognostiziert.
Eine Anfrage, die einen großen, unveränderten Präfix wiederholt — ein System-Prompt, ein Satz von Tool-Schemata, ein langes Referenzdokument — muss nicht bei jedem Aufruf zum vollen Eingabesatz abgerechnet werden. Die meisten Modelle der aktuellen Generation unterstützen eine Art Preisgestaltung für zwischengespeicherte Eingaben: einen reduzierten Satz für den Teil eines Prompts, den ein Anbieter als bereits verarbeitet erkennt. Der Mechanismus, die Rabattgröße und wie klar er veröffentlicht ist, variieren nach Anbieter und Gateway — diese Variation lohnt es, konkret zu betrachten, statt „Caching ist unterstützt“ als einheitliches Merkmal zu behandeln.
Was Preisgestaltung für zwischengespeicherte Eingaben ist — und nicht ist
Die Preisgestaltung für zwischengespeicherte Eingaben rabattiert die Eingabe-Tokens in einer Anfrage, die mit einem zuvor gesendeten Präfix übereinstimmen. Sie rabattiert keine Ausgabe-Tokens und ist nicht dasselbe wie ein Gateway, das zwei vollständig identische Anfragen dedupliziert und eine Antwort kostenlos zurückgibt — das ist ein anderer Mechanismus, den manche Gateways separat anbieten. Die Preisgestaltung für zwischengespeicherte Eingaben bedeutet konkret, weniger für den Teil eines Prompts zu bezahlen, den ein Modellanbieter kürzlich bereits gesehen hat, nicht das Generieren vollständig zu überspringen.
Sie ist zudem nicht kostenlos zu erstellen. Die GPT-5.6-Preishinweise von OpenAI geben an, dass Cache-Schreibvorgänge mit dem 1,25-fachen des nicht zwischengespeicherten Eingabesatzes abgerechnet werden, während Cache-Lesevorgänge einen Rabatt von 90 % erhalten. Diese Erstschreibprämie beeinflusst den Break-even-Punkt und wird leicht übersehen, wenn ein Vergleich nur den rabattierten Lesesatz zeigt. Andere Anbieter können speicherbasierte Gebühren anstelle desselben Schreibmodells verwenden, daher sollten Schreib- und Speicherkosten getrennt geprüft werden.
In der Praxis ist die abrechenbare Cache-Einheit in der Regel ein wiederverwendbarer Prompt-Präfix und nicht eine beliebige Sammlung wiederholter Sätze. Anbieter tokenisieren und vergleichen Inhalte der Reihe nach, daher muss das wiederverwendbare Material vor dem anfragespezifischen Ende erscheinen. Stabile Systemanweisungen, Tool-Definitionen, Richtlinien und Referenzmaterial gehören an den Anfang; eine sich verändernde Nutzer-Nachricht, ein Zeitstempel, eine Request-ID oder ein abgerufenes Snippet später. Selbst eine semantisch harmlose Änderung nahe dem Anfang kann die Tokenisierung verschieben oder die Übereinstimmung für alles Folgende unterbrechen.
Zulässigkeitsregeln sind ebenfalls modellspezifisch. Ein Anbieter kann eine Mindest-Promptlänge verlangen, nur dokumentierte Breakpoints erkennen oder ein explizites Cache-Control-Feld bereitstellen. Ein Cache-Eintrag kann zwischen den Aufrufen ablaufen, und ein Gateway muss möglicherweise verwandte Anfragen auf einer kompatiblen Upstream-Route halten. Das bedeutet, dass eine Cache-Trefferrate als beobachtetes Ergebnis behandelt werden sollte, nicht als Annahme aus Prompt-Ähnlichkeit. Ein gut strukturierter Prompt verbessert die Wiederverwendungswahrscheinlichkeit, aber die Response-Metadaten und die Rechnung bestimmen, ob der Rabatt tatsächlich angewendet wurde.
Was tatsächlich veröffentlicht ist, nach Modell und Gateway
Die folgende Tabelle ist ein Preissnapshot, geprüft am 29. Juli 2026. Preise sind in US-Dollar pro 1 Million Tokens, sofern keine andere Einheit angegeben ist. Die Zeilen vergleichen die aktuellen öffentlichen Informationen für GPT-5.6 Terra und Gemini 3.6 Flash beim Modellanbieter, bei CometAPI und OpenRouter; sie sind nicht als dauerhafte Tarife zu behandeln.
| Modell | Gateway | Standard-Eingabe | Zwischengespeicherte Eingabe (Lesen) | Cache-Schreiben | Rabatt offengelegt? |
|---|---|---|---|---|---|
| GPT-5.6 Terra | Offizieller OpenAI-Tarif | $2.50 / 1M | $0.25 / 1M | $3.13 / 1M | Ja — 90 % Rabatt, direkt angegeben |
| GPT-5.6 Terra | CometAPI | $2.00 / 1M | $0.20 / 1M | $2.50 / 1M | Ja — auf der eigenen CometAPI-Preisseite aufgeführt |
| GPT-5.6 Terra | OpenRouter | $2.50 / 1M | Nicht als spezifischer Satz aufgeführt | Nicht aufgeführt | Nein — nur als „60–80 % günstiger“ in Summe beschrieben, keine modellbezogene Zahl |
| Gemini 3.6 Flash | Offizieller Google-Tarif | $1.50 / 1M | $0.15 / 1M (laut Googles eigener Ankündigung) | Nicht offengelegt | Ja, zum Launch — über Googles Modelldokumentation |
| Gemini 3.6 Flash | CometAPI | $1.20 / 1M | Nicht als spezifischer Satz aufgeführt | Nicht offengelegt | Nein — die CometAPI-Seite markiert „Caching“ als unterstütztes Feature, veröffentlicht jedoch derzeit keinen rabattierten Cache-Eingabepreis für dieses spezifische Modell |
| Gemini 3.6 Flash | OpenRouter | $1.50 / 1M | Nicht als spezifischer Satz aufgeführt | Nicht offengelegt | Nein — die OpenRouter-Dokumentation beschreibt Googles Cache-Multiplikator generisch (0,25× Listen-Eingabe), bestätigt jedoch nicht den spezifischen Satz dieses Modells |
Lesen Sie die Tabelle als modell- und routenspezifischen Snapshot. Die CometAPI-GPT-5.6-Modellseite listet GPT-5.6 Terra mit $2.00 für Standard-Eingabe, $0.20 für zwischengespeicherte Eingabe und $2.50 für Cache-Schreiben pro 1 Million Tokens. Die Gemini-3.6-Flash-Modellseite von CometAPI veröffentlicht derzeit $1.20 für Eingabe und $6.00 für Ausgabe, zeigt jedoch keine separate Preiszeile für zwischengespeicherte Eingaben oder Cache-Speicherung. Googles Gemini Developer API Pricing listet das Standard-Tier mit $1.50 für Eingabe, $0.15 für Context-Caching und $1.00 pro 1 Million Tokens pro Stunde für Speicherung. OpenRouter veröffentlicht inzwischen modellspezifische Cache-Felder über seine Models API: Der Default-Route für GPT-5.6 Terra enthält niedrigere Aktionspreise und ein separates höheres Long-Context-Tier, während der Gemini-3.6-Flash-Eintrag unterschiedliche Werte für Standard, Flex und Priority ausweist. Das ist präziser, als einen generischen Cache-Multiplikator auf jedes Modell anzuwenden.
Warum sich Gateway- und Anbieterpreise unterscheiden können
Ein Gateway-Preis ist nicht zwingend ein Aufschlag auf einen unveränderlichen Upstream-Listenpreis. Er kann ausgehandelte Kapazität, eine zeitlich befristete Aktion, ein anderes Service-Tier oder eine routenspezifische kommerzielle Vereinbarung widerspiegeln. Ein Modellname kann auch mehreren Upstream-Varianten zugeordnet sein, deren Preise sich mit Kontextlänge oder Latenzgarantien ändern. OpenRouter veröffentlicht für GPT-5.6 Terra beispielsweise eine Default-Route und eine höher bepreiste Override, sobald die Eingabe die Long-Context-Schwelle erreicht. Google trennt für Gemini 3.6 Flash die Preise nach Standard, Batch, Flex und Priority. Eine einzelne Vergleichszeile braucht daher Datum, Route, Tier und Kontextannahme, um sinnvoll zu bleiben.
Das Gegenteil ist ebenfalls wichtig: Wenn eine Gateway-Seite keine separate Cache-Lesezeile veröffentlicht, sollte dieses Fehlen weder in „Caching ist nicht verfügbar“ noch in „der direkte Rabatt des Anbieters gilt automatisch“ umgedeutet werden. Das Gateway kann eine Upstream-Funktion durchreichen, ohne sie zu itemisieren, sie nur auf bestimmten Routen bereitstellen oder die Anfrage zum normalen Eingabesatz abrechnen. Der vertretbare Ansatz ist, die eigene aktuelle Modellseite des Gateways für die Planung zu verwenden und dann den tatsächlichen Satz anhand von Nutzungsaufzeichnungen oder Abrechnungsdaten zu bestätigen. Die Anbieterdokumentation bleibt nützlich, um den Mechanismus zu verstehen, legt jedoch nicht für sich allein die kommerziellen Bedingungen eines Intermediärs fest.
Wo der Rabatt tatsächlich zählt
Das Szenario, in dem sich die Kosten tatsächlich spürbar ändern, ist ein großer, statischer Präfix gepaart mit einer kleinen, variablen Anfrage — ein System-Prompt oder ein Satz von Tool-Schemata, die in einer Agentenschleife bei jedem Aufruf erneut gesendet werden, ein langes Referenzdokument, das wiederholt mit unterschiedlichen Fragen abgefragt wird, oder eine Konversationshistorie, die bei jedem Chatbot-Turn erneut gesendet wird. Für einen solchen Workload wächst der Unterschied zwischen dem vollen Eingabepreis auf den gesamten Präfix bei jedem Mal versus dem einmaligen Schreibaufschlag und dem rabattierten Lesesatz danach mit dem Anfragevolumen. Für Workloads ohne wiederholten Präfix bewirkt das nichts — eine einmalige Anfrage hat kein zwischengespeichertes Material, das überhaupt rabattiert werden könnte.
Eine praktische Break-even-Berechnung vergleicht die unzwischengespeicherte Kosten des wiederholten Präfixes über alle Aufrufe mit den Kosten für Cache-Schreiben oder Speicherung plus den rabattierten Cache-Lesungen bei späteren Aufrufen. Das Ergebnis hängt von der Präfixgröße, der Anzahl erfolgreicher Cache-Treffer, Cache-Ablauf und davon ab, ob das Gateway die Anfragen auf einer kompatiblen Anbieterroute hält. Wenn diese Bedingungen instabil sind, kann der Schlagzeilenrabatt die tatsächlichen Einsparungen in der Produktion überschätzen.
Ein einfaches Kostenmodell für einen wiederholten Präfix
Sei P die Anzahl der Tokens im stabilen Präfix und N die Anzahl der Aufrufe, die ihn wiederverwenden. Wenn U der unzwischengespeicherte Eingabesatz pro Token ist, kostet der Präfix ohne Caching N × P × U. Eine vereinfachte Cached-Schätzung ist P × W + (N − 1) × P × R + S, wobei W der Cache-Schreibpreis, R der Cache-Lesepreis und S eine etwaige Speichergebühr über den Zeitraum ist. Die Formel nimmt an, dass der erste Aufruf den Cache erzeugt und jeder spätere Aufruf ein erfolgreicher Treffer ist. Sie schließt den variablen „Tail“ jeder Anfrage, Ausgabe-Tokens, Retries und jeden Routenwechsel, der einen Miss verursacht, aus.
Betrachten Sie einen illustrativen Präfix mit 100.000 Tokens, der für 20 Aufrufe wiederverwendet wird, zum offiziellen GPT-5.6-Terra-Tarif. Bei $2.50 pro 1 Million unzwischengespeicherter Eingabetokens würde die wiederholte Verarbeitung dieses Präfixes $5.00 kosten. Unter Verwendung des veröffentlichten 1,25-fachen Schreibsatzes und des um 90 % rabattierten Lesesatzes würde ein einmaliger Schreibvorgang über 100.000 Tokens etwa $0.3125 kosten und neunzehn Lesevorgänge etwa $0.475 — für kombinierte Präfixkosten von rund $0.7875. Die Differenz beträgt etwa $4.21 vor variablen Eingabe- und Ausgabekosten. Dies ist eine Illustration, kein Angebot: Sie gilt nur, wenn alle neunzehn späteren Aufrufe denselben gültigen Cache treffen und keine zusätzlichen Speicher- oder Routinggebühren anfallen.
Der Break-even-Punkt folgt direkt aus demselben Modell. Eine Schreibprämie lohnt sich nur, wenn genügend rabattierte Lesungen vor dem Ablauf stattfinden. Bei einem Workload mit kurzen Sitzungen, häufigen Prompt-Änderungen oder schwacher Routenaffinität kann der Cache häufiger neu erstellt werden als erwartet. Bei einer langlebigen Agentenschleife oder wiederholter Dokumentanalyse mit stabilem Präfix kann die Anzahl der Treffer deutlich höher sein. Prognosen sollten daher eine beobachtete Trefferquotenspanne verwenden, statt eine perfekte Sequenz nach dem ersten Aufruf anzunehmen.
Implementierungsmuster, die die Cache-Wiederverwendung verbessern
Die Prompt-Konstruktion hat einen größeren Einfluss auf die Trefferquote, als viele Preis-Tabellen nahelegen. Stellen Sie das stabilste Material an den Anfang und halten Sie dessen Serialisierung deterministisch: Systemanweisungen, Tool-Schemata, Richtlinientexte und gemeinsamer Referenzkontext sollten die gleiche Reihenfolge, Leerzeichen und Feldrepräsentation über verwandte Aufrufe beibehalten. Fügen Sie volatilen Inhalt danach an. Vermeiden Sie es, Zeitstempel, zufällige Kennungen, sich kontinuierlich ändernde Zähler oder anfragespezifische Retrieval-Ergebnisse in den wiederverwendbaren Präfix einzuspritzen, es sei denn, sie werden dort wirklich benötigt.
Versionieren Sie stabiles Material bewusst. Wenn sich ein Tool-Schema oder eine Richtlinie ändert, weisen Sie die neue Version konsistent zu, statt mehrere nahezu identische Varianten zirkulieren zu lassen. Für konversationelle oder agentische Workloads verwenden Sie eine stabile Sitzungskennung oder einen Cache-Schlüssel, wenn die API einen unterstützt, und vermeiden Sie Anbieterwechsel innerhalb derselben cacheabhängigen Sequenz. OpenRouter dokumentiert provider-sticky Routing für Prompt-Caching und stellt Steuerungen wie session_id und prompt_cache_key bereit; diese Steuerungen können die Kontinuität verbessern, garantieren jedoch keinen Treffer, wenn der Upstream-Cache kalt oder abgelaufen ist.
Anwendungen sollten auch bei einem Cache-Miss sauber degradieren. Caching ist eine Optimierung für Kosten und Latenz, keine Korrektheitsabhängigkeit. Die Anfrage muss weiterhin dasselbe gültige Ergebnis liefern, wenn der Cache nicht verfügbar ist, und die Retry-Logik sollte nicht blind wiederholte Schreibvorgänge erzeugen. Diese Trennung macht den Routenvergleich sicherer: Teams können die Caching-Policy oder die Gateway-Konfiguration ändern, ohne das semantische Verhalten der Anwendung zu verändern.
So überprüfen Sie die Cache-Ökonomie im Betrieb
Beginnen Sie mit Telemetrie pro Anfrage statt mit der Monatsrechnung. Protokollieren Sie die exakte Modellkennung, Gateway-Route oder Anbieter (wenn offengelegt), Service-Tier, Gesamtanzahl der Eingabe-Tokens, zwischengespeicherte Lese-Tokens, Cache-Schreib-Tokens, Ausgabe-Tokens, Latenz und abgerechnete Kosten. Das Nutzungsobjekt von OpenRouter umfasst cached_tokens und cache_write_tokens; andere Anbieter veröffentlichen entsprechende Details unter anderen Feldnamen. Bewahren Sie Roh-Nutzungsfelder auf, damit eine spätere Preisänderung nicht die Belege löscht, die zur Kostenrekonstruktion nötig sind.
Aggregieren Sie die Daten nach Prompt-Version und Workload, nicht nur nach Modell. Nützliche Messgrößen sind der Anteil berechtigter Anfragen mit Cache-Treffer, der Anteil der Eingabe-Tokens, die zum Lesesatz abgerechnet wurden, Schreibvorgänge pro erfolgreiche Lesung, Zeit zwischen Schreibvorgang und letztem Treffer und die realisierten Kosten pro Anfrage. Eine hohe Trefferquote auf Anfrageebene kann wenig Wert liefern, wenn der zwischengespeicherte Präfix klein ist, während eine niedrigere Trefferquote bei einem sehr großen Präfix mehr sparen kann. Paaren Sie diese Messgrößen mit Latenz-Perzentilen, denn eine günstigere Route, die wiederholt verfehlt oder umleitet, kann operativ schlechter sein.
Überprüfen Sie schließlich Anomalien statt sie wegzuglätten. Ein plötzlicher Rückgang zwischengespeicherter Tokens kann auf ein Prompt-Versions-Rollout, instabile Serialisierung, abgelaufene Einträge, eine Long-Context-Tier-Grenze oder eine Gateway-Routenänderung hinweisen. Vergleichen Sie die betroffenen Anfragen mit der aktuellen Modellseite und der Anbieterdokumentation und verifizieren Sie dann den abgerechneten Satz. So schließen Sie die Lücke zwischen einem veröffentlichten Rabatt und den Einsparungen, die die Anwendung tatsächlich realisiert.
Was vor der Annahme eines gültigen Satzes zu prüfen ist
Bestätigen Sie fünf Punkte, bevor Sie einen veröffentlichten Satz in ein Budget übernehmen: das genaue Modell und Service-Tier, den minimal wiederverwendbaren Präfix oder explizite Cache-Breakpoints, die Erstschreib- oder Speichergebühr, die Cache-Lebensdauer und den Nachweis, dass Anfragen den Cache tatsächlich treffen. OpenAI gibt aktuell eine Mindest-Cache-Lebensdauer von 30 Minuten für GPT-5.6 an, aber das ist keine universelle Aufbewahrungsregel. Google veröffentlicht unterschiedliche Sätze für die Service-Tiers Standard, Batch, Flex und Priority. Gateways können ebenfalls zwischen Anbietern oder Tiers routen, daher zählt die gewählte Route. OpenRouter empfiehlt in der Prompt-Caching-Dokumentation, Antwort-Nutzungsfelder wie cached_tokens und cache_write_tokens zu prüfen. Für jede Produktionsschätzung sollten Sie die aktuelle Modellseite mit tatsächlicher Abrechnung und Nutzungsmetadaten vergleichen, statt sich nur auf ein allgemeines „Caching unterstützt“-Label zu verlassen.