Prompt Caching bei Claude, OpenAI, Gemini: 8 Regeln

Was speichert Prompt Caching?

Ein Sprachmodell merkt sich zwischen zwei Anfragen nichts. Schicken Sie dieselbe Systemanweisung, dasselbe Dokument oder denselben Code-Kontext hundertmal, wird alles hundertmal verarbeitet und hundertmal abgerechnet. Prompt Caching (Zwischenspeichern des Prompts) ändert das: Der Anbieter verarbeitet den unveränderlichen Anfang der Anfrage einmal und speichert ihn; spätere Anfragen mit demselben Anfang lesen ihn aus dem Cache.

Gespeichert wird nicht der Text selbst, sondern die Zwischenzustände, die das Modell beim Verarbeiten des Textes berechnet; der nächste Abschnitt erklärt das. Deshalb muss die Übereinstimmung exakt sein: Ist das Präfix nicht Byte für Byte gleich, kann es nicht aus dem Cache gelesen werden.

Drei Begriffe werden oft verwechselt:

Quelle: Dokumentation von OpenAI, Anthropic, vLLM und GPTCache, 15. Oktober 2026.

Damit haben wir jeden Tag zu tun: Wenn diffox einen Pull Request prüft, lesen viele spezialisierte Agenten denselben Kontext in getrennten Aufrufen (wie das funktioniert, beschreibt ein eigener Beitrag).

So funktioniert der Cache

Bevor ein Sprachmodell zu antworten beginnt, liest es die gesamte Eingabe; diese Phase heißt Prefill. Dabei berechnet es für jedes Token Zwischenzustände namens Key (Schlüssel) und Value (Wert). Die Dokumentation von OpenAI nennt sie KV-Zustände: Über sie blickt das Modell beim Erzeugen der Antwort auf frühere Tokens zurück. Genau das speichert Prompt Caching: nicht den Text, sondern die Tensoren, die das Modell beim Verarbeiten des Textes berechnet.

Daher kommt der Vorteil. Liegt das Präfix im Cache, überspringt das Modell dessen Berechnung und verarbeitet nur die neuen Tokens. Die Dokumentation von vLLM zeigt auch, wo der Gewinn endet: Der Cache verkürzt die Verarbeitung der Eingabe, nicht das Erzeugen neuer Tokens. Am meisten profitiert deshalb ein langes Präfix mit einer kurzen Antwort. Das Prompt-Cache-Paper hat gemessen, dass die Zeit bis zum ersten Token auf der GPU bis zu 8-mal und auf der CPU bis zu 60-mal kürzer wird.

Dieselbe Struktur erklärt, warum das Präfix Byte für Byte gleich sein muss. Das Designdokument von vLLM kennzeichnet jeden Block im Cache durch zwei Dinge: die Tokens des Blocks selbst und die Tokens des Präfixes davor. Derselbe Satz ist also ein anderer Block, wenn ein anderer Text vor ihm steht. Ein einziges Datum am Anfang macht alle Blöcke dahinter zu neuen Blöcken; der Cache nützt nur bis zu der Stelle, an der sich etwas geändert hat.

Klein sind diese Zustände auch nicht. Das PagedAttention-Paper schreibt, dass der KV-Cache-Speicher jeder Anfrage sehr groß ist und im Lauf der Anfrage wächst und schrumpft. Deshalb begrenzen die Anbieter den Cache auf Minuten: Laut der Dokumentation von Google Cloud ist der Cache im Arbeitsspeicher begrenzt, und Einträge werden verdrängt, sobald der Platz gebraucht wird. Auch Anthropic sagt, dass diese Zustände nur im Arbeitsspeicher liegen und nicht dauerhaft gespeichert werden.

Aktivierung und Preise bei vier Anbietern

Alle vier Anbieter unterstützen den Cache, unterscheiden sich aber darin, wie man ihn aktiviert, wie lang das Präfix mindestens sein muss und was er kostet. Die Angaben in der Tabelle haben wir am 15. Oktober 2026 der Dokumentation des jeweiligen Anbieters entnommen.

