OpenAI-Prompt-Caching für 12 Stunden: Lohnt sich der 2.5×-Preis?

Nutze OpenAIs 12-Stunden-Prompt-Cache für ein unverändertes Präfix, das ein Agent nach längeren Pausen erneut verwendet; wechselnde Sitzungsinhalte bleiben bei 30m oder außerhalb der Cache-Schreibvorgänge. Wenn mit 30m bei jeder Anfrage neu geschrieben werden muss, ist die Variante mit einem einzigen 12h-Schreibvorgang ab der dritten Anfrage insgesamt günstiger, also bei der zweiten Wiederverwendung, sofern das Präfix weiterhin übereinstimmt. Erzielt 30m bereits durchgehend Treffer, erhöht die längere Laufzeit die Kosten, ohne den Lesepreis zu senken.

Was kosten 30m und 12h?

Mit 12h gelten die günstigeren Preise für Eingaben aus dem Cache länger; dafür kostet das Schreiben doppelt so viel wie mit der Standardlaufzeit. OpenAIs API-Changelog vom 20. Oktober 2026 stellte die Option für Responses vor. Der Leitfaden zum Prompt-Caching dokumentiert die folgenden Regeln für GPT-5.6 und neuere Modelle, geprüft mit Stand 2026-10-24.

Eingabekosten	Faktor gegenüber normaler Eingabe	GPT-6.1 Sol, USD pro 1M tokens
Normale Eingabe	1×	$2.00
Schreiben mit `30m`, Standard	1.25×	$2.50
Schreiben mit `12h`	2.5×	$5.00
Cache-Lesezugriff, bei beiden Laufzeiten	0.1× bei den meisten Modellen; 0.05× bei GPT-6.1 Sol	$0.10

Das sind die vollständigen Schreibpreise. Ein mit 12h in den Cache geschriebenes Token kostet 2.5× den normalen Eingabepreis; es wird nicht zusätzlich zum normalen Eingabepreis noch einmal 2.5× berechnet.

Die Dollarspalte verwendet die aktuellen Standard-Preise von OpenAI für gpt-6.1-sol, bei Prompts mit höchstens 272K Eingabetokens und ohne Aufschlag für regionale Verarbeitung. Der Ausgabepreis beträgt $10.00 pro 1M tokens. Längere Prompts, andere Service-Tiers und regionale Verarbeitung können die Preise verändern. Prüfe deshalb die zutreffenden Preisbedingungen des Modells, bevor du die folgenden Berechnungen übernimmst.

Das wiederverwendbare Präfix muss mindestens 1,024 sichtbare Eingabetokens enthalten. Eine große Anfrage mit einem kurzen unveränderten Anfang macht diesen Anfang nicht automatisch für das Caching geeignet.

Wann lohnt sich der höhere Schreibpreis?

Zähle die Schreibvorgänge, die du durch die längere Gültigkeit vermeidest. Dabei bezeichnet B die normalen Eingabekosten deines unveränderten Präfixes, n die Gesamtzahl der Anfragen, r den Lesepreisfaktor und k die Anzahl der 30m-Schreibvorgänge einschließlich des ersten.

Wenn jeder Schreibvorgang oder Cache-Treffer das gesamte Präfix abdeckt und auf einen 12h-Schreibvorgang erfolgreiche Lesezugriffe folgen, gilt:

12h cost = B × [2.5 + (n - 1) × r]
30m cost = B × [1.25 × k + (n - k) × r]
No-cache cost = B × n

Sowohl bei r = 0.1 als auch bei r = 0.05 ist der langlebige Cache ab n = 3 günstiger als Eingaben ohne Cache. Gegenüber dem Standardcache wird er bei k >= 3 günstiger, solange die 12h-Variante weiterhin nur einen Schreibvorgang benötigt. Entscheidend ist also, zwei weitere Schreibvorgänge mit kurzer Laufzeit zu vermeiden. Eine hohe Zahl von Treffern allein reicht nicht.

Schreiben beide Varianten einmal und erzielen anschließend bei jeder Anfrage einen Treffer, bleibt 12h um 1.25 × B teurer. Bei häufigen interaktiven Dialogen gibt es daher wenig Grund, den höheren Schreibpreis zu bezahlen, sofern keine Pausen auftreten, nach denen erneut geschrieben werden muss.

Eine Pause von mehr als 30 Minuten eröffnet eine Sparmöglichkeit, beweist aber keinen Cache-Miss. OpenAI kann Einträge länger als die Mindestlaufzeit vorhalten, und ein 30m-Lesezugriff erneuert die Gültigkeit für mindestens weitere 30 Minuten. Verwende für Kostenprognosen eines bestehenden Workloads die tatsächlich beobachtete Zahl der Schreibvorgänge.

