Prompt-Caching

Eine Änderung an einer Anfrage führt nicht zwangsläufig dazu, dass ein vorhandener Cache-Eintrag verworfen wird. Entscheidend ist, ob eine nachfolgende Anfrage dasselbe Präfix hat und einen geeigneten, übereinstimmenden Breakpoint finden kann. Prüfe vor allem die folgenden Einstellungen:

Bei GPT-5.6 und neueren Modellen kosten Schreibvorgänge in den Cache das 1,25-Fache des Standardtarifs für nicht zwischengespeicherte Eingabetokens. Diese Kosten lohnen sich, wenn du weißt, dass ein Präfix wiederverwendet wird, denn nachfolgende Lesevorgänge kosten nur das 0,1-Fache dieses Tarifs. Ein Präfix einmal zu schreiben und einmal vollständig wiederzuverwenden kostet das 1,35-Fache seiner regulären Eingabekosten. Es zweimal ohne Caching zu verarbeiten kostet dagegen das Doppelte. Mit jedem weiteren Lesevorgang aus dem Cache steigt die Ersparnis: Bei zehn Anfragen kosten ein Schreibvorgang und neun vollständige Lesevorgänge das 2,15-Fache, verglichen mit dem Zehnfachen ohne Caching.

Sowohl implizites als auch explizites Caching werden unterstützt. Explizites Caching gibt dir mehr Kontrolle darüber, welcher Kontext in den Cache geschrieben wird.

Expliziter Modus: Du wählst passend zu deiner Kontextverwaltung aus, wo du Cache-Breakpoints setzt.

• Setze prompt_cache_options.mode auf explicit, um nur selbst ausgewählte Breakpoints zu verwenden. Markiere jeden gewünschten Breakpoint, indem du prompt_cache_breakpoint: { "mode": "explicit" } zu einem unterstützten Inhaltsblock innerhalb einer Eingabenachricht hinzufügst.
• Wenn keine expliziten Breakpoints gesetzt sind, verwendet die Anfrage kein Prompt-Caching und schreibt nichts in den Cache.
• Im rein expliziten Modus bestimmst du, bis wohin Inhalte in den Cache geschrieben werden. Inhalte nach dem letzten ausgewählten Breakpoint werden zum Tarif für nicht zwischengespeicherte Eingabetokens verarbeitet, ohne Gebühren für das Schreiben in den Cache. So kannst du vermeiden, wechselnde Inhalte zu speichern, die voraussichtlich nicht wiederverwendet werden.
• Mit mehreren expliziten Breakpoints kannst du Präfixe bewahren, die sich unterschiedlich häufig ändern. Jede Anfrage kann bis zu vier Schreibvorgänge in den Cache auslösen.
• Eingabeelemente vom Typ additional_tools akzeptieren derzeit kein prompt_cache_breakpoint.

Impliziter Modus: OpenAI wählt automatisch Positionen für Breakpoints, die sich für die meisten Anwendungsfälle eignen.

• Wenn prompt_cache_options.mode auf implicit gesetzt ist, platziert OpenAI einen Breakpoint am Ende der letzten geeigneten Nachricht. Als geeignet gelten:
  • Nachrichten von Nutzenden
  • die letzte Werkzeugantwort in einer Gruppe aufeinanderfolgender Werkzeugantworten
  • die letzte Developer-Nachricht in der anfänglichen Gruppe aufeinanderfolgender Developer-Nachrichten.
• Du kannst explizite Breakpoints hinzufügen, ohne den impliziten Breakpoint zu deaktivieren. Ein impliziter Breakpoint belegt einen der vier Plätze für Cache-Schreibvorgänge, sodass drei Plätze für explizite Cache-Schreibvorgänge übrig bleiben.