Quelle: Dokumentation der Anbieter, 15. Oktober 2026. Die Faktoren beziehen sich auf den Eingabepreis ohne Cache. Die Zeile zu Google Cloud gilt für Gemini 2.5 und neuer.

Bei Anthropic und bei den Modellen von OpenAI ab GPT-5.6 ist das Schreiben in den Cache teurer, als dieselben Tokens ohne Cache zu senden, das Lesen dagegen viel günstiger. Kostet das Schreiben das 1,25-Fache, rechnet sich der Cache deshalb schon beim ersten Lesen; beim 1-Stunden-Cache von Anthropic, bei dem das Schreiben das Doppelte kostet, beim zweiten. Beim expliziten Cache von Gemini kostet das Schreiben den normalen Preis, dafür fällt für jede Stunde, die der Cache besteht, eine Speichergebühr an; ob sich das lohnt, hängt davon ab, wie oft gelesen wird und wie lange der Cache bestehen bleibt.

Wenn in der Claude API viele Aufrufe denselben Kontext lesen, setzen Sie die Markierung an den gemeinsamen Block; die Anweisung für den einzelnen Aufruf folgt danach. ephemeral ist derzeit der einzige unterstützte Cache-Typ; der Modellname stammt aus dem Beispiel der Dokumentation selbst:

{
  "model": "claude-opus-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "<gemeinsamer Kontext: in jedem Aufruf derselbe Text>",
      "cache_control": {"type": "ephemeral"}
    },
    {
      "type": "text",
      "text": "<Anweisung nur für diesen Aufruf>"
    }
  ],
  "messages": [
    {"role": "user", "content": "<die Frage dieses Aufrufs>"}
  ]
}

Wie lange bleibt der Cache warm?

Ein Eintrag bleibt nicht unbegrenzt im Cache. Die Dokumentation von Claude Code beschreibt seinen Zustand mit zwei Wörtern: Liegt der Eintrag innerhalb seiner Laufzeit (TTL, Time to Live), ist der Cache warm; ist sie abgelaufen, ist er kalt (cold). Bei einem warmen Cache liest die nächste Anfrage das Präfix günstig; bei einem kalten verarbeitet sie es von vorn und zahlt den Preis fürs Schreiben.

Quelle: Dokumentation der Anbieter, 15. Oktober 2026. Die Laufzeit des impliziten Caches von Gemini steht nicht in der Dokumentation; bei Google Cloud sind es höchstens 24 Stunden, und die meisten Einträge fallen früher heraus.

Die Laufzeit läuft wie ein Timer ab, und dabei sind zwei Details wichtig. Bei Anthropic läuft der Timer ab dem Start der Anfrage, nicht ab dem Ende der Antwort: Hat das Streaming der Antwort 4 Minuten gedauert, muss die nächste Anfrage mit demselben Präfix innerhalb von etwa 1 Minute starten. Bei Anthropic, OpenAI und Bedrock setzt zudem jeder Treffer den Timer zurück; regelmäßiger Traffic hält den Cache so von selbst warm.

Die meisten Anbieter haben keinen Endpoint, der verrät, ob der Cache noch warm ist. Die Ausnahme ist der explizite Cache von Gemini: cachedContents.get liefert immer den Ablaufzeitpunkt (expireTime), nicht den Inhalt. Bei Anthropic, OpenAI und Bedrock erkennen Sie es erst an der nächsten Antwort: Fällt die Zahl der aus dem Cache gelesenen Tokens auf null, hat sich entweder das Präfix geändert oder der Eintrag ist kalt geworden. Das Cache-Diagnostics-Tool von Anthropic unterscheidet beides: Sind die Anfragen gleich und ist der Lesewert null, ist der Eintrag abgelaufen.