Als konkrete Schätzung dient ein Präfix mit 10,000 Tokens auf GPT-6.1 Sol zu Standard-Preisen: B = $0.02 und r = 0.05. Sende von Stunde 0 bis Stunde 11 jede Stunde eine Anfrage, insgesamt 12, ohne das Präfix zu verändern.

Angenommenes Cache-Verhalten	Eingabekosten des Präfixes für 12 Anfragen
Ohne Cache: 12 normale Eingaben	$0.240
`30m`: Alle 12 Anfragen benötigen einen Schreibvorgang	$0.300
`12h`: Ein Schreibvorgang und 11 Lesezugriffe	$0.061
`30m`: Ein Schreibvorgang und 11 Lesezugriffe	$0.036

Die beiden 30m-Zeilen zeigen, warum der Abstand zwischen Anfragen allein keine Einsparung belegt. Die Variante mit ausschließlich Schreibvorgängen ist eine Annahme, kein zwangsläufiges Ergebnis stündlicher Anfragen. Wechselnde Suffixe, Ausgabetokens und mögliche Tool-Gebühren sind in diesen Schätzungen nicht enthalten. Die Beträge sind Rechenbeispiele, keine tatsächlichen Rechnungswerte.

Warum 12h für die gesamte Anfrage mehr kosten kann

Die Einstellung prompt_cache_options.ttl: "12h" auf Anfrageebene gilt auch für den impliziten Breakpoint, also die automatisch gesetzte Cache-Grenze. Mit dem Standardwert mode: "implicit" können neu hinzugefügte, cachefähige Gesprächsinhalte deshalb in jeder Runde einen Schreibvorgang zum Faktor 2.5× auslösen, während das ältere Präfix günstig gelesen wird.

Bei einem Agenten, der Tool-Ergebnisse und Nutzernachrichten ansammelt, kann dieses wachsende Suffix die Einsparung am stabilen Anfang übersteigen. Eine hohe Cache-Trefferquote allein zeigt nicht, ob die gewählte Einstellung wirtschaftlich ist.

Wähle eine dieser Konfigurationen:

Stabiles gemeinsames Material und wiederverwendbarer Sitzungskontext: Setze die Vorgabe der Anfrage auf 30m und überschreibe sie am Ende des gemeinsamen Materials mit 12h.
Stabiles Material und einmalige Fragen: Verwende mode: "explicit" und platziere die wechselnde Frage hinter dem letzten expliziten Breakpoint.
Ein Dialog, dessen neuester Kontext bald wiederverwendet wird: Behalte mode: "implicit" mit der Anfragevorgabe 30m bei und setze zusätzlich einen 12h-Breakpoint für das gemeinsame Präfix.

Ein Breakpoint umfasst das gesamte Präfix vor seiner Position. Bei einer Anfrage ohne vorhandenen Cache, mit einem 12h-Breakpoint bei 2,000 Tokens und einem 30m-Breakpoint bei 5,000, werden 2,000 Tokens als Schreibvorgänge mit langer Laufzeit und 3,000 mit kurzer Laufzeit abgerechnet. Setzt du stattdessen einen 12h-Breakpoint an die spätere Grenze bei 5,000 Tokens, gilt für alle 5,000 Tokens der höhere Schreibpreis. Jedes Token wird nur einmal abgerechnet, und zwar zum Schreibpreis der längsten ausgewählten Cache-Laufzeit, die für dieses Token gilt.

Auch zwei Änderungen der Laufzeit sind relevant. Eine noch gültige 30m-Abdeckung auf 12h anzuheben, löst einen neuen Schreibvorgang mit langer Laufzeit aus; der frühere Schreibpreis wird nicht angerechnet. Liest eine Anfrage mit 30m ein Präfix aus einem weiterhin gültigen 12h-Eintrag, werden diese Tokens zum Lesepreis berechnet. Dabei beginnt weder eine neue 12-Stunden-Frist noch fällt eine weitere Schreibgebühr an. Wegen dieser Regeln zu Überschneidungen und Laufzeiten solltest du die Einstellung wählen, bevor du ein großes Präfix erstmals in den Cache schreibst.

12h und 30m in einer Responses-Anfrage konfigurieren

Verwende 30m als Anfragevorgabe und explizite Breakpoints, um gemeinsames Referenzmaterial, Sitzungskontext und die aktuelle Frage zu trennen. Das folgende Beispiel sendet die Anfrage direkt an OpenAIs Responses API und gibt sowohl den generierten Text als auch die für die Kostenprüfung benötigten Nutzungsdaten aus.

