GPT-6 Prompt-Caching: 90 % Rabatt auf gecachte Reads – und wie du echte Cache-Hits erzielst

Jede Agent-Schleife, die du ausführst, sendet dieselbe Eröffnung erneut. Der System-Prompt, die Tool-Definitionen, die OpenAPI-Spezifikation, die Repo-Konventionen. Das Modell hat dieses Präfix heute schon hundert Mal gesehen – und du hast jedes einzelne Mal den vollen Input-Preis dafür bezahlt.

Probier Apidog noch heute aus

Im großen Maßstab wird diese Rechnung laut. OpenAI sagt, dass sein eigener Median-Forscher über 600 $ pro Tag für Coding-Agents ausgibt, und das 90. Perzentil gibt 7.000 $ pro Tag aus. Das sind Leute, die interne Tools eines Labors betreiben, nicht eine Produktions-API, die Kunden bedient.

Zusammen mit GPT-6 Sol und GPT-6 Luna hat OpenAI am 22. September 2026 ein Prompt-Caching-Release veröffentlicht, das genau darauf abzielt: Gecachte Input-Reads werden mit 90 % Rabatt berechnet, die Trefferraten sind standardmäßig höher, zwei der häufigsten cache-zerstörenden Änderungen zerstören den Cache nicht mehr, du kannst explizite Breakpoints setzen, und es gibt jetzt ein Prompt Caching Dashboard plus ein Diagnose-Tool, um zu sehen, was tatsächlich passiert. GitHub, das dies in Produktion einsetzt, meldet über alle Milliarden von Anfragen hinweg mehr als 50 % weniger Prompt-Tokens, die eine Neuverarbeitung benötigen.

Dieser Leitfaden behandelt, was sich geändert hat, was der Rabatt in echtem Geld wert ist, wie du einen Prompt aufbaust, damit der Cache tatsächlich trifft, und wie du testest, dass er weiterhin trifft, nachdem jemand deinen System-Prompt refaktoriert hat.

Was veröffentlicht wurde

Änderung	Was es für deinen Code bedeutet
90 % Rabatt auf gecachte Input-Reads	Das wiederholte Präfix wird zu einem Zehntel des Input-Preises berechnet
Höhere Trefferraten standardmäßig	Bestehende Integrationen erhalten einen Teil davon ohne Codeänderung
Ändern des Reasoning-Aufwands zerstört den Cache nicht mehr	Du kannst mitten in der Sitzung von low auf max hochstufen und das Präfix warm halten
Ändern der Tool-Verfügbarkeit zerstört den Cache nicht mehr	Füge ein Tool hinzu oder entferne es, ohne für ein kaltes Präfix zu bezahlen
Explizite Breakpoints	Du entscheidest, wo das gecachte Präfix endet, anstatt zu raten
Prompt Caching Dashboard und ein Diagnose-Tool	Die Trefferrate wird etwas, das du misst, nicht etwas, das du annimmst

Die ersten drei sind für Agents am wichtigsten. Der letzte ist am wichtigsten für den Ingenieur, der die Rechnung des letzten Monats erklären muss.

Die Arithmetik

Prompt-Caching betrifft nur Input-Tokens. Die Output-Preisgestaltung ändert sich nicht, daher wird ein Agent, der lange Antworten auf einen kurzen Prompt schreibt, es kaum bemerken. Ein Agent, der einen großen stabilen Kontext liest und ein kurzes Urteil ausgibt, wird es stark bemerken.

Hier ist, was der Rabatt mit den veröffentlichten Preisen für die beiden neuen Modelle macht:

Modell	Input pro 1M	Gecachter Read pro 1M	Output pro 1M	Kontext
GPT-6 Sol (gpt-6-sol)	$2.00	$0.20	$10.00	872k
GPT-6 Luna (gpt-6-luna)	$0.10	$0.01	$0.50	1M