In Claude Code hängt die Laufzeit davon ab, wie Sie bezahlen. Laut Dokumentation nutzt die Hauptkonversation mit einem Claude-Abo einen 1-Stunden-Cache, solange Sie innerhalb der im Plan enthaltenen Nutzung bleiben. Mit Nutzungsguthaben, mit einem API-Schlüssel oder über einen Cloud-Anbieter ist es ein 5-Minuten-Cache. Subagenten bekommen auch im Abo 5 Minuten. Ändern lässt sich die Laufzeit mit der Einstellung promptCacheTtl oder der Variable CLAUDE_CODE_PROMPT_CACHE_TTL.

Den Zustand sehen Sie an drei Stellen. /usage zeigt, ob der Cache warm oder kalt ist, zusammen mit der aktuellen Laufzeit. Im JSON für die Statuszeile (Status Line) trägt das Objekt prompt_cache die Felder warm, ttl und expires_at, den Zeitpunkt, an dem der Cache kalt wird. Und die Cache-Uhr in der VS-Code-Erweiterung zählt von der 5-Minuten- oder 1-Stunden-Laufzeit herunter und zeigt die verbleibenden Minuten; bei einem 1-Stunden-Cache beginnt sie bei 60 Minuten.

Drei Dinge, auf die Sie achten sollten:

• Der Abstand zwischen den Anfragen muss unter der Laufzeit bleiben. Liegen zwischen zwei Anfragen mehr als 5 Minuten, schreibt die spätere das Präfix neu. Anthropic empfiehlt, beim 5-Minuten-Cache zu bleiben, wenn das Präfix öfter als alle 5 Minuten genutzt wird, denn die Verlängerung ist kostenlos.
• Eine lange Laufzeit gibt es nicht umsonst. Bei Anthropic kostet das Schreiben für 1 Stunde das Doppelte und rechnet sich erst, wenn das Präfix zweimal gelesen wird; beim expliziten Cache von Gemini fällt für jede Stunde eine Speichergebühr an.
• Die erste Anfrage nach einer langen Pause ist teuer. Ist der Cache abgekühlt, schreibt die erste Anfrage das ganze Präfix. Sie können den Cache aber vorwärmen, bevor die eigentliche Anfrage kommt: bei Anthropic mit max_tokens: 0, bei den Modellen von OpenAI ab GPT-5.6 mit prompt_cache_options.prewarm.

In einem Beispiel mit zehn Aufrufen kostet das Präfix 78,5 % weniger

Die Zahlen sind rund und hypothetisch; sie zeigen nur die Faktoren aus der Dokumentation. Angenommen, zehn Aufrufe lesen ein gemeinsames Präfix von 50.000 Tokens. Die Einheit ist ein Token zum Basis-Eingabepreis; Schreiben wird mit 1,25×, Lesen mit 0,1× angesetzt. Diese Faktoren gelten für den 5-Minuten-Cache von Anthropic und die meisten Modelle von OpenAI ab GPT-5.6.

ohne Cache     10 × 50.000 × 1      = 500.000

mit Cache       1 × 50.000 × 1,25   =  62.500   erster Aufruf schreibt
              + 9 × 50.000 × 0,1    =  45.000   neun Aufrufe lesen
                                    = 107.500

Nacheinander gestartet, zahlen die zehn Aufrufe für das Präfix den Gegenwert von 107.500 Tokens; das sind 78,5 % weniger als die 500.000 ohne Cache. Bei einem Modell mit dem Lesefaktor 0,05× sinkt die Summe auf 85.000. Mit dem 1-Stunden-Cache steigt das Schreiben auf 100.000, und die Summe liegt bei 145.000.

Der dritte Balken zeigt den schlimmsten Fall: Dieselben zehn Aufrufe starten gleichzeitig. Keiner kann lesen, was ein anderer geschrieben hat, und wenn jeder das Präfix selbst schreibt, kommen 625.000 zusammen. Das ist 25 % teurer, als den Cache gar nicht zu nutzen. Warum, erklärt der Abschnitt über parallele Aufrufe weiter unten.