Du benötigst Bash, curl, jq und einen OpenAI-API-Schlüssel mit Zugriff auf gpt-6.1-sol. Bereite im aktuellen Verzeichnis diese Dateien vor:

shared-context.md: sinnvolle technische Vorgaben und Referenzmaterial, das du über den Tag wiederverwendest, mit mindestens 1,024 sichtbaren Eingabetokens.
session-context.md: der aktuelle Kontext eines Deployments oder Pull Requests, den du während dieser Sitzung erneut verwenden möchtest.

Verändere die beiden Dateien zwischen den zwei Beispielaufrufen nicht. Sobald read auf eine Eingabe wartet, füge deinen API-Schlüssel ein und drücke Enter; der Schlüssel wird im Terminal nicht angezeigt. Die Authentifizierung folgt dem OpenAI-API-Quickstart.

set -o pipefail
read -rs OPENAI_API_KEY && export OPENAI_API_KEY

cache_request() {
  jq -n \
    --rawfile shared ./shared-context.md \
    --rawfile session ./session-context.md \
    --arg question "$1" \
    '{
  model: "gpt-6.1-sol",
  service_tier: "default",
  reasoning: {effort: "low"},
  prompt_cache_options: {mode: "explicit", ttl: "30m"},
  input: [
    {
      role: "developer",
      content: [{
        type: "input_text",
        text: $shared,
        prompt_cache_breakpoint: {mode: "explicit", ttl: "12h"}
      }]
    },
    {
      role: "user",
      content: [
        {
          type: "input_text",
          text: $session,
          prompt_cache_breakpoint: {mode: "explicit"}
        },
        {type: "input_text", text: $question}
      ]
    }
  ]
}' |
  curl --silent --show-error --fail-with-body \
    https://api.openai.com/v1/responses \
    -H "Authorization: Bearer $OPENAI_API_KEY" \
    -H "Content-Type: application/json" \
    --data-binary @- |
  jq '{id, status, service_tier,
  text: ([.output[]? | .content[]? |
    select(.type == "output_text") | .text] | join("\n")),
  usage, error}'
}

cache_request "Which deployment risks need review? Answer briefly." &&
cache_request "Which test should run first? Answer briefly."

Der erste Inhaltsblock überschreibt die Anfragevorgabe mit "ttl": "12h". Der Sitzungsblock gibt keinen eigenen TTL-Wert an und übernimmt "30m". Da die Anfrage ausschließlich explizite Breakpoints verwendet, verursacht die letzte Frage keine Cache-Schreibgebühr; normale Eingabekosten fallen dafür weiterhin an.

Bei einem geeigneten Präfix ohne vorhandenen Cache sollte die erste abgeschlossene Antwort Schreibvorgänge mit langer Laufzeit unter usage.input_tokens_details.cache_write_tokens_details.ttl_12h_tokens ausweisen. Die zweite sollte cached_tokens > 0 und keinen neuen Schreibvorgang mit langer Laufzeit zeigen, sofern Präfix und Cache-Abdeckung weiterhin gültig sind. Das zurückgegebene Feld text enthält die nutzbare Antwort. Eine sofortige Wiederholung prüft die Übereinstimmung und Abrechnung; Einsparungen nach längeren Pausen bewertest du mit den tatsächlichen Anfrageabständen deiner Produktionsumgebung.

Bei 400 invalid_request_error prüfst du die exakten TTL-Zeichenfolgen, das gewählte Modell und den Responses-Endpunkt. Geben beide Aufrufe null gecachte Tokens zurück, kontrolliere zuerst die Präfixlänge und vergleiche anschließend Dateien, Modell, Einstellungen und Breakpoint-Positionen. Änderungen vor dem gemeinsamen Breakpoint können die Wiederverwendung verhindern. Dazu gehören auch veränderte Tool-Definitionen, wenn du Tools hinzufügst.

Für einen Vergleich ohne Cache behältst du mode: "explicit" bei und entfernst alle prompt_cache_breakpoint-Marker. Laut offiziellem Anfrageschema nutzt der explizite Modus ohne Marker kein Prompt-Caching.

Eingabekosten aus usage berechnen

Behandle normale Eingaben, Cache-Lesezugriffe und die beiden Schreibklassen als getrennte Kategorien ohne Überschneidung. Die Gesamtzahl der geschriebenen Tokens, cache_write_tokens, enthält bereits ttl_30m_tokens und ttl_12h_tokens; alle drei zu berechnen würde die geschriebenen Tokens doppelt zählen. Tokens, die für die Umstellung auf 12h berechnet werden, zählen zu den Schreibvorgängen und sind nicht in cached_tokens enthalten.