Die Spalte „Gecachter Read“ ist der 90-%-Rabatt, angewendet auf den veröffentlichten Input-Preis. Bestätige ihn auf der aktuellen Preisseite, bevor du darauf ein Budget aufbaust.

Nun eine konkrete Arbeitslast. Angenommen, du betreibst einen Code-Review-Agenten: 40.000 Tokens stabiles Präfix (System-Prompt, Tool-Schemata, das OpenAPI-Dokument des Dienstes, deine API-Konventionen) plus etwa 2.000 Tokens Diff pro Durchlauf, 500 Durchläufe pro Tag.

	Sol, keine Cache-Treffer	Sol, Präfix gecacht	Luna, keine Cache-Treffer	Luna, Präfix gecacht
Präfix-Tokens pro Tag	20M bei $2.00 = $40.00	20M bei $0.20 = $4.00	20M bei $0.10 = $2.00	20M bei $0.01 = $0.20
Frische Tokens pro Tag	1M bei $2.00 = $2.00	1M bei $2.00 = $2.00	1M bei $0.10 = $0.10	1M bei $0.10 = $0.10
Tägliche Input-Kosten	$42.00	$6.00	$2.10	$0.30

Das sind ungefähr 86 % weniger Input-Rechnung bei Sol für eine Arbeitslast, die ihre Form überhaupt nicht geändert hat. Das Einzige, was sich geändert hat, ist, ob das Präfix zwischen Aufrufen byte-identisch blieb.

Erwähnenswert daneben: Claude Opus 5.5 listet gecachte Reads mit $0.20 pro Million gegenüber $4.00 Input, mit Cache-Writes bei $5.00 pro Million. Der Read-Preis landet an derselben Stelle wie bei Sol, und Anthropic berechnet einen expliziten Aufpreis für das Schreiben des Caches. OpenAI's Launch nennt keine Cache-Write-Rate für Sol oder Luna, was eine der offenen Fragen am Ende dieses Artikels ist. Wenn du ganze Rechnungen vergleichst statt einzelner Zahlen, bringt unsere September 2026 Modell-Preiskrieg-Aufschlüsselung alle drei Launches in einer Tabelle unter.

Warum Cache-Fehltreffer normalerweise deine eigene Schuld waren

Prompt-Caching gleicht auf einem Präfix ab. Der Cache ist auf den führenden Token-Lauf in deiner Anfrage geschlüsselt, daher invalidiert das erste Byte, das sich vom vorherigen Aufruf unterscheidet, alles danach. Ein Zeichen an der falschen Stelle kostet dich den gesamten Rabatt auf 40.000 Tokens. Die klassischen Übeltäter, in grober Reihenfolge ihrer Häufigkeit in echtem Code:

• Ein Zeitstempel, eine Request-ID oder Trace-ID, die in den System-Prompt eingefügt wird.
• Der Name des Benutzers, die Org-ID oder das Locale, platziert über den statischen Anweisungen statt darunter.
• Abgerufener Kontext, der vor den Tool-Definitionen eingefügt wird, sodass jeder neue Abruf das gesamte Präfix verschiebt.
• Ein Tool-Array, das aus einem Set oder Dictionary aufgebaut ist, sodass die JSON-Schlüsselreihenfolge zwischen Prozessen wechselt.
• Few-Shot-Beispiele, die pro Anfrage zur Abwechslung rotiert werden.

Zwei weitere standen früher auf dieser Liste und sind jetzt nicht mehr darauf. Das Ändern des Reasoning-Aufwands zerstört den Cache nicht mehr, sodass ein Agent, der bei den einfachen Turns mit low läuft und beim schwierigen auf max hochstuft, sein warmes Präfix über die Hochstufung hinweg behält. Das Ändern der Tool-Verfügbarkeit zerstört ihn ebenfalls nicht mehr, sodass das Absichern eines gefährlichen Tools hinter einer Berechtigungsprüfung nicht mehr einen kalten Read von allem darüber erzwingt. Diese beiden Muster sind in Agent-Frameworks extrem verbreitet, und bis jetzt haben sie den Cache stillschweigend genau bei den Turns auf null gesetzt, die am meisten kosteten.

