Prompt-Caching bei OpenAI und Claude: Funktionsweise, TTL, Preise, warum es nicht greift und wie man es prüft

Prompt-Caching verwendet die Berechnung für den Teil einer Anfrage wieder, der exakt mit dem Anfang einer früheren Anfrage übereinstimmt (dem Präfix), sodass dieser Teil der Eingabe günstiger und schneller verarbeitet wird. Sowohl die OpenAI-API als auch die Claude-API bieten es an, doch wie man es aktiviert, wie lange der Cache lebt, was ein Cache-Schreibvorgang kostet und wie man prüft, ob es greift, unterscheidet sich stark. Wer für beide mit denselben Annahmen plant, bekommt womöglich ein Caching, das auf der einen Seite funktioniert, während man auf der anderen bei jeder Anfrage den Schreibpreis zahlt und nie einen Treffer erzielt.

Dieser Artikel vergleicht das Prompt-Caching von OpenAI und Anthropic auf Basis des Originaltexts der OpenAI-Dokumente „Prompt caching“, „Prompt cache diagnostics“ und „Pricing“ sowie der Anthropic-Dokumente „Prompt caching“, „Cache diagnostics“, „Pricing“ und „Rate limits“. Er zeigt, worin sich die beiden Spezifikationen unterscheiden, wie man Cache-Treffer erzielt und wie man sie nachweist. Alle Zahlen wurden am 3. Oktober 2026 an den Originalseiten geprüft. Einen Gesamtüberblick, wie man API-Kosten senkt (Modellwahl, Batch-Verarbeitung, Steuerung der Ausgabe usw.), gibt unser Artikel „KI-Kosten und Tokens sparen“.

1. Was Prompt-Caching ist: ein identisches Präfix wiederverwenden

Jedes Mal, wenn ein Sprachmodell seine Eingabe liest, berechnet es für jedes Token Zwischenwerte (die KV-Tensoren, also Keys und Values). Prompt-Caching speichert diese Werte vom Anfang des Prompts bis zu einem bestimmten Punkt und überspringt die Berechnung, wenn die nächste Anfrage mit exakt denselben Tokens beginnt. Der Leitfaden von OpenAI erklärt, dass die KV-Werte gespeichert werden, nicht die Tokens selbst.

Entscheidend ist: Wiederverwendet werden kann nur der Teil, der vom allerersten Token an übereinstimmt. In den beiden Anfragen unten lassen sich nur die Anweisungen und die Dokumente wiederverwenden.

Anfrage 1: [Anweisungen 5,000 Tokens][Dokumente 20,000 Tokens][Frage A]
Anfrage 2: [Anweisungen 5,000 Tokens][Dokumente 20,000 Tokens][Frage B]
           └─────────────── bis hier identisch ──────────────┘└ anders ┘
→ Die 25,000 Tokens aus Anweisungen + Dokumenten sind wiederverwendbar

Anfrage 3: [Heutiges Datum][Anweisungen 5,000 Tokens][Dokumente 20,000 Tokens][Frage C]
           └─── anders ───┘
→ Obwohl der Rest übereinstimmt, ist kein einziges Token wiederverwendbar

Die Dokumentation beider Anbieter stellt klar, dass Caching den Inhalt der Ausgabe nicht verändert. Es speichert keine frühere Antwort, um sie erneut abzuspielen, sondern spart nur die Arbeit, die Eingabe zu lesen. Deshalb hilft es auch in Chats, in denen jede Frage anders ist, oder bei Agenten, die jedes Mal andere Dokumente lesen – solange es ein gemeinsames Präfix gibt (Anweisungen, Tool-Definitionen, Gesprächsverlauf).

2. Prompt-Caching bei OpenAI und Anthropic im direkten Vergleich

Am 22. September 2026 kündigte OpenAI Verbesserungen des Cachings für GPT-6 an, und für GPT-5.6 und neuere Modelle hat sich der Mechanismus geändert (30 Minuten Aufbewahrung, explizite Breakpoints, kostenpflichtige Cache-Schreibvorgänge u. a.). Die OpenAI-Spalte der folgenden Tabelle beschreibt GPT-5.6 und neuer. Die Unterschiede bei GPT-5.5 und älteren Modellen folgen nach der Tabelle.

Quellen: OpenAI „Prompt caching“, „Prompt cache diagnostics“; Anthropic „Prompt caching“, „Cache diagnostics“, „Rate limits“ (geprüft am 3. Oktober 2026)

