12-Stunden-Caching in der OpenAI API: Wann es die Kosten langer Prompts senkt

Für einen Agenten, der im Laufe eines Arbeitstags mehrmals die API aufruft, wirken sich wiederholte Übertragungen langer Anweisungen auf die Kosten aus. Am 20. Oktober 2026 ergänzte OpenAI die Responses API um die Möglichkeit, eine Cache-Dauer von 12 Stunden auszuwählen: Gemeinsame Anweisungen, Tools und Kontext können zwischen Anfragen, die mehrere Stunden auseinanderliegen, zur Wiederverwendung verfügbar bleiben. OpenAI gibt einen Schreibpreis an, der 2,5-mal so hoch ist wie der reguläre Preis für Eingabetokens; dabei handelt es sich um den vollständigen Schreibpreis, nicht um einen zusätzlichen Aufschlag. Die Einsparungen hängen von der Wiederverwendung des Präfixes und dem Preis für das Lesen gecachter Tokens ab. Der Eintrag im OpenAI-Änderungsprotokoll ist auf den 20. Oktober 2026 datiert.

Diese Dauer ist für mehrstufige Arbeitsabläufe gedacht: Ein Agent kann beispielsweise morgens Dokumente analysieren und die Aufgabe später mit denselben Anweisungen und Tools fortsetzen. Um zu entscheiden, ob die 12-Stunden-Dauer aktiviert werden soll, müssen Sie die Schreibkosten mit den Kosten wiederholter Lesevorgänge vergleichen und berücksichtigen, wie viele Anfragen tatsächlich dasselbe Präfix wiederverwenden.

Was genau wird gecacht?

Prompt-Caching verwendet einen übereinstimmenden Anfangsteil der Eingabe erneut. Nachfolgende Anfragen müssen diesen Teil unverändert beibehalten; veränderliche Daten sollten hinter dem konstanten Teil stehen. Im OpenAI-Leitfaden zum Prompt-Caching steht, dass sich für GPT‑5.6 und neuere Modelle in der Responses API ein TTL von `30m` oder `12h` festlegen lässt. Zwölf Stunden sind die Mindestdauer, während der ein Eintrag für gecachte Lesevorgänge verfügbar bleiben soll; das ist keine Zusage, ihn genau nach 12 Stunden zu löschen. Verfügbarkeit und Einstellungen hängen vom Modell ab.

Systemanweisungen, Tooldefinitionen und stabile Verarbeitungsregeln eignen sich für ein konstantes Präfix. Die aktuelle Frage, Aufgabenkennungen und neue Daten sollten weiter hinten stehen. Wenn sich frühe Teile der Anfrage ändern, wird das übereinstimmende Präfix kürzer und die Zahl der wiederverwendbaren Tokens kann sinken.

Rentabilität einschätzen

Angenommen, ein stabiles Präfix umfasst P Tokens und wird N Mal gesendet, der Preis für ein reguläres Eingabetoken beträgt C und der Preis für gecachte Lesevorgänge des gewählten Modells R. Bei einem Schreibvorgang und Cache-Treffern bei allen nachfolgenden Anfragen belaufen sich die Kosten für dieses Präfix auf ungefähr 2,5PC + (N−1)PR. Ohne Cache würde seine Übertragung NPC kosten. Diese Schätzung betrifft nur das stabile Präfix: Berücksichtigen Sie veränderliche Teile der Anfrage, Cache-Fehler und zusätzliche Schreibvorgänge gesondert. Der Lese-Tarif hängt vom Modell ab; laut Dokumentation beträgt er beispielsweise für GPT‑6.1 Sol 0,05 des regulären Preises für Eingabetokens und für GPT‑5.6 und neuere Modelle 0,1.

In diesem vereinfachten Modell spart der Cache beim wiederverwendeten Präfix, wenn 2,5C + (N−1)R < NC. Der tatsächliche Break-even-Punkt hängt von den realen Cache-Treffern, erneuten Schreibvorgängen und dem jeweiligen Tarif ab. Bei seltenen Anfragen, häufig wechselnden Anweisungen oder einem jedes Mal einzigartigen Präfix können die zusätzlichen Schreibkosten die Einsparungen beim Lesen übersteigen.

Mit der tatsächlichen Arbeitslast testen

1. Ausgangsszenario festlegen. Wählen Sie typische Anfragen, die Länge des stabilen Präfixes, die Abstände zwischen Aufrufen und die Kosten ohne 12-Stunden-TTL.
2. Konstante und veränderliche Teile trennen. Lassen Sie gemeinsame Anweisungen und Tool-Schemas am Anfang und setzen Sie nutzerspezifische Daten sowie die aktuelle Aufgabe dahinter.
3. Vergleichbare Anfragen gegenüberstellen. Zählen Sie Schreibvorgänge, die Menge gecachter Eingabetokens und die Gesamtkosten für das gewählte Modell und die gewählte Aufbewahrungsdauer.
4. Den gesamten Arbeitszyklus bewerten. Berücksichtigen Sie Cache-Fehler, erneute Schreibvorgänge nach Ablauf der Dauer und Fälle, in denen Änderungen am Präfix seine Wiederverwendung verhindern.

Die Antwortmetriken der API helfen dabei, die tatsächliche Menge gecachter Eingabetokens und Schreibvorgänge zu überprüfen; der Umfang der Berichterstattung hängt vom Modell ab. Eine einstellbare Dauer von 12 Stunden eignet sich für ein großes, stabiles Präfix, das im Abstand von mehreren Stunden wiederverwendet wird. Bei kurzen oder selten wiederholten Anfragen sollten Sie zunächst Schreibvorgänge, Cache-Treffer und Gesamtkosten anhand Ihres eigenen Datenverkehrs messen.