Baue den Prompt auf: stabil zuerst, volatil zuletzt

Die Disziplin überlebt jede zukünftige Preisänderung: Sortiere deinen Kontext danach, wie oft er sich ändert – das Stabilste oben.

1. System- oder Developer-Anweisungen, die für jeden Benutzer identisch sind.
2. Tool- und Funktions-Schemata, in fester Reihenfolge serialisiert.
3. Langes gemeinsames Referenzmaterial: das OpenAPI-Dokument, der Styleguide, das Datenbankschema.
4. Mandanten- oder projektspezifischer Kontext, der sich selten ändert.
5. Abgerufene Chunks, die sich pro Abfrage ändern.
6. Der User-Turn und alles, was eine Uhr enthält.

Die Ebenen eins bis drei sind dein Cache. Wenn ein Zeitstempel im Prompt sein muss, setze ihn in den User-Turn, nicht in die System-Nachricht. Wenn deine Tool-Liste dynamisch zusammengestellt wird, sortiere sie und friere die JSON-Schlüsselreihenfolge ein, damit zwei Prozesse sie identisch serialisieren.

from openai import OpenAI

client = OpenAI()

STATIC_PREFIX = [
    {"role": "developer", "content": SYSTEM_INSTRUCTIONS},   # never changes
    {"role": "developer", "content": OPENAPI_DOCUMENT},      # changes on deploy
]

response = client.responses.create(
    model="gpt-6-sol",
    reasoning={"effort": "low"},
    tools=SORTED_TOOL_SCHEMAS,
    prompt_cache_key="review-agent:v7",
    input=STATIC_PREFIX + [
        {"role": "user", "content": f"Review this diff:\n{diff}"},  # volatile, last
    ],
)

print(response.usage)

Die expliziten Breakpoints in diesem Release lassen dich markieren, wo dieses gecachte Präfix endet, anstatt dich darauf zu verlassen, dass die Plattform es ableitet. Das ist am nützlichsten, wenn Ebene vier groß ist: ein mandantenspezifischer Block, der für einen Kunden stabil und für den nächsten anders ist, wo du die Grenze bewusst gezogen haben willst, statt bei dem Token, den die Heuristik ausgewählt hat.

Versioniere den Cache-Schlüssel selbst, wie in review-agent:v7 oben. Wenn du das Präfix absichtlich änderst, erhöhe die Version, und du wirst die kalte Phase in deinen Metriken sehen, anstatt dich zu fragen, warum die Kosten gesprungen sind.

Verifiziere es, nimm es nicht an

Das Usage-Objekt in jeder Antwort sagt dir, wie viele Input-Tokens aus dem Cache bedient wurden. Lies es, protokolliere es und alarmiere darauf. Eine grobe Form:

usage = response.usage
cached = usage.input_tokens_details.cached_tokens
total_in = usage.input_tokens

print(f"cache hit rate: {cached / total_in:.0%}  billed fresh: {total_in - cached}")

Feldnamen in den obigen Snippets stammen aus den aktuellen OpenAI-API-Formen und nicht aus der Launch-Ankündigung – überprüfe sie also anhand der Referenz, bevor du auslieferst. Das Prinzip ändert sich nicht: Die Antwort sagt dir die Wahrheit, also setze diese Zahl auf ein Dashboard.

Das neue Prompt Caching Dashboard und das Diagnose-Tool decken die Flottenansicht ab, wo du das Muster erkennen wirst, das GitHub meldet: mehr als 50 % der Prompt-Tokens, die über Milliarden von Anfragen hinweg keine Neuverarbeitung mehr benötigen. Das ist eine plattformweite Messung, und der einzige Weg, deine eigene Zahl zu kennen, ist, sie zu messen.