GPT-5.5 und ältere Modelle kennen nur implizites Caching mit Breakpoints, die automatisch in festen Abständen gesetzt werden, und keinen Aufpreis für Cache-Schreibvorgänge. Die Aufbewahrung wird mit prompt_cache_retention festgelegt: Laut Leitfaden hält in_memory „etwa 5 bis 10 Minuten Inaktivität, bis zu 1 Stunde“, und 24h „meist etwa 30 Minuten, bis zu 24 Stunden“. Beim Umstieg auf GPT-5.6 oder neuer ersetzen Sie diese Einstellung durch prompt_cache_options.ttl.

Die Token-Preise der einzelnen Modelle finden Sie in unserem Preisvergleich „Claude vs. ChatGPT: Preisvergleich“. Zu den GPT-6-Modellen (Astra, Sol, Luna) siehe „unseren Artikel zu GPT-6 Sol und Luna“, zu den aktuellen Modellen aller Anbieter „Wissensstichtage von KI-Modellen“.

3. Wann der Cache trifft: Präfix, Mindestlänge, TTL und Geltungsbereich

Das gemeinsame Präfix und die Reihenfolge der Anfrage

Auf beiden Plattformen trifft der Cache nur, wenn das Präfix bis zum Breakpoint exakt übereinstimmt. Claude liest die Anfrage von vorn in der Reihenfolge tools → system → messages; ändert man also eine einzige Tool-Definition, wird der Cache für den nachfolgenden System-Prompt und den Gesprächsverlauf ungültig. Auch OpenAI erklärt, dass Tool-Definitionen, das Ausgabeformat (text.format), der Reasoning-Aufwand (reasoning.effort) und ähnliche Einstellungen zum Präfix gehören.

In der Praxis ist der Aufbau bei beiden gleich: Was sich nicht ändert (Tool-Definitionen, Anweisungen, Dokumente), kommt nach vorn; was sich bei jeder Anfrage ändert (Datum, nutzerspezifische Daten, die Frage), ans Ende. Gespräche erweitern Sie durch Anhängen, ohne den Verlauf umzuschreiben.

Breakpoints setzen: automatisch oder manuell

Der implizite Modus von OpenAI (ab GPT-5.6) setzt einen Breakpoint ans Ende der jüngsten geeigneten Nachricht (eine Nutzernachricht, das letzte einer Reihe von Tool-Ergebnissen usw.). Im Modus „nur explizit“ werden nur die Stellen zu Breakpoints, an denen Sie prompt_cache_breakpoint einfügen, und wenn Sie keinen setzen, wird der Cache nicht genutzt und es fällt auch kein Schreibpreis an.

Das automatische Caching von Claude, das mit einem einzigen "cache_control": {"type": "ephemeral"} auf oberster Ebene aktiviert wird, setzt einen Breakpoint auf den letzten cachefähigen Block und schiebt ihn mit wachsendem Gespräch nach hinten. Fügen Sie cache_control an einzelnen Blöcken ein, wählen Sie die Breakpoints selbst.

// Claude: Breakpoint am Ende des unveränderlichen System-Prompts (expliziter Breakpoint)
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "system": [
    {
      "type": "text",
      "text": "Lange Anweisungen und Dokumente...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [{ "role": "user", "content": "Die heutige Frage..." }]
}

// OpenAI (Responses API): Breakpoint nach den unveränderlichen Anweisungen, Modus „nur explizit“
{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "Lange Anweisungen und Dokumente...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "Die heutige Frage..." }
  ]
}

Mindestlänge: Kurze Präfixe werden nicht gecacht

Für GPT-5.6 und neuer liegt das Minimum bei OpenAI bei 1,024 Tokens sichtbarer Eingabe (versteckte Anweisungen, die OpenAI im Hintergrund hinzufügt, zählen nicht). Bei Claude hängt es vom Modell ab.

Quelle: Anthropic „Prompt caching“, Cache limitations (geprüft am 3. Oktober 2026). Auf Bedrock gelten die Werte aus der AWS-Dokumentation.

Liegt ein Claude-Prompt unter dem Minimum, löst das Hinzufügen von cache_control keinen Fehler aus; der Prompt wird einfach stillschweigend nicht gecacht. In diesem Fall sind cache_creation_input_tokens und cache_read_input_tokens in usage beide 0. Das Minimum ändert sich beim Modellwechsel, sodass ein Präfix, das beim vorherigen Modell gecacht wurde, nicht mehr gecacht werden kann (der Leitfaden von OpenAI warnt genauso davor).