Es wird nur implizites Caching unterstützt. OpenAI setzt implizite Breakpoints in modellabhängigen Abständen, gerechnet ab dem Anfang der verborgenen OpenAI-Systemnachricht. Berücksichtigt werden nur Breakpoints, die mindestens die für das Caching erforderliche Länge erreichen (gerechnet ab dem Ende des verborgenen Kontexts).

Der gemeldete Wert für cached_tokens wird berechnet, indem die verborgenen System-Token von der Position des letzten übereinstimmenden Breakpoints abgezogen werden. Anschließend wird das Ergebnis auf das nächstkleinere Vielfache von 128 abgerundet.

Mit prompt_cache_options.ttl steuerst du die Mindestlebensdauer des Caches. Der einzige unterstützte Wert, 30m, ist zugleich der Standardwert. Ein zwischengespeichertes Präfix kann nach dem letzten Schreibvorgang oder der letzten Wiederverwendung noch 30 Minuten lang wiederverwendet werden. OpenAI kann es jedoch länger aufbewahren.

Verwende prompt_cache_retention. Welche Werte unterstützt werden, hängt vom Modell ab:

• in_memory: Einträge bleiben bei Inaktivität in der Regel etwa 5 bis 10 Minuten lang aktiv, höchstens jedoch eine Stunde.
• 24h: Bei verlängerter Aufbewahrung bleiben Einträge in der Regel etwa 30 Minuten lang verfügbar und können bis zu 24 Stunden aufbewahrt werden.

Standardeinstellungen für die Aufbewahrung und „Keine Datenaufbewahrung“

Beim Prompt-Caching können verschlüsselte Key-Value-Tensoren als Anwendungszustand im GPU-lokalen Speicher abgelegt werden. Bei Modellen, die sowohl in_memory als auch 24h unterstützen, hängt der Standardwert von der Datenaufbewahrungsrichtlinie deiner Organisation ab:

• Für Organisationen ohne aktivierte Option „Keine Datenaufbewahrung“ gilt standardmäßig 24h.
• Für Organisationen mit aktivierter Option „Keine Datenaufbewahrung“ gilt standardmäßig in_memory.

Prüfe vor der Auswahl eines Werts, welche Aufbewahrungsrichtlinien für dein Modell und deine Organisation verfügbar sind.

Verwende bei Modellen vor GPT-5.6 einen stabilen prompt_cache_key für Anfragen mit einem gemeinsamen wiederverwendbaren Präfix. So lassen sich zusammengehörige Anfragen leichter an denselben Cache leiten. Ziele bei stark ausgelasteten Gruppen auf insgesamt etwa 15 Anfragen pro Minute je Schlüssel ab, über alle Präfixe hinweg, die diesen Schlüssel verwenden. Verteile ein höheres Anfrageaufkommen anhand einer stabilen, deterministischen Zuordnung auf mehrere Schlüssel. Verwende für zusammengehörige Anfragen denselben prompt_cache_key, damit sie dessen Cache wiederverwenden können. Schlüssel beeinflussen das Routing, binden Anfragen aber weder an einen bestimmten Rechner noch garantieren sie einen Cache-Treffer.

Bei GPT-5.6 und neueren Modellen übernimmt OpenAI das Cache-Routing automatisch. Der Schlüssel wird nicht benötigt, um das Caching zu optimieren. Mit getrennten Schlüsseln kannst du die Cache-Nutzung innerhalb deiner Anwendung für einzelne Kundinnen und Kunden oder Nutzende getrennt erfassen und abrechnen.

Getrennte Schlüssel können es erleichtern, die Nutzung und Abrechnung zwischengespeicherter Token für einzelne Kundinnen und Kunden oder Nutzende zu erklären. Sie helfen beispielsweise zu verhindern, dass jemand anhand von Cache-Treffern die Inhalte anderer Nutzender ausforscht. Dabei werden mögliche Prompts gesendet und Cache-Treffer beobachtet, um festzustellen, ob passende Inhalte zuvor zwischengespeichert wurden. Siehe Cache-Nutzung mit Schlüsseln getrennt erfassen und abrechnen.