OpenAIs Beispiel zur Nutzungsabrechnung hat diese Struktur:

{
  "usage": {
    "input_tokens": 12000,
    "input_tokens_details": {
      "cached_tokens": 4000,
      "cache_write_tokens": 7000,
      "cache_write_tokens_details": {
        "ttl_30m_tokens": 3000,
        "ttl_12h_tokens": 4000
      }
    }
  }
}

Dabei steht I für input_tokens, R für cached_tokens sowie W30 und W12 für die beiden TTL-spezifischen Schreibtokenzahlen. Die normale Eingabe berechnest du als U = I - R - W30 - W12; hier sind das 1,000 Tokens.

Für den normalen Eingabepreis P in USD pro 1M tokens und den Cache-Lesepreisfaktor r gilt:

Input cost = P × (U + r × R + 1.25 × W30 + 2.5 × W12) / 1,000,000

Das hypothetische Beispiel der Dokumentation mit P = $1 und r = 0.1 ergibt:

(1000 + 4000 × 0.1 + 3000 × 1.25 + 4000 × 2.5) / 1000000 = $0.01515

Setzt du für dieselbe Nutzung die Standard-Preise von GPT-6.1 Sol ein, also P = $2 und r = 0.05, betragen die Eingabekosten $0.02990. Ausgabe und weitere anfallende Gebühren rechnest du separat hinzu. Diese Rechnung betrachtet nur die Eingabeabrechnung; sie schätzt nicht die Gesamtkosten einer abgeschlossenen Programmieraufgabe.

Protokolliere Antwort-ID, Zeitpunkt, Modell, den tatsächlich verwendeten service_tier und diese Tokenzahlen. Fehlt im Client die Aufschlüsselung nach TTL, prüfe das unverarbeitete JSON, bevor du Kosten für gemischte Laufzeiten berechnest. Fehlende Zähler belegen nicht, dass keine Schreibvorgänge stattgefunden haben. Summiere die Dollarkosten über einen repräsentativen Tag, statt eine Einstellung anhand einer einzelnen Trefferquote zu wählen.

12h legt eine Mindestlaufzeit fest, während der die Cache-Lesepreise gelten können. Es setzt keine Löschfrist, verändert nicht die Richtlinie zur maximalen Datenaufbewahrung und garantiert nicht bei jeder Anfrage eine niedrigere Latenz.

Wie unterscheidet sich das von Codex, Work und Anthropic?

Trenne API-Abrechnung und die Nutzungskontingente angemeldeter Produktnutzer. In seinem Beitrag vom 21. Oktober 2026 schrieb Tibo Sottiaux, der Cache für angemeldete Nutzer von Codex und Work bleibe „für immer“ erhalten; auch das Fortsetzen alter Gespräche führe zu Cache-Treffern. Diese Aussage betrifft die Sitzungen dieser Produkte. Sie definiert keinen API-TTL und macht ein Abonnement nicht unbegrenzt.

Die offizielle Codex-Preisdokumentation erklärt separat, dass bei der Abrechnung über Codex-Credits keine eigene Cache-Schreibgebühr anfällt, während für die Nutzung mit API-Schlüssel die API-Preise gelten. Wenn du Codex mit einem API-Schlüssel betreibst, plane nach den API-Regeln und übertrage keine Zusage für angemeldete Produktsitzungen auf diese Nutzung.

Für Claude sind mit Stand 2026-10-24 ein Standardcache von 5 Minuten mit Schreibpreisen von 1.25× sowie ein optionaler Cache von 1 Stunde mit Schreibpreisen von 2× dokumentiert. Die Leserabatte hängen vom Modell ab: Claude Opus 5.5 und Sonnet 5.5 verwenden 0.05×; weitere Preise stehen in Anthropics Preistabelle. Erfolgreiche Lesezugriffe erneuern die Laufzeit ohne weiteren Schreibaufschlag. Bei Anfragen mit gemischten TTLs müssen Blöcke mit längerer Laufzeit vor denen mit kürzerer Laufzeit stehen.

Wenn deine Anwendung bereits ein unterstütztes Modell verwendet und wiederholt mehrstündige Pausen auftreten, teste zuerst OpenAIs 12h-Einstellung für das stabile Präfix. Bei einer durchgehend aktiven Sitzung beginnst du mit dem kürzeren Cache. Ein Anbietervergleich benötigt die tatsächlichen Basispreise, die Menge der Ausgabetokens und das beobachtete Cache-Verhalten. Laufzeit und Schreibpreisfaktoren allein zeigen nicht, welcher Anbieter die gesamte Aufgabe günstiger erledigt.