TTL: Achten Sie darauf, wann die Uhr startet

Bei OpenAI (ab GPT-5.6) hält der Cache „mindestens 30 Minuten nach dem letzten Schreiben oder Wiederverwenden und kann länger bestehen bleiben“. Claude nutzt standardmäßig 5 Minuten, und wer 1 Stunde wählt, zahlt für Schreibvorgänge das 2-Fache des Eingabepreises. Auf beiden Plattformen wird die TTL bei jeder Nutzung des Caches ohne Aufpreis verlängert.

Bei Claude gibt es eine Falle: Die TTL zählt ab dem Beginn der Anfrage, nicht ab dem Ende der Antwort. Im Beispiel der Dokumentation muss die nächste Anfrage, wenn das Erzeugen einer Antwort 4 Minuten dauert, innerhalb von etwa 1 Minute nach Ende dieser Antwort starten, um den 5-Minuten-Cache zu treffen. Für Agenten mit langen Ausgaben sind 5 Minuten kürzer, als sie wirken.

Geltungsbereich des Caches und wo er liegt

Der Cache von OpenAI gilt pro Organisation und wird nicht über Verarbeitungsregionen (Einstellungen zur Datenresidenz) hinweg geteilt. Laut Leitfaden liegt der Cache zudem auf einzelnen Maschinen, und ab etwa 15 Anfragen pro Minute können Anfragen an eine andere Maschine geleitet werden. Ab GPT-5.6 übernimmt OpenAI das Routing automatisch, und prompt_cache_key ist zu einer optionalen Einstellung geworden, mit der man Cache-Berichte nach Kunden trennt, statt ein Mittel zur Steigerung der Trefferquote zu sein (bei GPT-5.5 und älter war es wichtig, Anfragen mit demselben Schlüssel auf dieselbe Maschine zu lenken).

Die Claude-API begrenzt den Cache auf den Workspace. Innerhalb derselben Organisation teilen verschiedene Workspaces keinen Cache, selbst bei identischen Prompts. Auf Bedrock und Google Cloud gilt er pro Organisation. Außerdem steht der Cache erst zur Verfügung, sobald die erste Antwort beginnt: Schicken Sie viele parallele Anfragen mit demselben Präfix auf einmal, werden auch die übrigen zu Schreibvorgängen, bevor die erste den Cache geschrieben hat.

4. Preise und Break-even: wie viele Lesevorgänge, bis sich Caching lohnt

Weil ein Cache-Schreibvorgang mehr kostet als normale Eingabe, ist ein Cache-Eintrag, der geschrieben und nie gelesen wird, teurer als gar kein Caching. Sei w der Schreibmultiplikator, r der Lesemultiplikator und n die Zahl der Lesevorgänge nach dem Schreiben. Wie viele Lesevorgänge für den Break-even nötig sind, folgt aus diesen Formeln.

Mit Caching     = w + n × r
Ohne Caching    = 1 + n          (dasselbe Präfix n + 1 Mal unverändert senden)
Lohnt sich bei  : n > (w − 1) ÷ (1 − r)

Multiplikatoren bezogen auf einen Eingabepreis von 1. Berechnet nach OpenAI „Prompt caching“ und „Pricing“ sowie Anthropic „Pricing“ (geprüft am 3. Oktober 2026). Verglichen wird nur das Präfix; Ausgabe und die Frage der jeweiligen Anfrage sind ausgenommen.

Der Leitfaden von OpenAI enthält dieselbe Rechnung für ein Modell mit 0.1x: Einmal schreiben und einmal lesen kostet 1.35x, gegenüber 2x für zweimaliges Verarbeiten ohne Caching. Auch die Preisseite von Anthropic sagt, dass sich der 5-Minuten-Cache nach einem Lesevorgang lohnt und der 1-Stunden-Cache nach zwei. Wie günstig das Lesen auch ist – ein 1-Stunden-Cache kann sich mit einem einzigen Lesevorgang nicht lohnen, weil der Schreibvorgang zum 2-Fachen zu schwer wiegt.

Modelle mit gleichem Eingabepreis: Der Abstand zwischen Anfragen kehrt das Ergebnis um

Zu den offiziellen Preisen vom 3. Oktober 2026 verlangen GPT-6.1 Sol und Claude Sonnet 5.5 beide $2 pro Million Eingabe-Tokens, und ihr Schreibpreis für 5 Minuten ist mit $2.50 ebenfalls gleich. Unterschiedlich sind der Lesepreis (Sol $0.10, Sonnet 5.5 $0.20) und die TTL. Wir haben die Kosten des Präfixes berechnet, wenn ein Präfix mit 100,000 Tokens 10-mal in unterschiedlichen Abständen gesendet wird.