In Anwendungen mit mehreren Gesprächsrunden kann die Wiederverwendung des wachsenden Gesprächsverlaufs mehr Eingabetokens einsparen als das Caching allein der anfänglichen Anweisungen. Behalte frühere Nachrichten und Werkzeugergebnisse bei, damit spätere Gesprächsrunden das gesamte gemeinsame Präfix wiederverwenden können.

• Halte das Präfix stabil. Platziere unveränderliche Entwicklerinstruktionen und gemeinsam genutztes Referenzmaterial am Anfang. Enthalten sie Zeitstempel, nutzerspezifische oder andere dynamische Inhalte, platziere diese am Ende statt am Anfang oder verschiebe sie in spätere Nachrichten des Gesprächs.
• Behalte den Gesprächsverlauf bei. Hänge neue Nachrichten an, statt frühere Gesprächsrunden umzuschreiben. Zusammenfassungen, Compaction (Kontextverdichtung) oder das Abschneiden von Kontext können das Präfix verändern und die Cache-Wiederverwendung zurücksetzen.
• Ändere den Reasoning-Aufwand, ohne das Präfix umzuschreiben. Hänge bei GPT-6 Astra ein Eingabeelement vom Typ configuration_update an, um den Reasoning-Aufwand zwischen Antworten zu ändern, während reasoning.effort auf Anfrageebene unverändert bleibt. So bleibt das ursprüngliche Präfix für die Cache-Wiederverwendung erhalten. Beispiele und Einschränkungen zur Kompatibilität findest du unter Reasoning-Aufwand während eines Gesprächs ändern.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26{
  "model": "gpt-5.6",
  "reasoning": { "effort": "low", "context": "all_turns" },
  "text": { "verbosity": "medium" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Stable instructions and shared reference material...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "developer",
      "content": "Dynamic developer instructions, such as user-specific content and timestamps..."
    },
    {
      "role": "user",
      "content": "The user's current question..."
    }
  ]
}

Hänge bei unterstützten Modellen ab GPT-6 ein Eingabeelement vom Typ configuration_update an, um den Reasoning-Aufwand während eines Gesprächs zu ändern und dabei das zuvor gecachte Präfix beizubehalten. Behalte für reasoning.effort auf oberster Ebene den ursprünglichen Wert bei, da eine Änderung dieser Einstellung Anweisungen in den verborgenen Systemanweisungen umschreiben kann.

Die neueste Konfigurationsaktualisierung steuert den Reasoning-Aufwand für nachfolgende Antworten. Hänge beispielsweise dieses Element an das bestehende input-Array an, um den Reasoning-Aufwand für die nachfolgenden Anfragen auf high umzustellen:

1
2
3
4{
  "type": "configuration_update",
  "reasoning": { "effort": "high" }
}

Wenn deine Anwendung je nach Anfrage unterschiedliche Werkzeuge benötigt, ändere die Auswahl der aufrufbaren Werkzeuge, ohne ihre Definitionen zu verändern. So bleiben wiederverwendbare Präfixe erhalten.

• Halte die Werkzeuge konsistent. Behalte Werkzeugdefinitionen, Reihenfolge und Schemas bei.
• Deaktiviere die Werkzeugnutzung für eine Anfrage. Setze tool_choice auf "none", statt die Werkzeugdefinitionen zu entfernen.
• Aktiviere nur ausgewählte Werkzeuge. Beschränke mit allowed_tools die aufrufbaren Werkzeuge und behalte dabei die übergebene tools-Liste unverändert bei.
• Lade Werkzeuge bei Bedarf. Nutze die Tool-Suche mit defer_loading: true, um in den ersten Anfragen eines Threads mit mehreren Gesprächsrunden weniger Eingabetokens für Werkzeugdefinitionen zu verbrauchen. Gefundene Werkzeuge werden am Ende des Kontexts angehängt, sodass frühere wiederverwendbare Inhalte erhalten bleiben.
• Behalte den Verlauf der geladenen Werkzeuge bei. Verwende ein Eingabeelement vom Typ additional_tools mit der Entwicklerrolle, um während eines Threads entsprechend der Logik deiner Anwendung Werkzeuge hinzuzufügen.