8 Regeln für eine hohe Cache-Trefferquote

Die Dokumentationen der vier Anbieter sagen über Treffer dasselbe. Jede der folgenden Regeln steht in der Dokumentation von mindestens zwei Anbietern.

Am häufigsten wird die zweite Regel übersehen. Eine Zeile in den Versionshinweisen von Claude Code zeigt das: Das Datum aus dem System-Prompt zu nehmen, hat die Cache-Trefferquote erhöht. Das Datum ändert sich täglich, und steht es am Anfang des Präfixes, schreibt die erste Anfrage jedes neuen Tages das ganze Präfix neu.

Zwei Regeln gelten nur bei einem Anbieter. Bei den Modellen von OpenAI vor GPT-5.6 bekommen Anfragen mit demselben Präfix einen festen prompt_cache_key. Er hilft, sie zum selben Cache zu leiten; die Dokumentation empfiehlt etwa 15 Anfragen pro Minute und Schlüssel. Anthropic verlangt dagegen, dass die JSON-Schlüssel in Tool-Aufrufen immer in derselben Reihenfolge stehen. Laut Dokumentation ordnen manche Sprachen wie Swift und Go Schlüssel zufällig an, sodass derselbe Inhalt mit anderen Bytes verschickt wird.

Was den Cache ungültig macht

Bei Anthropic und Bedrock folgt der Cache einer Hierarchie: tools, system, messages. Eine Änderung auf einer Ebene macht diese Ebene und alle dahinter ungültig. Hier sind sechs der Fälle, die Anthropics Dokumentation aufzählt:

Die Zitierfunktion ein- oder auszuschalten wirkt wie die Websuche, Bilder im Prompt hinzuzufügen oder zu entfernen wie tool_choice. Den Fall, den die Dokumentation einen „häufigen Fehler“ nennt, zeigt die vierte Karte: Steht der Breakpoint auf einem Block mit einem Zeitstempel oder mit der Nachricht des Nutzers, schreibt jede Anfrage einen neuen Eintrag, und keine kann lesen. Das System sucht rückwärts höchstens 20 Blöcke ab; es sucht aber nicht nach unverändertem Inhalt, sondern nach einem Eintrag, den eine frühere Anfrage geschrieben hat. Geschrieben wird nur am Breakpoint. Deshalb kommt die Markierung an den letzten Block, der zwischen den Anfragen gleich bleibt.

Caching bei parallelen Aufrufen

Aufrufe mit demselben Präfix gleichzeitig zu starten, liegt nahe. Anthropics Dokumentation ist hier eindeutig: Bei gleichzeitigen Anfragen ist ein Cache-Eintrag erst nutzbar, nachdem die erste Antwort begonnen hat; sollen parallele Anfragen aus dem Cache lesen, warten Sie auf die erste Antwort, bevor Sie die übrigen senden. Auch OpenAI schreibt, dass der Cache auf einzelnen Maschinen liegt und mehr als 15 Anfragen pro Minute auf andere Maschinen ausweichen können.

Die erste Antwort muss nicht fertig sein, es reicht, dass sie begonnen hat. Die Dokumentationen zeigen drei Wege:

• Senden Sie den ersten Aufruf allein. Claude Code macht das selbst, wenn es in einem Workflow Agenten mit demselben Präfix gemeinsam startet: Es hält alle außer dem ersten zurück, bis die Antwort des ersten Agenten beginnt; die Wartezeit beträgt standardmäßig höchstens 5.000 Millisekunden.
• Wärmen Sie den Cache vor. Eine Anfrage mit max_tokens: 0 schreibt am Breakpoint in den Cache und kehrt zurück, ohne eine Ausgabe zu erzeugen; Ausgabe-Tokens werden nicht abgerechnet. Die Markierung muss auf dem gemeinsamen Block stehen, und die Thinking-Einstellung sowie der Wert von output_config.effort müssen denen der eigentlichen Aufrufe entsprechen. Zusammen mit Einstellungen, die eine Ausgabe verlangen (etwa stream: true), wird die Anfrage abgelehnt.
• Nutzen Sie bei Batch-Jobs den 1-Stunden-Cache. In der Batch API werden Anfragen in beliebiger Reihenfolge verarbeitet, und ein Lesen aus dem Cache ist nicht garantiert. Die Dokumentation empfiehlt, die eine Anfrage mit dem gemeinsamen Präfix zuerst mit 1-Stunden-Cache zu senden und den Rest, sobald sie abgeschlossen ist.