Preise aus OpenAI „Pricing“ (Standard, bis 272K) und Anthropic „Pricing“ (beide geprüft am 3. Oktober 2026). 100,000 Tokens = 0.1 (in Einheiten von 1 Million Tokens). Bei Treffern ist die erste Anfrage ein Schreibvorgang, die übrigen 9 sind Lesevorgänge; bei Fehltreffern sind alle 10 Schreibvorgänge. Bei OpenAI kann es auch durch das Routing zwischen Maschinen und ähnliche Faktoren zu Fehltreffern kommen, daher sind die Trefferzeilen Werte unter günstigen Bedingungen.

So ergibt GPT-6.1 Sol alle 3 Minuten „0.1 × $2.50 (ein Schreibvorgang) + 0.1 × $0.10 × 9 Lesevorgänge = $0.25 + $0.09 = $0.34“. Die Tabelle zeigt drei Dinge.

• Bei Abständen von 5 Minuten oder weniger ist der Unterschied zwischen beiden gering ($0.34 vs. $0.43). Es kommt nur auf den Lesepreis an.
• Bei Abständen von 5 bis 30 Minuten gewinnt die 30-Minuten-TTL von OpenAI. Mit der 5-Minuten-TTL von Claude wird jede Anfrage zum Schreibvorgang und kostet $2.50 – mehr als ganz ohne Cache. Mit 1 Stunde sinkt der Betrag auf $0.58.
• Ist der Abstand größer als die TTL, verliert man mit Caching Geld. Bei Anfragen alle 2 Stunden ist der Verzicht auf den Cache mit $2.00 am günstigsten. Bei Claude lassen Sie cache_control weg; bei OpenAI ab GPT-5.6 nutzen Sie den Modus „nur explizit“ ohne Breakpoints und vermeiden so die Schreibgebühr.

Vor allem gilt: Weil Caching bei OpenAI ab GPT-5.6 standardmäßig aktiv ist, kann der implizite Modus bedeuten, dass Sie selbst für Eingaben den Schreibpreis zahlen, die Sie nie wieder senden. Sendet Ihr Workload viele lange Einmal-Eingaben, prüfen Sie cache_write_tokens in usage und entscheiden Sie, ob Sie in den Modus „nur explizit“ wechseln.

Wie Caching mit anderen Preismodellen zusammenwirkt

• Batch: Die Preisliste von OpenAI enthält auch für Batch und Flex Preise für gecachte Eingabe und Cache-Schreiben (GPT-6.1 Sol im Batch: Eingabe $1, Cache-Lesen $0.05, Cache-Schreiben $1.25). Anthropic gibt an, dass die Cache-Multiplikatoren mit dem Batch-Rabatt von 50 % kombiniert werden, beschreibt Cache-Treffer aber als „best effort“ (ohne Garantie), da Batch-Anfragen parallel und in keiner festen Reihenfolge verarbeitet werden.
• Lange Eingaben: Bei OpenAI verdoppeln sich die Preise für Eingabe, Cache-Lesen und Cache-Schreiben, sobald die Eingabe 272K Tokens überschreitet (die Multiplikatoren bleiben gleich). Bei Anthropic berechnen Claude 4.6 und neuere Modelle bis 1 Million Tokens denselben Preis.
• Vorwärmen: Bei beiden wird ein Vorwärm-Schreibvorgang zum normalen Schreibpreis abgerechnet. max_tokens: 0 bei Claude verursacht keine Ausgabekosten.

5. Warum Prompt-Caching nicht greift: häufige Ursachen

Kombiniert man die Hinweise beider Anbieter zu typischen Fallstricken mit den Listen der Gründe, die ihre Diagnosefunktionen liefern, lassen sich die Ursachen für Fehltreffer grob in drei Gruppen einteilen.

Häufige Probleme bei OpenAI