Ab GPT-5.6 bestimmen zwei Einstellungen, wo Cache-Breakpoints platziert werden: prompt_cache_options.mode wählt zwischen implizitem und rein explizitem Caching, und prompt_cache_breakpoint markiert eine von dir gewählte Grenze.

• Lass Breakpoints automatisch platzieren. Nutze implizites Caching, um am Ende der letzten geeigneten Nachricht einen Breakpoint zu platzieren. Das ist praktisch für Threads mit mehreren Gesprächsrunden, die den bestehenden Kontext durch Anhängen erweitern.
• Wähle Breakpoints gezielt aus. Platziere explizite Markierungen am Ende unveränderlicher Inhalte. Nutze den rein expliziten Modus, um unnötige Cache-Schreibvorgänge für veränderliche Suffixe zu vermeiden.

Verwende bei GPT-5.6 und neueren Modellen prompt_cache_key, wenn du die Cache-Nutzung innerhalb deiner Anwendung für einzelne Kundinnen und Kunden, Nutzende oder Workspaces getrennt erfassen und abrechnen möchtest. Dadurch lassen sich die Nutzung und Abrechnung zwischengespeicherter Token innerhalb jeder Gruppe leichter erklären. Der Schlüssel ist optional und wird bei diesen Modellen nicht benötigt, um das Caching zu optimieren.

• Lege fest, wie du die Cache-Abrechnung trennen möchtest. Vergib jeweils einen eigenen Schlüssel für alle Kundinnen, Kunden oder Nutzenden, deren Cache-Abrechnung getrennt bleiben soll. Beispielsweise sorgen support:customer_123 und support:customer_456 für eine getrennte Cache-Abrechnung für zwei Kundinnen oder Kunden, selbst wenn ihre Anfragen dasselbe Präfix enthalten.
• Behalte die Schlüssel innerhalb jeder Gruppe bei. Verwende für zusammengehörige Anfragen derselben Kundin oder desselben Kunden immer denselben Schlüssel. Erzeuge nur dann einen separaten Schlüssel für eine Sitzung oder einen Thread, wenn dafür eine eigene Cache-Abrechnung erforderlich ist.
• Wende Schlüssel konsequent an. Verwende den jeweiligen Kundenschlüssel für alle zugehörigen Anfragen, um die Cache-Abrechnung getrennt zu halten. Das hilft auch zu verhindern, dass Kundinnen oder Kunden Cache-Treffer anderer gezielt ausforschen.

Bei Modellen vor GPT-5.6 ist prompt_cache_key wichtig, um die Cache-Trefferquote zu optimieren. Verwende einen stabilen Schlüssel für Anfragen mit einem gemeinsamen wiederverwendbaren Präfix, damit sie leichter an denselben Cache geleitet werden können. Befolge bei stark ausgelasteten Gruppen die Hinweise zur Verteilung des Anfrageaufkommens auf mehr Schlüssel.

Setze bei früheren Modellen prompt_cache_retention vorzugsweise auf "24h", um eine längere Aufbewahrung zu nutzen, sofern das Modell und deine Anforderungen an die Datenaufbewahrung dies zulassen. Unterstützte Einstellungen und Standardwerte findest du unter Cache-Lebensdauer.

Wenn viele Anfragen dieselben Entwicklerinstruktionen und Werkzeugdefinitionen wiederverwenden, das gemeinsame Präfix aber unter der Mindestlänge für das Caching des Modells liegt, erwäge, es zu kürzen oder um nützliche, unveränderliche Anweisungen, Beispiele oder Referenzmaterial zu erweitern. Miss, ob die Cache-Wiederverwendung die zusätzlichen Eingabetokens und etwaige Gebühren für Cache-Schreibvorgänge ausgleicht, und stelle sicher, dass die Evaluierungsergebnisse und das Verhalten stabil bleiben.