So messen Sie Ihre Cache-Treffer

Verlassen Sie sich nicht darauf, dass der Cache greift; lesen Sie es an der Antwort ab. Alle vier Anbieter geben in den Nutzungsangaben der Antwort die aus dem Cache gelesenen Tokens in einem eigenen Feld an:

Quelle: Dokumentation der Anbieter, 15. Oktober 2026.

Die Cache-Trefferquote ist der Anteil der aus dem Cache gelesenen Tokens an der gesamten Eingabe; OpenAI definiert sie so und empfiehlt, sie nach Nutzer, Workspace oder Tag zusammenzufassen. Wichtig ist, die gesamte Eingabe richtig zu berechnen: Bei Anthropic und Bedrock zählt das Eingabefeld die Tokens im Cache nicht mit, die Summe ergibt sich aus drei Feldern; bei Gemini enthält promptTokenCount die aus dem Cache gelesenen Tokens bereits.

Die gesamte Eingabe ist die Summe der drei Felder. input_tokens allein zeigt nicht die ganze Eingabe; es zählt nur, was nach dem letzten Breakpoint kommt. Läuft alles wie vorgesehen, entspricht das Schreibfeld beim ersten Aufruf der Länge des Präfixes; bei den folgenden Aufrufen steht dieselbe Zahl im Lesefeld. Sind beide Felder null, wurde der Prompt nicht gecacht; der wahrscheinlichste Grund ist ein Präfix unter der Mindestlänge. Bleibt das Schreibfeld bei jedem Aufruf hoch, ändert sich etwas im Präfix.

Wir speichern die drei Felder jedes Aufrufs einzeln. Einen Aufruf ohne Nutzungsangaben zählen wir nicht als null, sondern als nicht gemessen; eine als null eingetragene Lücke sähe aus wie ein kostenloser Aufruf.

Wann sich der Cache nicht lohnt

Nicht für jeden Workload lohnt sich der Cache. Prüfen Sie vor dem Aktivieren vier Fälle:

• Das Präfix wird nur einmal gelesen. Kostet das Schreiben das 1,25-Fache und liest kein zweiter Aufruf, zahlen Sie 25 % mehr.
• Der Abstand zwischen den Aufrufen ist länger als die Laufzeit. Der Cache ist jedes Mal kalt, und das Präfix wird neu geschrieben.
• Das Präfix ist kürzer als die Mindestlänge. Die Anfrage läuft, der Cache nicht; einen Fehler gibt es auch nicht.
• Das Präfix ändert sich bei jeder Anfrage. Ein Datum am Anfang macht jede Anfrage zu einem neuen Schreibvorgang.

Es geht nicht nur um den Preis: Bei langen Präfixen kommt auch das erste Token schneller. Beim Ratenlimit gehen die Anbieter auseinander: Laut Anthropic und Bedrock werden bei Claude aus dem Cache gelesene Tokens nicht auf das Ratenlimit angerechnet; bei OpenAI zählen sie zum Token-Limit pro Minute.

In diffox lesen die spezialisierten Agenten eines Reviews denselben gemeinsamen Kontext: den Diff der Änderung und den Dateikontext. Dieser Kontext steht in einem Block am Anfang der Anfrage und trägt die Cache-Markierung; der erste Aufruf geht allein los, die übrigen starten danach parallel. Was jeder Aufruf schreibt und liest, wird einzeln gespeichert.