• Kein Breakpoint direkt nach dem gemeinsamen Präfix: Der implizite Modus setzt den Breakpoint ans Ende der neuesten Nachricht; bei „festen Anweisungen + jedes Mal anderer Nutzernachricht“ wird daher auch der veränderliche Teil geschrieben, und die nächste Anfrage verfehlt den Cache. Setzen Sie direkt nach dem festen Teil einen expliziten Breakpoint.
• Mittendrin in den Modus „nur explizit“ wechseln: Dieser Modus sucht nur nach den Breakpoints, die Sie gesetzt haben, und trifft daher keine Cache-Einträge, die im impliziten Modus geschrieben wurden.
• An dieselbe Nachricht anhängen: Wird aus einer Nachricht, die mit „Inhalt A“ endete, „Inhalt A + Inhalt B“, liegt der frühere Breakpoint mitten in einer Nachricht, und der Cache verfehlt. Fügen Sie neuen Inhalt als neue Nachricht hinzu.
• Mittendrin den Reasoning-Aufwand ändern: Bei GPT-6-Modellen können Sie den Aufwand ändern, ohne den Cache zu brechen, indem Sie reasoning.effort in der Anfrage unverändert lassen und nach der Eingabe ein configuration_update anhängen.
• Compaction (Kontextkomprimierung) ausführen: Das Präfix ändert sich, also sinkt die Trefferquote. Der Leitfaden merkt jedoch an, dass die Gesamtkosten trotzdem sinken können, weil die Eingabe schrumpft, und rät, die Gesamtkosten zu vergleichen.

Häufige Probleme bei Claude

• Ein Breakpoint auf einem Block, der sich jedes Mal ändert: Geschrieben wird nur an Breakpoint-Positionen, und beim Lesen wird nur rückwärts nach früheren Schreibpositionen gesucht. Liegt ein Breakpoint auf einem Block, der sich jedes Mal ändert, zahlen Sie jedes Mal den Schreibpreis und erzielen nie einen Treffer. Auch das automatische Caching setzt seinen Breakpoint auf den letzten Block und tappt in dieselbe Falle. Setzen Sie einen expliziten Breakpoint auf den letzten Block, der sich nicht ändert.
• 20 oder mehr Blöcke in einem Zug hinzugefügt: Die Suche nach früheren Schreibvorgängen reicht von einem Breakpoint aus bis zu 20 Positionen zurück. Wächst das Gespräch auf einmal stark, liegt der frühere Schreibvorgang außerhalb dieses Fensters. Halten Sie weiter vorn im Prompt einen zusätzlichen Breakpoint vor.
• Den System-Prompt mittendrin umschreiben: Bei unterstützten Modellen können Sie Anweisungen ergänzen, ohne den Cache zu brechen, indem Sie das system auf oberster Ebene unverändert lassen und innerhalb von messages eine Nachricht mit "role": "system" hinzufügen.
• Zwischen Fast Mode (speed: "fast") und Standard wechseln: Das macht den Cache für System-Prompt und Gespräch ungültig.

6. Cache-Treffer prüfen: usage und Diagnose

Beginnen Sie mit usage: input_tokens bedeutet Verschiedenes

Auf beiden Plattformen zeigt usage in der Antwort, wie viel aus dem Cache gelesen und wie viel hineingeschrieben wurde. Zu beachten ist, dass input_tokens auf beiden Plattformen Gegensätzliches bedeutet.

Quellen: OpenAI „Prompt caching“, Monitor cache performance; Anthropic „Prompt caching“, Tracking cache performance (geprüft am 3. Oktober 2026)

Teilen Sie durch input_tokens von Claude, als wäre es die gesamte Eingabe, liegen Trefferquote und Kosten deutlich daneben. Wenn Sie die Zahlen beider Anbieter in dasselbe Dashboard bringen, normalisieren Sie die Summen vor dem Vergleich mit den obigen Formeln. Der Leitfaden von OpenAI empfiehlt, die „Token-Trefferquote“ als Summe der aus dem Cache gelesenen Tokens geteilt durch die Summe der Eingabe-Tokens zu berechnen, aggregiert nach Nutzer, Tag usw.

Für die Kosten gilt bei OpenAI „(Eingabe − Lesen − Schreiben) × Preis + Lesen × Preis × 0.1 + Schreiben × Preis × 1.25“ und bei Claude „input_tokens × Preis + Lesen × Preis × 0.1 + Schreiben × Preis × 1.25 (2 für den 1-Stunden-Anteil)“ (ersetzen Sie den Lesemultiplikator je nach Modell durch 0.05 oder einen anderen Wert). OpenAI bietet auf seiner Nutzungsseite ein „Prompt Caching Dashboard“, und die Rate-Limits-Dokumentation von Anthropic verweist für die Cache-Trefferquote auf die Usage-Seite.

Was Sie der Reihe nach prüfen, wenn die Lesevorgänge bei 0 liegen