Das Diagramm zeigt die Kostenfalle bei der Mindestlänge für das Caching: Kurze Präfixe können ohne Caching mehr kosten, als wenn du sie auf die erforderliche Mindestanzahl an Tokens erweiterst.

• Miss die tatsächliche Cache-Leistung. Erfasse usage.input_tokens_details.cached_tokens, usage.input_tokens_details.cache_write_tokens, die Anzahl der Eingabe-Token, die Latenz und die tatsächlich angefallenen Kosten. Berechne die Cache-Trefferquote für Token, indem du die Gesamtzahl der gecachten Token durch die Gesamtzahl der Eingabe-Token teilst. Fasse dazu beide Werte nach nutzender Person, Workspace, Tag oder einer anderen sinnvollen Gruppierung zusammen.
• Berechne die Eingabekosten. Verwende die Token-Anzahlen in response.usage und die Preise pro Million Token des Modells.
• Nutze das Prompt-Caching-Dashboard. Überwache die Cache-Trefferquoten im Prompt-Caching-Dashboard.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18function calculateInputCost(
  usage,
  inputPricePerMillion,
  cacheInputMultiplier = 0.1,
  cacheWriteMultiplier = 1.25
) {
  const inputTokens = usage.input_tokens;
  const cachedTokens = usage.input_tokens_details.cached_tokens;
  const cacheWriteTokens = usage.input_tokens_details.cache_write_tokens;
  const ordinaryInputTokens = inputTokens - cachedTokens - cacheWriteTokens;

  const weightedInputTokens =
    ordinaryInputTokens +
    cachedTokens * cacheInputMultiplier +
    cacheWriteTokens * cacheWriteMultiplier;
  const inputCost = (weightedInputTokens * inputPricePerMillion) / 1_000_000;
  return inputCost;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21from openai.types.responses import ResponseUsage


def calculate_input_cost(
    usage: ResponseUsage,
    input_price_per_million: float,
    cache_input_multiplier: float = 0.1,
    cache_write_multiplier: float = 1.25,
) -> float:
    input_tokens = usage.input_tokens
    cached_tokens = usage.input_tokens_details.cached_tokens
    cache_write_tokens = usage.input_tokens_details.cache_write_tokens
    ordinary_input_tokens = input_tokens - cached_tokens - cache_write_tokens

    weighted_input_tokens = (
        ordinary_input_tokens
        + cached_tokens * cache_input_multiplier
        + cache_write_tokens * cache_write_multiplier
    )
    input_cost = weighted_input_tokens * input_price_per_million / 1_000_000
    return input_cost

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17def calculate_input_cost(
  usage,
  input_price_per_million,
  cache_input_multiplier = 0.1,
  cache_write_multiplier = 1.25
)
  input_tokens = usage.input_tokens
  details = usage.input_tokens_details
  cached_tokens = details.cached_tokens
  cache_write_tokens = details.cache_write_tokens
  ordinary_input_tokens = input_tokens - cached_tokens - cache_write_tokens

  weighted_input_tokens = ordinary_input_tokens +
                          (cached_tokens * cache_input_multiplier) +
                          (cache_write_tokens * cache_write_multiplier)
  (weighted_input_tokens * input_price_per_million) / 1_000_000
end

• Behalte vorhandene stabile Präfixe bei.
• Wenn du prompt_cache_key verwendest, behalte die vorhandenen Werte bei, damit die Cache-Nutzung weiterhin getrennt nach Kundschaft oder Nutzenden erfasst wird.
• Ersetze prompt_cache_retention durch prompt_cache_options.ttl.
• Stelle sicher, dass wiederverwendbare Präfixe die Mindestlänge für das Caching des Modells erreichen.
• Wenn der standardmäßige Breakpoint Inhalte einschließt, die sich zwischen Anfragen ändern, füge nach dem stabilen Präfix einen expliziten Breakpoint hinzu.
• Verwende prompt_cache_options.mode: "explicit", wenn es sich nicht lohnt, nachfolgende Inhalte in den Cache zu schreiben.
• Vergleiche cached_tokens, cache_write_tokens, Latenz und Gesamtkosten vor und nach der Migration.

Betrachte ein LLM, das in einem einzelnen Dialogschritt bewertet, ob eine abgeschlossene Interaktion mit einem Chatbot Hinweise auf die Zufriedenheit der nutzenden Person enthält. Jede Anfrage verwendet dasselbe Bewertungsraster und dieselben mit Labels versehenen Few-Shot-Beispiele, um eine andere Interaktion zu bewerten.

• Präfix beibehalten: Das feste Bewertungsraster und die Beispiele stehen am Anfang. Ihre Gesamtlänge wird bewusst knapp über der Mindestlänge für das Caching des Modells gehalten. Dafür wird Material verwendet, das die Bewertung durch das LLM kalibriert. Die zu bewertende Interaktion steht am Ende.
• Caching-Modus und Breakpoint: Das Caching ist auf explizite Breakpoints beschränkt. Ein Breakpoint steht nach dem festen Bewertungsraster und den Beispielen. Die zu bewertende Unterhaltung zwischen der nutzenden Person und dem Chatbot folgt nach diesem Breakpoint und wird nicht in den Cache geschrieben. So entstehen keine Cache-Schreibkosten für Inhalte, die voraussichtlich nicht wiederverwendet werden.

Bei einer beispielhaften Bereitstellung nach diesen Prinzipien wurde eine Cache-Trefferquote für Token von etwa 70 % gemeldet. Dieser Wert veranschaulicht ein mögliches Ergebnis. Die tatsächlich erreichbare Cache-Trefferquote hängt von deinem Kontext und der Nutzung deiner Anwendung ab.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Judge whether the completed interaction provides evidence that the user is satisfied. Return true or false. Full grading rubric and labeled few-shot examples...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "user",
      "content": "Completed interaction to evaluate..."
    }
  ]
}

