GPT-5.6 Kostenguide: Prompt Caching 90 % günstiger, Reasoning Effort

GPT-5.6 bewegt beide Kostenhebel gleichzeitig: Gecachter Input fällt auf 10 % des Input-Tarifs (bei 5.x waren es noch 50 % Rabatt), und weil Reasoning standardmäßig aktiv ist, kostet ein fehlendes reasoning_effort das 1,5-fache gegenüber einem fest gesetzten none – gemessen über unsere Matrix aus 50 Calls, bei identischen Antworten. Auf der Input-Seite lassen sich jetzt bis zu vier Cache-Breakpoints explizit setzen; auf der Output-Seite entscheidet der Effort-Regler, wie viel Denkarbeit du bezahlst. Wir haben beide Hebel über das Gateway an den Day-One-Modellen vermessen: Sol (5 $/30 $ pro 1M Token in/out), Terra (2,50 $/15 $) und Luna (1 $/6 $), jeder Tarif gegen den Live-Zähler usage.cost bestätigt.

TL;DR

• Gecachter Input wird mit 10 % des Input-Tarifs abgerechnet, gemessen 0,10 $/0,25 $/0,50 $ pro 1M über die Tiers; bei 5.x waren es 50 % Rabatt.
• Breakpoints ermöglichen teilweise Wiederverwendung: Änderte man den Block nach einem Marker, wurden nur 1.210 von 2.431 Token neu berechnet.
• Präfixe unter 1.024 Token cachen nie, und Wiederholungen können still danebengehen; kalkuliere mit Trefferquoten unter 100 %.
• Cache-Writes werden mit 1,25x auf die geschriebenen Token abgerechnet; ein nie gelesener Write kostet mehr als gar kein Caching.
• Ein weggelassenes reasoning_effort kostete über eine 4-Task-Matrix das 1,5-fache von none, bei identischen Antworten; setze es explizit.

Gemessen am 10.07.2026 über das Synthorai-Gateway (OpenAI-kompatible Chat Completions), einen Tag nachdem OpenAI die Familie vorgestellt hat. Alle drei Modelle sind live; die neuen Caching-Parameter werden unverändert durchgereicht.

Drei Tiers, eine Generation

Das Namensschema ist neu: Die Zahl steht für die Generation, und Sol, Terra und Luna sind Leistungs-Tiers, die die Suffixe pro/mini/nano ersetzen. Alle drei teilen sich ein Kontextfenster von 1M Token und 128K max. Output. Jeder Tarif unten stimmt exakt mit dem gemessenen usage.cost auf bekannten Token-Zahlen überein, inklusive der Cached-Spalte:

Sol ist das Flaggschiff und der preisgleiche Nachfolger von gpt-5.5: Die Preisliste ist mit 5 $/30 $ identisch. Terra und Luna sind die abgespeckten Tiers derselben Generation, zum halben bzw. fünftel des Sol-Preises, und übernehmen die Plätze, die früher die Suffixe mini und nano hatten. Fürs Token-Counting sind die drei ein einziges Modell: Alle lieferten bei jedem gesendeten Sample identische Zählungen.

Wie das Caching in 5.6 laut Doku funktioniert

Bislang gab es beim GPT-Caching nur ein Verhalten: Die API erkannte wiederholte Prefixe ab 1.024 Tokens von selbst und rechnete den gecachten Anteil zum halben Preis ab. Genau deshalb stand die GPT-Spalte in unserem Provider-Vergleich unter “vollautomatisch”. Der Caching-Guide für 5.6 ersetzt das durch ein Design mit zwei Modi:

{
  "model": "gpt-5.6-luna",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    {
      "role": "system",
      "content": [
        {
          "type": "text",
          "text": "...stable system prompt, 1024+ tokens...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "user", "content": "the varying part" }
  ]
}

Die entscheidenden Regeln, zusammengefasst aus dem Guide:

• Ein Breakpoint markiert das Ende eines gecachten Prefixes und deckt diesen Block sowie alles davor ab. Im Modus implicit (Standard) setzt die API weiterhin automatisch einen Breakpoint auf die letzte Nachricht; im Modus explicit wird nur gecacht, was du selbst markierst.
• Vier Cache-Writes pro Request, wobei der automatische Breakpoint im impliziten Modus einen davon verbraucht. Damit bleiben explizite Marker im Standardmodus drei Slots und im expliziten Modus vier. Breakpoints aus früheren Turns der Konversation sind bei späteren Requests nur lesbar.
• Die Untergrenze von 1.024 Tokens bleibt bestehen: Ein markierter Prefix darunter wird nicht gecacht.
• ttl: "30m" ist eine garantierte Mindestlebensdauer, keine Obergrenze (“at least 30 minutes… may retain it longer”). Es ersetzt prompt_cache_retention, das auf 5.6 deprecated ist, und damit fällt auch die alte Option 24h für verlängerte Retention weg.
• Über prompt_cache_key bekommst du zuverlässige Treffer: Der Guide empfiehlt einen stabilen Key pro Tenant oder Session, damit Wiederholungen an denselben Cache geroutet werden, mit einem Soft-Limit von rund 15 Requests pro Minute und Key. Caches sind auf deine Organisation beschränkt.
• Cache-Writes werden mit dem 1,25-fachen Input-Preis abgerechnet, ab 5.6+, ausgewiesen im neuen Feld usage.prompt_tokens_details.cache_write_tokens. Auf 5.x und davor waren Writes kostenlos.

GPT-5.5 und älter lehnen die neuen Parameter mit einem sauberen 400 ab (prompt_cache_options is not supported on this model), also solltest du jedes Rollout an die Version koppeln.

Falls dir das Design bekannt vorkommt: Marker auf Content-Blöcken, vier Breakpoints, ein Aufschlag für Writes und eine gleitende, nur lesbare History sind genau die Form, die Claudes cache_control schon immer hatte. Der Unterschied liegt in der TTL: Die garantierte Untergrenze von OpenAI mit 30 Minuten ist das Sechsfache von Claudes Standard von 5 Minuten.

Was das Meter sagt

Doku sind Behauptungen; hier steht, was das Meter des Gateways zurückgegeben hat, Probe für Probe. Die vollständigen Rohdaten liegen im Run-Log; jeder Kostenwert unten stimmt auf die Ziffer genau mit den Tarifsätzen überein.

Drei dieser Zeilen sind eine genauere Betrachtung wert.

Teilweise Wiederverwendung funktioniert, und genau deshalb lohnt sich der Einsatz von Breakpoints. Bei stabilem Block A und getauschtem Tail B rechnete das Meter nur den Tail neu ab: 1.212 Tokens zum Cached-Satz zurückgelesen, 1.210 für das neue B zum Write-Aufschlag geschrieben, aus einem Prompt mit 2.431 Tokens, und die Summe stimmt auf die Ziffer mit dem Tarifblatt überein. Das ist das Layered-Prefix-Verhalten (System-Prompt, dann Tools, dann Dokumente, jeweils markiert), um das herum Claude-Nutzer ihre Prompts strukturieren, und das GPTs automatischer Modus nie garantieren konnte. Eine Fußnote: Bei vollen Wiederholungen springt die getroffene Länge manchmal unter die Markierung (1.897 von einem 2.422-Token-Write in einer Probe), also kalkuliere mit dem Rabattsatz, nicht mit exakten Match-Zahlen.

Der Schwellenwert und die stillen Fehlgriffe sind die operativen Fallen. Ein markierter Block mit 621 Token cachte nichts, zweimal, ohne Fehler und ohne Nutzungshinweis über die Nullen hinaus; wenn Ihr „stabiles Präfix” ein kurzer System-Prompt ist, zahlen Sie den vollen Preis, und nichts sagt es Ihnen. Und ein Fehlgriff kann ohne Schreibvorgang eintreten, zum vollen Preis, ebenso still. Die Trefferquote ist eine Verteilung, kein Versprechen, welchen Weg Ihre Anfragen auch nehmen: Lesen Sie cached_tokens in der Produktion und alarmieren Sie darauf, so wie es unser fünfminütiges Cache-Audit tut.

Der Write-Aufschlag ist real, und er verschiebt den Break-even. Geschriebene Tokens werden auf allen drei Tiers zu exakt 1,25x des Input-Satzes abgerechnet (Luna-Writes metern zu 1,25 $ pro Million, Terra zu 3,125 $, Sol zu 6,25 $) und stimmen bei jeder Probe im finalen Run auf die Ziffer überein. Dieser Aufschlag zahlt sich erst aus, sobald das Prefix erneut gelesen wird: ein Write ohne Treffer kostet 25 % mehr als gar kein Caching, dieselbe Falle, die wir bei Claudes Write-Aufschlag im LangChain-Post gemessen haben. Markiere Prefixes, von denen du weißt, dass sie sich wiederholen, nicht alles, was stabil aussieht.

Der 30-Minuten-Boden hielt, soweit wir ihn ausgelotet haben. Ein per Schlüssel erneutes Auslesen 15 Minuten nach dem Schreibvorgang kam vollständig gecacht zurück (1.313 von 1.313 Tokens, abgerechnet zum 10%-Satz), weit über den alten In-Memory-Horizont von 5 bis 10 Minuten hinaus, und eine zweite per Schlüssel durchgeführte Prüfung mit demselben Abstand wiederholte das Ergebnis. Wir haben die vollen 30 Minuten nicht ausgelotet.

Zum Vergleich dieselbe Last auf GPT-5.5

Der faire Vergleich läuft über gleiche Preise: Sol hat exakt die Preisliste von gpt-5.5 ($5/$30) und ist damit der direkte Nachfolger, mit Terra und Luna als abgespeckten Stufen darunter. Gleicher Listenpreis, aber ganz andere Caching-Konditionen:

Bei gleichem Listenpreis sind die Caching-Bedingungen das Upgrade. Ein Präfix mit 3.000 Tokens kostet auf 5.5 $0.0075 pro Aufruf, wenn sein automatischer Cache einen Treffer beschließt, und $0.0015 auf warmem Sol, 5x weniger für den gecachten Anteil. Die tiefergehende Änderung betrifft Kontrolle und Sichtbarkeit: Die Treffer von 5.5 hängen von einer undurchsichtigen Präfix-Erkennung ab, die man weder auslösen noch debuggen kann, während 5.6 es dir erlaubt, genau zu markieren, was gecacht werden soll, Wiederholungen mit einem prompt_cache_key zu routen und jeden Schreibvorgang in usage zu beobachten. Ein Fehltreffer erscheint jetzt als Null in einem Feld, das du erstellt hast, nicht als Schweigen. Der Herabstufungspfad kommt obendrauf: Wenn 5.5 die Arbeitslast überversorgt hat, halbiert Terra die gesamte Preisliste und Luna teilt sie durch fünf, und dasselbe warme Präfix fällt auf $0.00075 und $0.0003. Das Einzige, was 5.5 beibehält, ist die optionale 24-Stunden-Aufbewahrung; wenn dein Traffic ein täglicher Batch gegen ein riesiges Präfix ist, läuft dieser Kompromiss andersherum. Und beachte, dass der zweite Hebel bei der Migration in die andere Richtung wirkt: 5.6 schlussfolgert standardmäßig, sodass eine 5.5-Arbeitslast, die ohne fixiertes reasoning_effort umgezogen wurde, neue Ausgabekosten zur selben Preisliste aufnimmt.

Der zweite Hebel: Reasoning-Aufwand

Caching bestimmt, was du für den Input bezahlst; reasoning_effort bestimmt die Output-Seite, denn Reasoning-Tokens werden zum Output-Tarif abgerechnet und lassen sich – anders als dein Prefix – nie cachen. GPT-5.6 akzeptiert auf allen Tiers none bis xhigh. Der Launch-Post führt außerdem einen Aufwand max für Sol ein; über Chat Completions gibt es den nicht (400: 'reasoning_effort' does not support 'max' with this model, bei Sol wie bei Terra), also ist xhigh in der Praxis die Obergrenze auf dem API-Pfad, den Gateways und SDKs nutzen.

Wir haben eine Matrix aus 50 Calls gefahren: vier Aufgabentypen (eine Rezension klassifizieren, ein Feld aus einer Log-Zeile extrahieren, eine mehrstufige arithmetische Textaufgabe, eine kleine Code-Generierungsaufgabe) über alle sechs Einstellungen, none bis xhigh plus den weggelassenen Parameter, auf Terra und Luna mit einem Stichproben-Check auf Sol. Alle 50 Antworten waren bei jeder Einstellung korrekt. Was variierte, war die Rechnung. Das sind Calls mit kurzem Output (Dutzende sichtbare Tokens), also dominieren ein paar Dutzend Reasoning-Tokens zum Output-Tarif die Gesamtsumme; die Ratio-Spalte vergleicht die Kosten des gesamten Calls:

Drei Erkenntnisse. Erstens ist 5.6 von sich aus adaptiv: bei den beiden trivialen Typen verbrauchte keine Einstellung auch nur ein Reasoning-Token, dort ist der Knopf also gratis. Zweitens denkt der Default bei Typen, die nach Nachdenken aussehen (math, code), auch dann, wenn es nichts bringt: den Parameter wegzulassen kostete auf Lunas math und code sowie Terras math das 2,5- bis 3,5-Fache des none-Preises (Terras code-Lauf verbrauchte beim Default zufällig nichts) für dieselben korrekten Antworten, und über das gesamte Terra-und-Luna-Raster summiert das 1,5-Fache. Drittens sind die Zwischeneinstellungen (nicht in der Tabelle) Rauschen, kein Regler: Terras math-Lauf verbrauchte 19 Reasoning-Tokens bei low, null bei medium, 21 bei high und wieder null bei xhigh, und Lunas code-Lauf verbrauchte 101 bei xhigh gegenüber 41 bei high. Die Namen sind Absichten, keine Budgets – dasselbe Verhalten, das wir bei GLM 5.2 gemessen haben.

Schick reasoning_effort bei jedem Call explizit mit und setze den Default auf none für Klassifizierung, Extraktion, Routing und kurze Transformationen. Erhöhe eine konkrete Call-Site nur dann, wenn deine Evals zeigen, dass die höhere Einstellung das Ergebnis ändert – nicht weil sich die Aufgabe schwer anfühlt. Unsere vier Typen sind API-Workloads mit kurzem Output; wirklich schwere mehrstufige Arbeit rechtfertigt ihren Reasoning-Aufwand vielleicht, aber lass die Messungen entscheiden.

Die beiden Hebel verstärken sich gegenseitig. Ist ein Prefix erst warm, kostet die Input-Seite eines Luna-Calls ein Zehntel des Listenpreises, und der Reasoning-Default wird bei kurzen Aufgaben zum größten verbleibenden Posten: Lunas math-Call kostete bei none insgesamt $0,00007 und mit weggelassenem Parameter $0,00025 – allein der Reasoning-Default fügte $0,00018 hinzu, mehr als das Doppelte des gesamten Managed Calls. Cachst du, ohne den Aufwand festzunageln, sickern die Einsparungen auf der anderen Seite wieder ab.

Empfehlung je nach Workload

Die Entscheidung hat jetzt eine echte Struktur. Das raten wir Gateway-Kunden:

Unabhängig von der Form: Senden Sie einen stabilen prompt_cache_key pro Tenant oder Session (die Dokumentation macht den Schlüssel zur Grundlage für zuverlässiges Matching), halten Sie jede markierte Ebene über der Untergrenze von 1.024 Tokens und überwachen Sie cached_tokens, weil stille Fehltreffer existieren. Denken Sie daran, dass die Caches pro Modell gelten: Ein A/B-Test über verschiedene Tiers hinweg wärmt auf jeder Seite von Null neu auf. Und setzen Sie den anderen Hebel im selben Commit: Fixieren Sie reasoning_effort gemäß der obigen Matrix, none, sofern eine Evaluation nichts anderes ergibt.

Bei der Tier-Wahl verschiebt der 90-%-Rabatt die Rechnung stärker als das Tier selbst. Ein Workload, der ein 3.000-Token-Präfix erneut abspielt, zahlt bei warmem Luna-Traffic etwa 0,30 $ pro tausend Calls für dieses Präfix und 1,50 $ bei warmem Sol; der Abstand zwischen den Tiers beim gecachten Anteil ist kleiner als der Abstand bei den Output-Tokens. Also das Tier nach Output-Qualität und Preis wählen und den Input durch Caching glätten lassen. Wer von gpt-5.5 kommt, bekommt mit Sol das Drop-in-Upgrade zur gleichen Rate Card, mit 5x günstigeren Cache-Reads und Kontrolle darüber, wann sie passieren; auf Terra oder Luna heruntergehen, wo deine Evals sagen, dass das kleinere Tier trägt, und die Rate Card halbiert oder fünftelt sich obendrauf.

Der Tokenizer hat sich nicht geändert

Unsere 24 Samples (ein Erzähltext in neun Sprachen, technische und News-Versionen in sechs davon, eine Python-Funktion und ein JSON-Tool-Call) werden über GPT-5.5, Sol, Terra und Luna hinweg in jedem abgeschlossenen Vergleich identisch gezählt. Token-Budgets und Cache-Floor-Schätzungen, die auf 5.5 kalibriert sind, gelten unverändert weiter; das sprachübergreifende Verhalten steht in unserem Tokenizer-nach-Sprache-Post und trifft auf 5.6 unverändert zu.

Fazit

• Dass der Cache-Rabatt von 50 % auf 90 % steigt, bei garantierten 30 Minuten TTL, ist die eigentliche Preissenkung dieses Releases; die Tier-Preise sind die Schlagzeile, aber die Caching-Konditionen bewegen echte Rechnungen stärker.
• Für geschichtete Prompts explizite Breakpoints einsetzen: die teilweise Wiederverwendung ist gemessen, nicht theoretisch, und das mentale Modell überträgt sich eins zu eins von Claude.
• Die 1.024-Token-Grenze beachten, einen prompt_cache_key senden und cached_tokens überwachen; sowohl stille Misses als auch stilles Gar-nicht-Cachen kommen vor.
• reasoning_effort explizit senden, Default none: der ungesteuerte Default hat über unsere Matrix hinweg das 1,5-Fache berechnet, bei einzelnen Tasks bis zum 3,5-Fachen, für identische Antworten.
• xhigh ist die erreichbare Obergrenze (max mit 400s über Chat Completions); keine Tokenizer-Neukalibrierung gegenüber 5.5.

FAQ

Unterstützt GPT-5.6 explizites Prompt Caching wie Claude? Ja. prompt_cache_options: {"mode": "explicit"} zusammen mit prompt_cache_breakpoint-Markern an Content-Blöcken, bis zu vier Writes pro Request (drei im impliziten Modus, wo der automatische Breakpoint einen Slot belegt). Gemessen über ein OpenAI-kompatibles Gateway: Ein markiertes Präfix von 3.012 Token wurde beim ersten Aufruf geschrieben und beim zweiten vollständig zum Cache-Tarif zurückgelesen.

Was kostet Cached Input bei GPT-5.6? 10 % des Input-Tarifs, gemessen über alle drei Tiers: 0,10 $ pro Million bei Luna, 0,25 $ bei Terra, 0,50 $ bei Sol. GPT-5.x hat gecachte Token mit 50 % des Inputs abgerechnet, damit liegt der Tarif für gecachte Token bei 5.6 um das 5-Fache niedriger.

Ist das Caching von GPT-5.6 besser als das von GPT-5.5? Bei Rabatthöhe und Kontrolle ja: 10 % Cache-Tarif statt 50 %, vier explizite Breakpoints statt reiner automatischer Erkennung, die man weder auslösen noch debuggen kann, und ein fester Mindestwert von 30 Minuten statt 5–10 Minuten Best Effort. Der einzige verbleibende Vorteil von 5.5 ist der optionale 24-Stunden-Retention-Tier, den 5.6 streicht.

Wie lange lebt der GPT-5.6-Cache? Die Dokumentation garantiert mindestens 30 Minuten (ttl: "30m" ist der einzige akzeptierte Wert), möglicherweise länger; die Option ersetzt das veraltete prompt_cache_retention, einschließlich der alten erweiterten 24-Stunden-Stufe. In unseren Tests trafen mit Schlüssel versehene erneute Lesevorgänge 15 Minuten nach dem Schreibvorgang vollständig; die vollen 30 haben wir nicht getestet.

Brauche ich prompt_cache_key? Senden Sie ihn: Die Dokumentation macht einen stabilen Schlüssel pro Mandant oder Sitzung zur Grundlage für zuverlässiges Matching bei 5.6, mit einer weichen Grenze von etwa 15 Anfragen pro Minute pro Schlüssel. Es kostet nichts, ihn einzubeziehen, und die Kombination mit cached_tokens-Monitoring ist der Weg, um zu überprüfen, ob der Rabatt tatsächlich greift.

Wie stark ändert reasoning_effort die Kosten von GPT-5.6? In unserer Matrix aus 50 Aufrufen (vier Task-Formen, sechs Settings, Terra und Luna) lieferte jedes Setting korrekte Antworten, und das Weglassen des Parameters kostete insgesamt das 1,5-Fache von none, bei der Arithmetik-Task bis zum 3,5-Fachen. Bei trivialen Formen (Klassifikation, Extraktion) verbrauchte kein Setting überhaupt Reasoning-Token. Fixiere none und eskaliere nur auf Basis von Evals.

Ist der maximale Reasoning Effort bei GPT-5.6 Sol verfügbar? Nicht über Chat Completions. Requests mit reasoning_effort: "max" geben einen 400 zurück, der none bis xhigh auflistet, auf Sol wie auf Terra.

Welchen GPT-5.6-Tier sollte ein API-Workload nutzen? Sol ist der preisgleiche Nachfolger von gpt-5.5 (identische Preisliste 5 $/30 $, 5x günstigere Cache-Reads); Terra und Luna sind die abgespeckten Tiers zur Hälfte bzw. zu einem Fünftel davon. Sobald dein Präfix stabil und keyed ist, glättet der 90-%-Cache-Rabatt die Input-Seite, also geh so weit runter, wie es deine Evals zur Output-Qualität erlauben, und lass den Tier den Output-Preis bestimmen.

← Zurück zum Blog