1. Sind die Schreibvorgänge ebenfalls 0? Bei Claude heißt das, wenn beide 0 sind: Der Prompt liegt unter der Mindestlänge oder cache_control fehlt. Bei OpenAI im Modus „nur explizit“ wird ebenfalls nichts geschrieben, wenn Sie keinen Breakpoint gesetzt haben.
2. Erscheinen bei jeder Anfrage Schreibvorgänge? Der Breakpoint liegt an einer Stelle, die sich jedes Mal ändert, oder im Präfix ändert sich jedes Mal etwas. Finden Sie mit der unten beschriebenen Diagnose heraus, was sich geändert hat.
3. Wie viel Zeit ist seit der vorherigen Anfrage vergangen? Prüfen Sie, ob die 5 Minuten von Claude (inklusive Generierungszeit der Antwort) oder die 30 Minuten von OpenAI überschritten wurden.

Diagnose bei OpenAI: prompt_cache_diagnostics

In der Responses API von OpenAI legt bei unterstützten Modellen ab GPT-5.6 die Angabe der ID einer früheren Antwort in prompt_cache_options.comparison_response_id das Ergebnis des Vergleichs dieser Anfrage mit der aktuellen in prompt_cache_diagnostics ab. Laut Dokumentation kostet das nichts extra und zählt nicht gesondert zu den Rate Limits.

// Der zweiten Anfrage ein Vergleichsziel hinzufügen
{
  "model": "gpt-6.1-sol",
  "input": [ ...gleiches Präfix wie die erste Anfrage..., { "role": "user", "content": "Nächste Frage" } ],
  "prompt_cache_options": { "comparison_response_id": "resp_(ID der ersten Antwort)" }
}