Betrachte einen Agenten, der über mehrere Dialogschritte hinweg arbeitet, lange, gemeinsam genutzte Entwickleranweisungen erhält und häufig Tools aufruft. Typischerweise führen Nutzende mehrere Sitzungen mit dem Agenten gleichzeitig aus und forken häufig die Threads.

• Präfix beibehalten: In jedem Dialogschritt werden neue Nachrichten, Tool-Aufrufe und Ergebnisse angehängt, ohne früheren Kontext umzuschreiben. So wächst das wiederverwendbare Präfix mit der Zeit.
• Optionaler Prompt-Cache-Schlüssel: Dieses Beispiel verwendet agent_123_v1:user_456, um die Cache-Nutzung für die Person mit der Nutzer-ID 456 getrennt zu erfassen. Dadurch lassen sich ihre Nutzung gecachter Token und deren Abrechnung leichter nachvollziehen. Dies hilft außerdem zu verhindern, dass Nutzende durch gezielte Anfragen Cache-Treffer anderer Nutzender erkennen können. Der Schlüssel bleibt über alle Sitzungen und Forks dieser Person mit dem Agenten hinweg gleich. Lass ihn weg, wenn deine Anwendung diese Trennung nicht benötigt.
• Impliziter Caching-Modus: Implizites Caching ist aktiviert, sodass die letzte dafür geeignete Nutzer- oder Tool-Nachricht einen Breakpoint liefert.
• Explizite Breakpoints: Nach jedem Tool-Ergebnis wird ein Breakpoint hinzugefügt, um frühere wiederverwendbare Präfixe zu erhalten und den Cache beim Forken effizienter zu nutzen.