Der Fehlermodus ist still. Nichts schlägt fehl, wenn der Cache aufhört zu treffen. Ein Teammitglied fügt eine Request-ID zum Debuggen in den System-Prompt ein, das Präfix wird kalt, und das einzige Signal ist eine langsam steigende Zeile auf der Rechnung drei Wochen später.

Das macht es zu einem Regressionstest, nicht zu einem Monitoring-Problem. Behandle den Modell-Endpunkt wie jede andere API, von der du abhängst: Speichere die Anfrage in Apidog, stelle sicher, dass usage.input_tokens_details.cached_tokens beim zweiten Aufruf in einem Szenario einen Mindestwert überschreitet, und führe es geplant in CI aus. Zwei Aufrufe nacheinander – einer zum Aufwärmen und einer zum Prüfen – sind der ganze Test, und ein Prompt-Refactoring, das den Cache zerstört, schlägt dann im Pull Request fehl statt auf der Rechnung.

Die Latenz-Fußnote

Caching reduziert die Arbeit, die vor dem ersten Token erledigt wird, also hilft es normalerweise sowohl der Zeit bis zum ersten Token als auch den Kosten. Erwarte nicht, dass es die Reasoning-Modi rettet.

Artificial Analysis, ein Drittanbieter, misst die Zeit bis zum ersten Token mit 102,15 Sekunden für GPT-6 Sol und 124,23 Sekunden für GPT-6 Luna bei ihren „max“-Reasoning-Varianten. Das sind nicht die Zahlen, die du bei low-Aufwand sehen wirst, und es sind keine Herstellerzahlen – behandle sie also als richtungsweisend. Der Punkt bleibt so oder so bestehen: Kein Caching-Rabatt verwandelt ein Zwei-Minuten-Denkbudget in ein interaktives. Miss die Latenz pro Aufwandsstufe, bevor du eine Antwortzeit versprichst. Unser GPT-6 Astra API-Leitfaden behandelt die Aufwandsstufen ausführlicher.

Was der Launch nicht beantwortet

Vier Dinge sind es wert, bestätigt zu werden, bevor du ein Design darauf festlegst:

• Ob Cache-Writes bei Sol und Luna eine Gebühr tragen – und zu welchem Satz.
• Wie lange ein gecachtes Präfix ohne Verkehr lebt und ob die Retention-Kontrollen aus der GPT-5.6-Ära unverändert übernommen werden.
• Ob der gecachte Read-Preis von GPT-6 Astra auf denselben 90-%-Rabatt gesenkt wurde, da das Launch-Material die neuen Modelle abdeckt.
• Der genaue Parametername für explizite Breakpoints, den die Ankündigung eher nach Fähigkeit als nach Feld beschreibt.

Keines davon blockiert die Layout-Arbeit. Stabile-zuerst-Reihenfolge, ein versionierter Cache-Schlüssel und eine Zusicherung zu gecachten Tokens zahlen sich unter jeder der Antworten aus.

Die Kurzfassung

Sortiere deinen Prompt nach Volatilität und halte die Uhr aus der System-Nachricht heraus. Versioniere den Cache-Schlüssel, damit absichtliche Änderungen sichtbar sind. Lies cached_tokens in jeder Antwort und lege in CI einen Mindestwert darunter. Stufe den Reasoning-Aufwand hoch und schalte Tools jetzt frei nach Belieben um – keines von beiden kostet dich mehr das Präfix. Für Hintergrundinformationen zum Mechanismus selbst behandelt unser Erklärstück zu wie Prompt-Caching funktioniert die Grundlagen.

Die Preise für diese Modelle werden sich wieder ändern. Das tun sie immer. Prompt-Layout-Disziplin ist der Teil, der sich weiter auszahlt, nachdem der nächste Launch jede Zahl in der Tabelle zurücksetzt.