// Beispiel für die Rückgabe bei einem Fehltreffer (Beispiel aus der Dokumentation: ein Tool wurde umbenannt)
{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

type hat vier Werte: cache_hit, cache_miss, comparison_response_not_found (kein Vergleichsdatensatz oder abgelaufen) und unavailable (keine Aussage möglich). Bei einem Fehltreffer ist reason einer dieser neun Werte.

Quelle: OpenAI „Prompt cache diagnostics“, Fix a cache miss (geprüft am 3. Oktober 2026)

Diagnose bei Claude: diagnostics

In der Claude-API müssen Sie in jede Anfrage ein Feld diagnostics aufnehmen, denn die API speichert einen Vergleichs-Fingerprint (Hashes und geschätzte Token-Zahlen) nur für Anfragen, die es enthalten. Übergeben Sie im ersten Zug "previous_message_id": null, danach die id der vorherigen Antwort.

// Ab dem zweiten Zug
{
  "model": "claude-sonnet-5-5",
  "max_tokens": 1024,
  "cache_control": { "type": "ephemeral" },
  "diagnostics": { "previous_message_id": "msg_(id der vorherigen Antwort)" },
  "system": "...",
  "messages": [ ... ]
}

Ist diagnostics in der Antwort null, wurde kein Unterschied gefunden (oder kein Vergleich durchgeführt); {"cache_miss_reason": null} bedeutet, dass der Vergleich noch nicht abgeschlossen ist; und ist ein Grund angegeben, markiert er die erste Stelle, an der die Anfragen voneinander abweichen. Es gibt sechs Gründe: model_changed, system_changed, tools_changed, messages_changed, previous_message_not_found und unavailable. Die *_changed-Gründe werden von cache_missed_input_tokens begleitet, einer Schätzung, wie viel verloren ging.

Die Dokumentation von Claude empfiehlt, die Diagnose zusammen mit cache_read_input_tokens zu lesen.

Quelle: Anthropic „Cache diagnostics“, Reading diagnostics alongside usage (geprüft am 3. Oktober 2026)

Die beiden Diagnosefunktionen haben viel gemeinsam: Beide liefern nur den ersten gefundenen Unterschied, nach dessen Behebung muss man also erneut vergleichen. Die Unterschiede: Die Diagnose von Claude funktioniert nur in der Claude-API (nicht auf Amazon Bedrock, Google Cloud, Claude Platform on AWS oder Microsoft Foundry) und vergleicht nur mit Anfragen aus demselben Workspace. Die Dokumentation von OpenAI beschreibt keinen Schritt, mit dem die frühere Vergleichsanfrage vorab markiert werden müsste. Enthielt bei Claude die frühere Anfrage nicht ebenfalls diagnostics, erhalten Sie previous_message_not_found.

7. Zahlen zur Trefferquote: Beispiele der Anbieter und Daten von Dritten

Die kursierenden Zahlen zur Cache-Trefferquote bedeuten sehr Unterschiedliches, je nachdem, wer sie unter welchen Bedingungen veröffentlicht hat. Hier sind sie getrennt aufgeführt.

Zahlen der Anbieter

• Beispiele im Leitfaden von OpenAI: Ein einmaliger Bewertungs-Workload (ein LLM als Bewerter) mit einem expliziten Breakpoint nach einem festen Bewertungsschema erreichte eine „Token-Trefferquote von etwa 70 %“, ein Agent, der wiederholt Tools aufruft, „über 90 %“. Der Leitfaden betont, dass dies Beispiele möglicher Ergebnisse sind und die Obergrenze vom Workload abhängt.
• Kundenstimmen in der Ankündigung von OpenAI (22. September 2026): Das Manus-Team berichtet, dass seine Trefferquote auf OpenAI-Modellen nach einer Überarbeitung der Breakpoint-Platzierung in weniger als einer Woche von „etwa 85 % auf konstant über 90 %“ stieg. Eine Stimme zu GitHub Copilot besagt, dass der Anteil der Eingabe, der neu verarbeitet werden muss, in den vergangenen Monaten gegenüber der früheren Basislinie um mehr als 50 % gesunken ist. Beides sind Kundenzitate, die OpenAI auf seiner eigenen Seite veröffentlicht hat, keine unabhängigen Messungen.
• Anthropic: Die Dokumentation nennt keine realen Trefferquoten. Die Seite Rate limits enthält ein Rechenbeispiel – „bei einer Trefferquote von 80 % verarbeitet ein Eingabelimit von 2 Millionen Tokens pro Minute effektiv 10 Millionen Tokens pro Minute“ –, doch das ist Arithmetik auf Basis einer Annahme, keine Messung.

Daten von Dritten: kein direktes Urteil, wer besser ist

Requesty, ein Dienst, der Anfragen an mehrere KI-APIs weiterleitet, hat die Anfragen ausgewertet, die über sein eigenes Gateway liefen, und für April 2026 Trefferquoten von 77 % für Anthropic direkt (77.50 % in der Tabelle) und 36 % für OpenAI (36.40 %) veröffentlicht („Prompt-cache hit rate per provider, April 2026“, aktualisiert am 9. Mai). Auf den ersten Blick scheint Claude mehr als doppelt so oft zu treffen, doch aus vier Gründen lassen sich diese Zahlen nicht für den Vergleich in diesem Artikel verwenden.

1. Die Daten stammen aus der Zeit vor der Änderung bei OpenAI: OpenAI führte die 30-minütige Aufbewahrung und explizite Breakpoints am 22. September ein; die April-Daten liegen davor.
2. Die Workloads unterscheiden sich: Es handelt sich um Ergebnisse von Apps verschiedener Nutzer, die über das Gateway unterschiedliche Prompts in unterschiedlichen Abständen senden – nicht um denselben Prompt, der an beide Anbieter ging. Bei Claude zählen nur Anfragen, in die die Nutzer selbst cache_control eingefügt haben.
3. Der Nenner: Die Seite nennt „cached_tokens ÷ input_tokens“, doch wie in Abschnitt 6 erklärt, schließt input_tokens bei Claude gecachte Tokens aus. Wie die Seite umgerechnet hat, sagt sie nicht.
4. Die Seite widerspricht sich selbst: An einer Stelle setzt sie Claude über Google Cloud (Vertex) bei 24 % an, an einer anderen bei 14 %.

Bei unserer Suche am 3. Oktober 2026 fanden wir keine Messung von Dritten, die beide Caches unter gleichen Bedingungen verglichen hätte. Letztlich gilt: Ob Caching in Ihrer App greift, erfahren Sie nur, wenn Sie es in Ihren eigenen Nutzungsdaten messen. Berechnen Sie Trefferquote und Kosten mit den Formeln aus Abschnitt 6, und finden Sie bei Fehltreffern mit der Diagnose die Ursache.

Fazit

Prompt-Caching bei OpenAI und Claude beruht auf derselben Grundidee: das identische Präfix wiederverwenden und Lesevorgänge mit etwa dem 0.1-Fachen des Eingabepreises abrechnen. Der Unterschied: OpenAI (ab GPT-5.6) ist standardmäßig aktiv, hält den Cache mindestens 30 Minuten und berechnet für Schreibvorgänge das 1.25-Fache, während Claude nur cacht, wenn Sie cache_control hinzufügen, den Cache 5 Minuten hält (optional 1 Stunde) und für Schreibvorgänge das 1.25-Fache berechnet (2-Fache für 1 Stunde).

Beim Preis gilt: Weil Schreiben extra kostet, ist ein Cache, der nie gelesen wird, ein Verlust. 5- und 30-Minuten-Caches lohnen sich nach einem Lesevorgang, der 1-Stunden-Cache von Claude nach zweien. Bei Abständen von 5 bis 30 Minuten zwischen Anfragen hat die 30-Minuten-TTL von OpenAI die Nase vorn, und bei Claude verhindert die Wahl von 1 Stunde die Umkehrung. Liegen Ihre Anfragen weiter auseinander als die TTL, ist der Verzicht auf Caching günstiger.

Ob Caching greift, prüfen Sie anhand der Lese- und Schreibmengen in usage. input_tokens umfasst bei Claude nur, was nach dem Breakpoint kommt; berechnen Sie also zuerst die Summe und dann die Trefferquote. Bei Fehltreffern zeigen prompt_cache_diagnostics von OpenAI und diagnostics von Claude, worin sich die Anfrage von der vorherigen unterscheidet. Weitere Wege, Kosten zu senken, finden Sie in „KI-Kosten und Tokens sparen“.

FAQ

F. Wie lang ist die TTL beim Prompt-Caching von OpenAI?

A. Ab GPT-5.6 mindestens 30 Minuten nach dem letzten Schreiben oder Wiederverwenden. Die Einstellung prompt_cache_options.ttl akzeptiert nur "30m", und laut Leitfaden kann der Cache länger bestehen bleiben. Bei GPT-5.5 und älter wählen Sie mit prompt_cache_retention: in_memory hält etwa 5 bis 10 Minuten Inaktivität (bis zu 1 Stunde), 24h bis zu 24 Stunden.

F. Lässt sich die TTL beim Prompt-Caching von Claude verlängern?

A. Ja, "cache_control": {"type": "ephemeral", "ttl": "1h"} ergibt 1 Stunde. Schreibvorgänge kosten das 2-Fache des Eingabepreises, daher lohnt es sich erst, wenn der Cache mindestens zweimal gelesen wird. Nutzen Sie ihn weiter in Abständen unter 5 Minuten, wird der 5-Minuten-Cache bei jedem Lesevorgang kostenlos verlängert. Beide zählen ab dem Beginn der Anfrage, sodass die Zeit zum Erzeugen einer langen Antwort in die TTL eingeht.

F. Verändert Caching die Antworten?

A. Nein. Die Dokumentation beider Anbieter besagt, dass Caching die Erzeugung der Ausgabe nicht beeinflusst. Gespeichert wird die Zwischenberechnung beim Lesen der Eingabe, nicht die Antwort selbst. Wie ohne Caching liefert dieselbe Eingabe nicht immer dieselbe Antwort.

F. Kann ich den Cache manuell leeren?

A. Auf keiner der beiden Plattformen. OpenAI erklärt, dass Einträge gemäß TTL und Einstellungen ablaufen, Anthropic, dass sie nach mindestens 5 Minuten ohne Nutzung automatisch entfernt werden (nach 1 Stunde, wenn Sie 1 Stunde gewählt haben). Wollen Sie den Inhalt des Prompts ersetzen, ändern Sie das Präfix – die nächste Anfrage schreibt dann einen neuen Eintrag.

Quellen

• OpenAI-API-Dokumentation: Prompt caching
• OpenAI-API-Dokumentation: Prompt cache diagnostics
• OpenAI-API-Dokumentation: Pricing
• OpenAI: Better prompt caching for GPT-6 (22. September 2026)
• Claude-Platform-Dokumentation: Prompt caching
• Claude-Platform-Dokumentation: Cache diagnostics
• Claude-Platform-Dokumentation: Pricing
• Claude-Platform-Dokumentation: Rate limits
• Requesty: Prompt-cache hit rate per provider, April 2026

Alle Quellen wurden am 3. Oktober 2026 im Original geprüft. Preise, TTLs und Mindestlängen können sich mit neuen Modellen ändern; prüfen Sie sie daher vor Verwendung auf der Preisseite des jeweiligen Anbieters. Die Kostenrechnungen in diesem Artikel sind Arithmetik auf Basis der offiziellen Preise, keine Messungen aus eigenen API-Aufrufen.