Bei einer beispielhaften Bereitstellung nach diesen Prinzipien wurde eine Cache-Trefferquote für Token von >90 % gemeldet. Dieser Wert veranschaulicht ein mögliches Ergebnis. Die tatsächlich erreichbare Cache-Trefferquote hängt von deinem Kontext und der Nutzung deiner Anwendung ab.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "medium" },
  "prompt_cache_key": "agent_123_v1:user_456",
  "prompt_cache_options": { "mode": "implicit" },
  "tools": [
    {
      "type": "function",
      "name": "function_name",
      "description": "Function description",
      "parameters": { "...": "..." }
    }
  ],
  "input": [
    {
      "role": "developer",
      "content": "Stable developer instructions and reference material..."
    },
    { "role": "user", "content": "Can you do...?" },
    {
      "type": "function_call",
      "call_id": "call_123",
      "name": "function_name",
      "arguments": "..."
    },
    {
      "type": "function_call_output",
      "call_id": "call_123",
      "output": [
        {
          "type": "input_text",
          "text": "Tool result...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "assistant", "content": "Assistant response..." },
    { "role": "user", "content": "Can you also do...?" }
  ]
}

Dies tritt besonders häufig bei der Migration von früheren Modellen zu GPT-5.6 oder neuer auf, weil sich das Verhalten des impliziten Cachings geändert hat. Wenn Anfragen ein langes gemeinsames Präfix, aber unterschiedliche Suffixe haben, wird das kürzere gemeinsame Präfix nicht dadurch wiederverwendbar, dass die erste vollständige Anfrage ausschließlich implizit gecacht wird.

Angenommen, jede Anfrage enthält eine statische Developer-Nachricht, gefolgt von einer dynamischen Nutzernachricht. Diese Anfrage schreibt den Inhalt einschließlich des dynamischen Teils in den Cache. Ändert sich dieser Teil in der nächsten Anfrage, stimmt sie nicht mehr mit dem längeren gecachten Präfix überein. Nach dem statischen Inhalt gibt es keinen separaten Breakpoint.

1
2
3
4
5
6
7
8
9
10{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "implicit" },
  "input": [
    { "role": "developer", "content": "Static content..." },
    { "role": "user", "content": "Dynamic content..." }
  ]
}

Setze in beiden Anfragen einen expliziten Breakpoint nach dem statischen Inhalt, um das Problem zu beheben. Die erste Anfrage schreibt das wiederverwendbare Präfix in den Cache. Die nächste kann es auch dann wiederverwenden, wenn sich der dynamische Inhalt ändert. Dieses Beispiel verwendet den ausschließlich expliziten Modus, damit der dynamische Inhalt nicht in den Cache geschrieben wird.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17{
  "model": "gpt-5.6-sol",
  "reasoning": { "effort": "medium", "context": "all_turns" },
  "text": { "verbosity": "low" },
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "Static content...",
        "prompt_cache_breakpoint": { "mode": "explicit" }
      }]
    },
    { "role": "user", "content": "Dynamic content..." }
  ]
}

Angenommen, Anfrage 1 verwendet den impliziten Modus und cacht ein Präfix bis zum Ende einer Nutzernachricht. Die nachfolgende Anfrage 2 behält dieses Präfix bei, wechselt aber zu prompt_cache_options.mode: "explicit". Wie unter So funktioniert der Präfixabgleich erläutert, prüft Anfrage 2 nur die expliziten Breakpoints in ihrer eigenen Eingabe. Deshalb verwendet sie das implizit gespeicherte Präfix aus Anfrage 1 nicht wieder, es sei denn, einer der expliziten Breakpoints in Anfrage 2 stimmt mit dem gecachten Endpunkt aus Anfrage 1 überein.

▼ = breakpoint

- Request 1: implicit mode
  [Developer message][User message] ▼

