OpenAIs neue Prompt-Cache-Diagnose macht ein bisher schwer erklärbares Kostenproblem untersuchbar: Sie vergleichen eine Anfrage mit einer jüngeren Antwort und identifizieren eine Konfigurations- oder Eingabeänderung, die Wiederverwendung verhindert hat. Für einen Unternehmensagenten beginnt die Einführung mit einem rein lesenden Diagnose-Canary, nicht mit einer automatischen Wiederholung des Geschäftsprozesses. Trennen Sie Abrechnungsnachweise vom Diagnoselabel und schwächen Sie weder Mandantentrennung noch Werkzeugberechtigungen zugunsten einer höheren Cache-Trefferrate.
Was sich geändert hat
Am 22. September 2026 hat OpenAI verbessertes Prompt-Caching für GPT-6 angekündigt: Cache-Rabatte für geeignete gemeinsame Präfixe innerhalb eines 30-Minuten-Fensters, ein Prompt Caching Dashboard, Diagnose einzelner Cache-Misses und explizite Cache-Breakpoints. Die Ankündigung beschreibt außerdem Änderungen des Reasoning-Aufwands über angehängte Konfigurationsupdates sowie die Steuerung verfügbarer Werkzeuge ohne Entfernen stabiler Werkzeugdefinitionen.
Neu ist die Beobachtungs- und Steuerungsschnittstelle, nicht das Prinzip des Prefix-Cachings. Unser bestehender Leitfaden zur Wirtschaftlichkeit von Prefix-Caching behandelt die Frage, ob vermiedenes Prefill seinen Aufwand rechtfertigt. Dieser Beitrag beantwortet eine andere Betriebsfrage: Wie untersuchen Sie eine schlechtere Cache-Wiederverwendung in der OpenAI API, ohne die Befugnisse Ihres Agenten zu verändern oder dessen Arbeit erneut auszuführen?
OpenAIs Aussagen zu höheren Trefferraten sind Herstellerangaben. Wir haben diese Funktionen nicht gegen eine Produktionslast vermessen. Die folgenden Umsetzungsempfehlungen leiten sich aus der veröffentlichten Schnittstelle und ihren dokumentierten Fehlerzuständen ab; die Quellen wurden am 23. September 2026 geprüft.
Verfügbarkeit und Kosten der Diagnose
Die Diagnosedokumentation nennt Unterstützung in der Responses API für GPT-5.6 und spätere unterstützte Modelle. Die GPT-6-Ankündigung belegt daher weder eine Exklusivität für GPT-6 noch die Verfügbarkeit über jedes Modell oder vorgeschaltete API-Gateway. Prüfen Sie die tatsächliche Antwort des Modells und Endpunkts, den Ihre Anwendung verwendet.
Für die Diagnose fällt kein zusätzlicher Preis an; sie zählt nicht gesondert gegen Rate-Limits. Zusätzliche Baseline- oder Wiederholungsanfragen sind dagegen regulär abgerechnete API-Anfragen. Der Caching-Leitfaden nennt für GPT-5.6 und spätere Modelle einen Cache-Schreibpreis vom 1,25-Fachen und einen Cache-Lesepreis vom 0,1-Fachen des normalen Preises für ungecachte Eingabetokens. Diese Faktoren betreffen die Eingabeabrechnung, nicht die gesamte Agentenrechnung. Ausgabe, Werkzeugausführung und fehlgeschlagene Versuche bleiben relevant. Gleichen Sie Modell, Service-Tier und Kontextbereich mit Ihrem tatsächlichen Tarif ab, bevor Sie Einsparungen prognostizieren.
Für die neuere Modellfamilie beschreibt der Leitfaden prompt_cache_options.ttl mit 30m als unterstütztem Wert und Standard. Ein Präfix bleibt nach dem letzten Schreiben oder Wiederverwenden mindestens 30 Minuten für Wiederverwendung geeignet; OpenAI kann es länger vorhalten. Stellen Sie diese Einstellung nicht als garantierte Löschfrist dar. Laut Leitfaden werden Caches nicht zwischen Organisationen geteilt und nicht über regionale Verarbeitungsgrenzen hinweg wiederverwendet. Daraus allein folgt weder die EU-Verarbeitung Ihrer Anwendung noch eine geeignete Mandantenzugriffskontrolle.
Eine Vergleichs-ID setzt kein Gespräch fort
Setzen Sie comparison_response_id innerhalb von prompt_cache_options auf eine jüngere, abgeschlossene Antwort derselben Organisation, deren Präfix wiederverwendet werden sollte. Das dokumentierte Anfragefragment lautet prompt_cache_options={"comparison_response_id": baseline_id}. Es fordert einen Vergleich an, lädt aber weder den Gesprächsinhalt dieser Antwort noch beschränkt es die Anfrage auf genau diesen Cache-Eintrag.
Dagegen übernimmt previous_response_id vorherigen Gesprächskontext. Beide IDs dürfen dieselbe oder unterschiedliche Antworten referenzieren. Wenn Ihre Anwendung die Historie selbst übermittelt, behalten Sie dieses Verfahren bei und ergänzen Sie nur die Vergleichsoption. Ersetzen Sie die Historie nicht durch eine Vergleichs-ID. OpenAI dokumentiert außerdem, dass Anweisungen auf oberster Anfrageebene nicht über previous_response_id übernommen werden; das Fortsetzungsbeispiel übermittelt sie erneut.
Beim Debugging ist diese Unterscheidung entscheidend. Wer beim Ergänzen von Telemetrie zugleich Gesprächsaufbau und Cache-Konfiguration verändert, untersucht anschließend womöglich einen neuen Integrationsfehler statt der ursprünglichen Produktionsregression. Versionieren Sie den Request-Builder und vergleichen Sie gegen eine feste Baseline. Das Muster für Prompt-Versionierung mit CI-Regressionsprüfungen hält diese Änderung nachvollziehbar.
Vier Zustände richtig interpretieren
Cache-Hit: tatsächliche Token-Nutzung prüfen
cache_hit bedeutet, dass der Vergleich keinen Miss erkannt hat. Es bedeutet nicht, dass sämtliche Eingabetokens aus dem Cache kamen. Lesen Sie usage.input_tokens_details.cached_tokens zusammen mit der gesamten Eingabe und den Cache-Schreibtokens aus. Eine angehängte Frage benötigt neue Verarbeitung, auch wenn das frühere Präfix wiederverwendbar ist. Übersetzen Sie ein kategorisches Diagnoselabel nicht in einen Prozentsatz eingesparter Rechnungskosten.
Cache-Miss: eine klassifizierte Ursache beheben und erneut vergleichen
cache_miss liefert einen Grund und eine Schätzung in cache_missed_tokens; zusätzlich kann comparison_reusable_tokens vorliegen. Dokumentierte Ursachen sind Änderungen an Werkzeugen, Modell, Schlüssel, Service-Tier, Ausgabeformat, Reasoning-Aufwand, Ausführlichkeit und Eingabe sowie komprimierter Kontext. Die Diagnose nennt den ersten klassifizierten Grund, keinen vollständigen Konfigurationsvergleich. Korrigieren Sie eine unbeabsichtigte Änderung, behalten Sie dieselbe Vergleichsbaseline bei und prüfen Sie das nächste Ergebnis.
Trennen Sie tools_changed von einer Berechtigungsentscheidung. Stabile Werkzeugdefinitionen und ihre Reihenfolge können Wiederverwendung begünstigen; allowed_tools oder tool_choice: "none" begrenzen die Aufrufbarkeit, ohne Definitionen zu entfernen. Der externe Tool-Broker muss Ressourcenberechtigungen weiterhin durchsetzen. Darf bereits die Beschreibung eines entzogenen Werkzeugs nicht mehr an das Modell gelangen, entfernen Sie diese und akzeptieren Sie die Cache-Kosten. Cache-Stabilität steht unterhalb der Sicherheitsgrenze.
Vergleichsdatensatz fehlt: Baseline ersetzen, nicht Geschäftsaktion wiederholen
comparison_response_not_found bedeutet, dass ein verwendbarer Diagnosedatensatz fehlt oder abgelaufen ist. Die Antwort selbst kann weiterhin vorhanden sein. Wählen Sie eine andere jüngere, abgeschlossene Antwort derselben Organisation. Markieren Sie die Agentenaufgabe nicht allein wegen abgelaufener Diagnosedaten als fehlgeschlagen. Senden Sie keine Bestellung oder CRM-Änderung erneut, nur um die Diagnosehistorie wiederherzustellen.
Nicht verfügbar: unbekannt statt erfolgreich oder fehlgeschlagen
unavailable ist nicht eindeutig. Es kann auftreten, wenn das Modell nicht unterstützt wird oder der Vergleich noch nicht bereitsteht. Laut OpenAI blockiert die Diagnose die Anfrage nicht und lässt sie nicht fehlschlagen. Behalten Sie die normale Ergebnisbehandlung bei, erfassen Sie Nutzungsfelder und dokumentieren Sie die Diagnoseabdeckung separat. Ein Alarm sollte steigende tatsächlich abgerechnete ungecachte Eingabe von sinkender Beobachtbarkeit unterscheiden.
Sicher untersuchen, bevor Sie optimieren
Beginnen Sie mit einem vorhandenen rein lesenden Ablauf und einer repräsentativen freigegebenen Eingabe. Erfassen Sie die Baseline-Antwort-ID, das tatsächlich verwendete Modell und Service-Tier, die Request-Builder-Version, die Werkzeug-Schemaversion und die Eingabenutzung. Ergänzen Sie die Vergleichsoption an einer ansonsten unveränderten geeigneten Anfrage. Bei Streaming lesen Sie prompt_cache_diagnostics aus der Antwort des Ereignisses response.completed, statt aus einem unvollständigen Stream zu entscheiden.
Reproduzieren Sie anschließend ausschließlich die vermutete Änderung am Anfrageaufbau: eine umsortierte Werkzeugliste, einen frühen Zeitstempel, ein neues Ausgabeschema oder einen beabsichtigten Modell-Fallback. Prüfen Sie, ob die Diagnose diese Änderung klassifiziert. Die Klassifizierung ist unterstützende Evidenz, kein Beweis für die Gleichheit aller übrigen Eingaben. Vergleichen Sie zusätzlich anwendungsseitige versionierte Manifeste. Schreiben Sie keine vertraulichen Rohprompts, Dokumentinhalte oder Kundenkennungen in Metriklabels.
Für Reasoning-Anpassungen bei GPT-6 beschreibt die Ankündigung das Anhängen von configuration_update, während der Reasoning-Aufwand auf Anfrageebene unverändert bleibt. Eine direkte Änderung dieses Anfragefelds ist nicht dieselbe Operation. Ebenso ist das Anhängen neuer Anweisungen zur Bewahrung eines Präfixes nicht grundsätzlich sicher: Veraltete Sicherheitsanweisungen oder Fakten müssen möglicherweise entfernt werden. Bewahren Sie Semantik und Aktualität, auch wenn die korrigierte Anfrage ihren Vorgänger nicht wiederverwenden kann.
Der Kostenzähler muss Baseline-Aufrufe, Diagnosewiederholungen, Cache-Schreiben, ungecachte und gecachte Eingabe, Ausgabe sowie relevante Werkzeugkosten umfassen. Teilen Sie durch akzeptierte Aufgaben, die Qualitäts- und Latenzkriterien erfüllen. Eine niedrigere Trefferrate nach sinnvoller Kontextkomprimierung kann mit einer niedrigeren Rechnung einhergehen. Deshalb gehört der Diagnosegrund ins Untersuchungsprotokoll, nicht allein in die Freigaberegel.
Checkliste für die Einführung im Unternehmen
1. Schnittstelle vor dem Canary bestätigen
Prüfen Sie das genaue Modell und den Responses-API-Pfad, die Übermittlung der Option durch Ihr SDK, das Auslesen des Ergebnisses sowie die Behandlung jedes dokumentierten Diagnosezustands. Erforderlicher Nachweis: ein bereinigtes Antwort-Fixture und ein getesteter Parser. Ein fehlendes Feld bedeutet nicht null Cache-Misses.
2. Arbeitsausführung von der Diagnose entkoppeln
Führen Sie die erste Untersuchung mit rein lesender Last oder in einem Testsystem durch, das keine externen Schreibaktionen auslösen kann. Erforderlicher Nachweis: außerhalb des Modells deaktivierte oder abgefangene Werkzeugausführung bei unveränderter Geschäfts-Retry-Logik. Die Diagnose darf niemals zu einem zweiten Ausführungstrigger werden.
3. Abrechnung und Latenz gemeinsam prüfen
Erfassen Sie gesamte Eingabe, gecachte Eingabe, Cache-Schreibtokens, Ausgabe, Modell, Service-Tier und Ende-zu-Ende-Dauer bei repräsentativen Anfrageabständen. Erforderlicher Nachweis: eine zur Rechnung passende Kostenaufstellung einschließlich der Untersuchungsaufrufe. Geben Sie keine Änderung allein aufgrund einer warmen Anfrage oder der Dashboard-Trefferrate frei.
4. Aufbewahrung und Berechtigungsgrenzen erhalten
OpenAI dokumentiert die Diagnosefunktion als mit Zero Data Retention vereinbar: Temporäre Datensätze enthalten Konfigurationsmetadaten, Tokenschätzungen und Hashes, keine Rohprompts oder Ausgaben. Das ist eine funktionsbezogene Aussage, keine pauschale Freigabe für Antwortspeicherung, Caching, Logs oder eine Cloud-Region. Erforderlicher Nachweis: Prüfung der tatsächlichen Kontokonfiguration und Datenflüsse durch die zuständigen Sicherheits- und Datenschutzverantwortlichen; rechtliche Fragen gehören in die anwaltliche Prüfung.
5. Rollback als Request-Builder-Änderung gestalten
Versionieren Sie Vergleichsoption, Parser und Metriken gemeinsam. Halten Sie einen Schalter bereit, der die Diagnose deaktiviert, ohne Prompts, Modellauswahl oder Werkzeugbefugnisse zu verändern. Erforderlicher Nachweis: dieselbe funktionale Regressionssuite mit und ohne Instrumentierung. Das LLM-Release-Bundle liefert die Struktur für Manifest und Rücknahme.
Nächster Schritt: ein erklärbarer Miss statt eines Komplettumbaus
Wählen Sie einen teuren Ablauf mit wiederholtem Präfix. Bestimmen Sie die bisher abgerechnete Eingabe, identifizieren Sie einen reproduzierbaren Miss und prüfen Sie eine Korrektur, die die Semantik erhält. Wenn Ihr Team daraus eine belastbare Freigabeentscheidung machen möchte, kann ein Architekturreview für KI-Automatisierung Request-Manifest, Diagnoseparser, sichere Wiederholungsgrenze und Kostenakzeptanzkriterien festlegen. Das Ergebnis ist ein überprüfter Grund, eine Änderung beizubehalten oder abzulehnen – kein versprochener Rabatt auf jeden Agentenlauf.