- Request 2: explicit-only mode. Does not hit cache.
  [Developer message][User message][Follow-up] ▼

Um das implizite Präfix aus Anfrage 1 wiederzuverwenden, setze in Anfrage 2 einen expliziten Breakpoint an der entsprechenden Inhaltsblockgrenze. Alternativ kannst du den impliziten Modus aktiviert lassen, damit das Ende der früheren geeigneten Nachricht weiterhin bei der Cache-Suche berücksichtigt wird.

Selbst wenn beide Anfragen den impliziten Modus verwenden, reicht es nicht immer aus, dieselben Anfangstoken beizubehalten. Angenommen, Anfrage 1 endet mit einer Nutzernachricht, die Content A enthält. Die nachfolgende Anfrage 2 erweitert dieselbe Nachricht auf Content A + Content B. Der bisherige Endpunkt nach Content A liegt nun innerhalb einer Nachricht statt an ihrem Ende. Wie unter So funktioniert der Präfixabgleich erläutert, verwendet Anfrage 2 das dort gespeicherte Präfix ohne einen expliziten Breakpoint an dieser Grenze nicht wieder.

▼ = breakpoint

- Request 1: implicit mode
  [Developer message][User message: Content A] ▼

- Request 2: implicit mode. Cannot reuse the prefix through Content A.
  [Developer message][User message: Content A + Content B] ▼

Wenn die Gesprächsstruktur es zulässt, behalte die ursprüngliche Nachricht bei und hänge stattdessen eine neue Nachricht an. Andernfalls lege den wiederverwendbaren Text in einem separaten Inhaltsblock ab und setze in beiden Anfragen einen expliziten Breakpoint dahinter.

Im impliziten Modus werden Developer-Nachrichten nach dem anfänglichen zusammenhängenden Block von Developer-Nachrichten nicht automatisch als Grenzen für die Cache-Suche verwendet. Setze einen expliziten Breakpoint am Ende der wiederverwendbaren Developer-Nachricht und behalte ihn in nachfolgenden Anfragen bei. So kann OpenAI nach einem passenden gecachten Präfix suchen.

Ein Präfix, das bei einem Modell gecacht werden kann, ist bei einem anderen möglicherweise zu kurz. Sieh dir den Modellvergleich an und miss das wiederverwendbare Präfix mit dem Modell und den Einstellungen, die du tatsächlich verwendest. Wiederhole diese Prüfung bei einem Modellwechsel, statt davon auszugehen, dass der Schwellenwert des vorherigen Modells weiterhin gilt.

Compaction (Kontextverdichtung) ersetzt früheren Gesprächskontext durch eine kürzere Darstellung. Dadurch kann sich das Präfix ändern. Die erste Anfrage nach der Compaction (Kontextverdichtung) kann daher möglicherweise weniger vom bisherigen Cache wiederverwenden, auch wenn das Gespräch inhaltlich unverändert ist.

Halte wiederverwendbare Anweisungen und Referenzmaterial möglichst unverändert und lasse nachfolgende Gesprächsrunden auf dem verdichteten Kontext aufbauen. Vergleiche die gesamten Eingabekosten vor und nach der Compaction (Kontextverdichtung): Weniger Eingabetoken können auch dann Kosten sparen, wenn die Cache-Trefferquote sinkt.

Nein. Prompt-Caching ändert nicht, wie das Modell Ausgabetoken generiert. Das Modell erzeugt anhand des gecachten Präfixes eine neue Antwort. Identische Anfragen liefern daher nicht garantiert identische Ausgaben.

Nein. Der Cache lässt sich derzeit nicht manuell leeren. Cache-Einträge laufen gemäß der Cache-Lebensdauer und den Aufbewahrungseinstellungen des Modells ab.

Ja. Gecachte Eingabetoken werden weiterhin auf die Limits für Token pro Minute angerechnet. Prompt-Caching ändert nichts daran, wie Ratenlimits berechnet werden.