GPT-5.6-Kosten: 90 % Rabatt via Prompt Caching, Reasoning Effort

GPT-5.6 setzt an beiden Kostenhebeln gleichzeitig an: Gecachter Input kostet nur noch 10 % des regulären Input-Tarifs, während 5.x lediglich 50 % Rabatt bot. Reasoning ist standardmäßig aktiv. In unserer Matrix mit 50 Aufrufen verursachte das Weglassen von reasoning_effort daher 1,5-mal so hohe Kosten wie die explizite Einstellung none - bei identischen Antworten. Auf der Input-Seite lassen sich jetzt bis zu vier Cache-Breakpoints explizit setzen. Auf der Output-Seite bestimmt die Effort-Einstellung, wie viel Reasoning abgerechnet wird. Wir haben beide Hebel direkt zum Start über das Gateway vermessen: Sol ($5/$30 pro 1M Input-/Output-Token), Terra ($2.50/$15) und Luna ($1/$6). Sämtliche Tarife wurden mit dem Live-Zähler usage.cost abgeglichen.

TL;DR

• Gecachter Input wird mit 10 % des Input-Tarifs abgerechnet. Gemessen wurden je nach Tier $0.10/$0.25/$0.50 pro 1M Token; bei 5.x waren es 50 %.
• Breakpoints ermöglichen partielle Wiederverwendung: Nach einer Änderung des Blocks hinter einem Marker wurden von 2.431 Token nur 1.210 erneut abgerechnet.
• Präfixe unter 1.024 Token werden nie gecacht, und wiederholte Requests können unbemerkt verfehlen. Bei der Kostenplanung sollte die Trefferquote daher unter 100 % angesetzt werden.
• Cache-Schreibvorgänge kosten für die geschriebenen Token das 1,25-Fache. Ein Cache-Eintrag, der nie gelesen wird, ist teurer als gar kein Caching.
• Ohne reasoning_effort lagen die Kosten in einer Matrix aus vier Aufgaben 1,5-mal so hoch wie mit none, obwohl die Antworten identisch waren. Setzt den Wert explizit.

Gemessen am 2026-07-10 über das Synthorai-Gateway mit OpenAI-kompatiblen Chat Completions, einen Tag nachdem OpenAI die Modellfamilie angekündigt hatte. Alle drei Modelle sind verfügbar; die neuen Caching-Parameter werden unverändert durchgereicht.

Drei Tiers, eine Generation

Das Namensschema ist neu: Die Zahl bezeichnet die Generation. Sol, Terra und Luna stehen für verschiedene Leistungsstufen und ersetzen die bisherigen Suffixe pro, mini und nano. Alle drei bieten ein Kontextfenster mit 1M Token und maximal 128K Output-Token. Die folgenden Preise stimmen bei bekannten Token-Mengen exakt mit dem gemessenen usage.cost überein, einschließlich der Spalte für gecachten Input:

Sol ist das Flaggschiff und der preislich gleich positionierte Nachfolger von gpt-5.5: Die Preisliste ist mit $5/$30 identisch. Terra und Luna sind die kleineren Tiers derselben Generation. Sie kosten die Hälfte beziehungsweise ein Fünftel von Sol und übernehmen damit die bisherigen Plätze von mini und nano. Bei der Token-Zählung verhalten sich alle drei wie ein einziges Modell: Für sämtliche gesendeten Samples lieferten sie identische Werte.

So funktioniert das Caching bei 5.6 laut Dokumentation

Bisher kannte GPT-Caching nur einen Modus: Die API erkannte wiederholte Präfixe ab 1.024 Token automatisch und rechnete den gecachten Anteil zum halben Preis ab. Deshalb führten wir GPT in unserem Provider-Vergleich als „vollautomatisch“. Der Caching-Leitfaden für 5.6 ersetzt dieses Verfahren durch 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 relevanten Regeln aus dem Leitfaden:

• Ein Breakpoint markiert das Ende eines gecachten Präfixes. Er umfasst den jeweiligen Block und alle davorliegenden Inhalte. Im standardmäßigen Modus implicit wird weiterhin automatisch ein Breakpoint an der neuesten Nachricht gesetzt. Im Modus explicit werden nur explizit markierte Inhalte gecacht.
• Pro Request sind vier Cache-Schreibvorgänge möglich. Der automatische Breakpoint im Modus implicit belegt einen davon. Damit bleiben dort drei Plätze für explizite Marker, im Modus explicit dagegen vier. Breakpoints aus früheren Conversation-Turns können in späteren Requests nur gelesen werden.
• Die Untergrenze von 1.024 Token bleibt bestehen: Ein markiertes Präfix darunter wird nicht gecacht.
• ttl: "30m" garantiert eine Mindestlebensdauer, keine Obergrenze („mindestens 30 Minuten … möglicherweise länger“). Der Parameter ersetzt das bei 5.6 veraltete prompt_cache_retention. Damit entfällt auch die bisherige Option 24h für eine längere Aufbewahrung.
• Mit prompt_cache_key werden Wiederholungen zuverlässig zugeordnet: Der Leitfaden empfiehlt einen stabilen Schlüssel pro Tenant oder Session, damit wiederholte Requests denselben Cache erreichen. Pro Schlüssel gilt ein Soft-Limit von ungefähr 15 Requests pro Minute. Caches sind auf die eigene Organisation begrenzt.
• Cache-Schreibvorgänge kosten bei 5.6+ das 1,25-Fache des Input-Tarifs. Die geschriebenen Token stehen im neuen Feld usage.prompt_tokens_details.cache_write_tokens. Bei 5.x und älteren Versionen waren Schreibvorgänge kostenlos.

GPT-5.5 und ältere Modelle weisen die neuen Parameter mit einem klaren 400-Fehler zurück (prompt_cache_options is not supported on this model). Rollouts müssen daher anhand der Modellversion gesteuert werden.

Das Konzept ist bekannt: Marker auf Content-Blöcken, vier Breakpoints, ein Aufpreis für Schreibvorgänge und ein gleitender Verlauf, der nur gelesen werden kann. Genau so funktioniert Claudes cache_control schon immer. Der Unterschied liegt bei der TTL: OpenAI garantiert mindestens 30 Minuten, also das Sechsfache von Claudes standardmäßigen 5 Minuten.

Was der Zähler tatsächlich ausweist

Dokumentation enthält zunächst Behauptungen. Die folgende Tabelle zeigt die Ergebnisse des Gateway-Zählers für die einzelnen Messungen. Die vollständigen Rohdaten stehen im Ausführungsprotokoll. Alle Kosten stimmen bis auf die letzte Stelle mit den jeweiligen Tier-Tarifen überein.

Drei dieser Ergebnisse brauchen mehr Kontext.

Partielle Wiederverwendung funktioniert und ist der wichtigste Grund für Breakpoints. Bei einem stabilen Block A und einem ausgetauschten hinteren Block B berechnete der Zähler nur den hinteren Teil neu: Von einem Prompt mit 2.431 Token wurden 1.212 Token zum Cache-Tarif gelesen und 1.210 Token für den neuen Block B mit Schreibaufschlag gespeichert. Die Gesamtkosten stimmen bis auf die letzte Stelle mit der Preisliste überein. Dieses gestaffelte Präfixmodell - System Prompt, danach Tools, danach Dokumente, jeweils markiert - ist für Claude-Nutzer bereits üblich. Der automatische Modus von GPT konnte es nie garantieren. Eine Einschränkung: Bei vollständigen Wiederholungen lag die erkannte Länge gelegentlich unterhalb der Markierung. In einer Messung wurden von 2.422 geschriebenen Token nur 1.897 wiederverwendet. Kalkuliert daher mit dem reduzierten Tarif, nicht mit exakt übereinstimmenden Token-Zahlen.

Die Untergrenze und unbemerkte Cache Misses sind die operativen Fallstricke. Ein markierter Block mit 621 Token wurde in zwei Durchläufen überhaupt nicht gecacht. Es gab weder einen Fehler noch einen anderen Hinweis als die Nullwerte in den Usage-Daten. Besteht das „stabile Präfix“ nur aus einem kurzen System Prompt, wird weiterhin der volle Preis fällig, ohne dass die API darauf hinweist. Auch ein Cache Miss kann ohne Schreibvorgang zum vollen Preis eintreffen, ebenfalls ohne Meldung. Die Trefferquote ist eine Verteilung, keine Garantie - unabhängig vom Request-Pfad. Erfasst cached_tokens in Produktion und richtet Alerts dafür ein, wie in unserem Audit zum Fünf-Minuten-Cache.

Der Schreibaufschlag existiert und verschiebt den Break-even. Geschriebene Token werden in allen drei Tiers mit exakt dem 1,25-Fachen des Input-Tarifs abgerechnet: Bei Luna misst der Zähler $1.25 pro Million, bei Terra $3.125 und bei Sol $6.25. In jedem Test unseres abschließenden Durchlaufs stimmten die Beträge bis auf die letzte Stelle. Der Aufpreis amortisiert sich erst, wenn das Präfix erneut gelesen wird. Ein Cache-Eintrag ohne späteren Treffer kostet 25 % mehr als gar kein Caching. Dieselbe Falle haben wir bereits bei Claudes Schreibaufschlag im LangChain-Beitrag gemessen. Markiert nur Präfixe, die sich nachweislich wiederholen, nicht alles, was stabil aussieht.

Die garantierte Mindestdauer von 30 Minuten hielt in unseren Messungen. Ein erneuter Request mit Schlüssel war 15 Minuten nach dem Schreibvorgang vollständig gecacht: 1.313 von 1.313 Token zum 10-%-Tarif. Das liegt deutlich über dem bisherigen In-Memory-Zeitraum von 5 bis 10 Minuten. Ein zweiter Test mit Schlüssel und demselben Abstand lieferte dasselbe Ergebnis. Die vollen 30 Minuten haben wir nicht geprüft.

Zum Vergleich: derselbe Workload auf GPT-5.5

Für einen fairen Vergleich muss der Preis gleich sein. Sol übernimmt die exakte Preisliste von gpt-5.5 ($5/$30) und ist damit der direkte Nachfolger. Terra und Luna liegen als kleinere Tiers darunter. Listenpreis identisch, Caching-Konditionen deutlich verändert:

Bei identischem Listenpreis sind die neuen Caching-Konditionen das eigentliche Upgrade. Ein Präfix mit 3.000 Token kostet bei 5.5 pro Aufruf $0.0075, wenn der automatische Cache greift. Mit warmem Cache auf Sol sind es $0.0015, also fünfmal weniger für den gecachten Anteil. Noch wichtiger sind Kontrolle und Transparenz: Bei 5.5 hängen Treffer von einer undurchsichtigen Präfixerkennung ab, die sich weder gezielt auslösen noch debuggen lässt. Mit 5.6 kann exakt markiert werden, was in den Cache gehört. Wiederholungen lassen sich per prompt_cache_key routen, und jeder Schreibvorgang erscheint in usage. Ein Cache Miss zeigt sich jetzt als Null in einem bewusst erzeugten Feld statt durch völlige Unsichtbarkeit. Hinzu kommen die günstigeren Tiers: Wenn 5.5 für den Workload überdimensioniert war, halbiert Terra die gesamte Preisliste, Luna reduziert sie auf ein Fünftel. Dasselbe warme Präfix kostet dann $0.00075 beziehungsweise $0.0003. Einen Vorteil behält 5.5: die optionale Aufbewahrung über 24 Stunden. Bei einem täglichen Batch-Job mit sehr großem Präfix kann das den Ausschlag in die andere Richtung geben. Der zweite Kostenhebel wirkt bei einer Migration allerdings gegenläufig: 5.6 nutzt standardmäßig Reasoning. Wird ein 5.5-Workload ohne explizites reasoning_effort migriert, entstehen beim gleichen Tarif neue Output-Kosten.

Der zweite Hebel: Reasoning Effort

Caching bestimmt die Input-Kosten. reasoning_effort steuert die Output-Seite, denn Reasoning-Token werden zum Output-Tarif abgerechnet und können im Gegensatz zum Präfix nie gecacht werden. GPT-5.6 akzeptiert auf allen Tiers Werte von none bis xhigh. Im Launch-Beitrag wird außerdem max für Sol genannt. Über Chat Completions ist dieser Wert jedoch nicht verfügbar (400: 'reasoning_effort' does not support 'max' with this model, sowohl bei Sol als auch bei Terra). Für den von Gateways und SDKs genutzten API-Pfad ist xhigh damit die praktische Obergrenze.

Wir haben eine Matrix mit 50 Aufrufen ausgeführt: vier Aufgabentypen - Bewertung klassifizieren, Feld aus einer Logzeile extrahieren, mehrstufige Textaufgabe zur Arithmetik und eine kleine Codegenerierung - über alle sechs Einstellungen von none bis xhigh, zusätzlich mit weggelassenem Parameter. Getestet wurde auf Terra und Luna sowie stichprobenartig auf Sol. Alle 50 Antworten waren bei jeder Einstellung korrekt. Unterschiede gab es nur bei der Abrechnung. Da diese Aufrufe wenig sichtbaren Output erzeugen, meist einige Dutzend Token, dominieren bereits wenige Dutzend Reasoning-Token zum Output-Tarif die Gesamtkosten. Die Verhältnis-Spalte vergleicht die Kosten des gesamten Aufrufs:

Daraus ergeben sich drei Befunde. Erstens passt 5.6 sein Reasoning selbst an: Bei den beiden einfachen Aufgaben verbrauchte keine Einstellung auch nur ein Reasoning-Token. Dort ist die Einstellung kostenneutral. Zweitens nutzt der Standardwert bei Aufgaben, die nach Reasoning aussehen, zusätzliche Token, selbst wenn sich das Ergebnis nicht verbessert. Bei den Mathematik- und Code-Aufgaben auf Luna sowie der Mathematik-Aufgabe auf Terra kostete das Weglassen des Parameters bei identisch korrekten Antworten 2,5- bis 3,5-mal so viel wie none. Beim Code-Test auf Terra wurden mit dem Standardwert zufällig keine Reasoning-Token verbraucht. Über die gesamte Terra- und Luna-Matrix lagen die Kosten ohne Parameter 1,5-mal so hoch. Drittens sind die Zwischenstufen - in der Tabelle nicht aufgeführt - eher Rauschen als eine verlässliche Skala: Bei der Mathematik-Aufgabe auf Terra wurden mit low 19 Reasoning-Token verbraucht, mit medium null, mit high 21 und mit xhigh wieder null. Beim Code-Test auf Luna waren es 101 bei xhigh, gegenüber 41 bei high. Die Bezeichnungen drücken eine Absicht aus, kein Budget. Dasselbe Verhalten haben wir bei GLM 5.2 gemessen.

Sendet reasoning_effort bei jedem Aufruf explizit und verwendet standardmäßig none für Klassifikation, Extraktion, Routing und kurze Transformationen. Erhöht den Wert nur für konkrete Call Sites, bei denen Evals eine Verbesserung der Ergebnisse nachweisen - nicht bloß, weil die Aufgabe schwierig wirkt. Unsere vier Aufgabentypen sind API-Workloads mit kurzem Output. Anspruchsvolle, mehrstufige Aufgaben können den zusätzlichen Reasoning-Aufwand rechtfertigen, aber diese Entscheidung sollte auf Messwerten beruhen.

Beide Hebel wirken zusammen. Sobald ein Präfix warm ist, kostet die Input-Seite eines Luna-Aufrufs nur noch ein Zehntel des Listenpreises. Bei kurzen Aufgaben wird das standardmäßige Reasoning dann zum größten verbleibenden Kostenpunkt: Die Mathematik-Aufgabe auf Luna kostete mit none insgesamt $0.00007, bei weggelassenem Parameter dagegen $0.00025. Allein das standardmäßige Reasoning addierte $0.00018 und war damit mehr als doppelt so teuer wie der gesamte explizit gesteuerte Aufruf. Wer nur das Caching optimiert, aber den Effort-Wert nicht festlegt, verliert einen Teil der Einsparung auf der Output-Seite wieder.

Empfehlungen nach Workload

Die Entscheidung lässt sich jetzt klar strukturieren. Gateway-Kunden empfehlen wir Folgendes:

Unabhängig vom Workload sollte pro Tenant oder Session ein stabiler prompt_cache_key gesendet werden. Laut Dokumentation ist dieser Schlüssel die Grundlage für zuverlässige Treffer. Jede markierte Schicht muss oberhalb der Untergrenze von 1.024 Token liegen. Überwacht außerdem cached_tokens, da Cache Misses unbemerkt auftreten können. Die Caches gelten pro Modell: Ein A/B-Test über verschiedene Tiers beginnt auf beiden Seiten mit einem kalten Cache. Setzt im selben Commit auch den zweiten Hebel: reasoning_effort gemäß der obigen Matrix explizit festlegen, standardmäßig auf none, solange Evals nichts anderes zeigen.

Bei der Wahl des Tiers verändert der Rabatt von 90 % die Rechnung stärker als der Tier selbst. Ein Workload, der ein Präfix mit 3.000 Token wiederholt, zahlt bei warmem Luna-Traffic ungefähr $0.30 pro tausend Aufrufe für dieses Präfix, bei warmem Sol-Traffic $1.50. Die Preisdifferenz zwischen den Tiers ist beim gecachten Anteil kleiner als bei den Output-Token. Wählt den Tier daher nach Output-Qualität und -Preis und nutzt Caching, um die Input-Seite zu reduzieren. Für Nutzer von gpt-5.5 ist Sol das direkte Upgrade mit identischer Preisliste, fünfmal günstigeren Cache-Lesevorgängen und Kontrolle darüber, wann sie stattfinden. Wechselt zu Terra oder Luna, wenn die Evals zeigen, dass der kleinere Tier ausreicht. Dadurch halbiert sich die Preisliste zusätzlich oder sinkt auf ein Fünftel.

Der Tokenizer ist unverändert

Unsere 24 Samples - ein narrativer Text in neun Sprachen, technische Texte und Nachrichtentexte in sechs dieser Sprachen, eine Python-Funktion und ein JSON-Tool-Call - ergaben bei jedem abgeschlossenen Vergleich identische Token-Zahlen für GPT-5.5, Sol, Terra und Luna. Auf 5.5 abgestimmte Token-Budgets und Schätzungen zur Cache-Untergrenze lassen sich unverändert übernehmen. Das sprachübergreifende Verhalten ist in unserem Beitrag zum Tokenizer nach Sprache beschrieben und gilt genauso für 5.6.

Fazit

• Der Cache-Rabatt steigt von 50 % auf 90 %, kombiniert mit einer garantierten TTL von mindestens 30 Minuten. Das ist die eigentliche Preissenkung dieses Releases. Die Tier-Preise stehen zwar im Vordergrund, aber die Caching-Konditionen haben größeren Einfluss auf reale Rechnungen.
• Verwendet explizite Breakpoints für gestaffelte Prompts. Die partielle Wiederverwendung ist gemessen, nicht nur theoretisch, und das Konzept lässt sich direkt von Claude übertragen.
• Beachtet die Untergrenze von 1.024 Token, sendet einen prompt_cache_key und überwacht cached_tokens. Sowohl unbemerkte Cache Misses als auch vollständig unterbliebene Cache-Schreibvorgänge kommen vor.
• Sendet reasoning_effort explizit und verwendet standardmäßig none: Der ungesteuerte Standardwert verursachte über unsere Matrix 1,5-mal so hohe Kosten, bei einzelnen Aufgaben bis zu 3,5-mal so hohe - trotz identischer Antworten.
• xhigh ist die erreichbare Obergrenze; max führt über Chat Completions zu einem 400-Fehler. Gegenüber 5.5 ist keine neue Tokenizer-Baseline nötig.

FAQ

Unterstützt GPT-5.6 explizites Prompt Caching wie Claude? Ja. Verwendet prompt_cache_options: {"mode": "explicit"} zusammen mit prompt_cache_breakpoint-Markern auf Content-Blöcken. Pro Request sind bis zu vier Schreibvorgänge möglich. Im Modus implicit bleiben drei, da der automatische Breakpoint einen Slot belegt. Bei der Messung über ein OpenAI-kompatibles Gateway wurde ein markiertes Präfix mit 3.012 Token beim ersten Aufruf geschrieben und beim zweiten vollständig zum Cache-Tarif gelesen.

Was kostet gecachter Input bei GPT-5.6? 10 % des Input-Tarifs, gemessen auf allen drei Tiers: $0.10 pro Million bei Luna, $0.25 bei Terra und $0.50 bei Sol. Bei GPT-5.x wurden gecachte Token mit 50 % des Input-Tarifs abgerechnet. Der Tarif für gecachte Token ist bei 5.6 damit fünfmal niedriger.

Ist das Caching von GPT-5.6 besser als bei GPT-5.5? Bei Rabatthöhe und Steuerbarkeit: ja. Der Cache-Tarif liegt bei 10 % statt 50 %. Es gibt vier explizite Breakpoints statt einer rein automatischen Erkennung, die sich weder gezielt auslösen noch debuggen lässt. Hinzu kommt eine garantierte Untergrenze von 30 Minuten mit Schlüssel statt 5 bis 10 Minuten nach Best Effort. Der verbleibende Vorteil von 5.5 ist die optionale Aufbewahrung über 24 Stunden, die bei 5.6 entfällt.

Wie lange bleibt der GPT-5.6-Cache erhalten? Die Dokumentation garantiert mindestens 30 Minuten. ttl: "30m" ist der einzige akzeptierte Wert; eine längere Aufbewahrung ist möglich. Die Option ersetzt das veraltete prompt_cache_retention, einschließlich der bisherigen 24-Stunden-Stufe. In unseren Messungen waren erneute Requests mit Schlüssel 15 Minuten nach dem Schreibvorgang vollständig gecacht. Die vollen 30 Minuten haben wir nicht geprüft.

Brauche ich prompt_cache_key? Sendet den Schlüssel. Laut Dokumentation ist ein stabiler Key pro Tenant oder Session die Grundlage für zuverlässige Treffer bei 5.6. Pro Key gilt ein Soft-Limit von ungefähr 15 Requests pro Minute. Das Mitsenden verursacht keine Kosten. Zusammen mit dem Monitoring von cached_tokens lässt sich damit prüfen, ob der Rabatt tatsächlich greift.

Wie stark beeinflusst reasoning_effort die Kosten von GPT-5.6? In unserer Matrix mit 50 Aufrufen - vier Aufgabentypen, sechs Einstellungen, Terra und Luna - lieferten alle Einstellungen korrekte Antworten. Ohne den Parameter lagen die Gesamtkosten 1,5-mal so hoch wie mit none, bei der Arithmetik-Aufgabe bis zu 3,5-mal so hoch. Bei einfachen Aufgaben wie Klassifikation und Extraktion verbrauchte keine Einstellung Reasoning-Token. Verwendet standardmäßig none und erhöht den Wert 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" liefern sowohl bei Sol als auch bei Terra einen 400-Fehler, der nur Werte von none bis xhigh auflistet.

Welchen GPT-5.6-Tier sollte ein API-Workload verwenden? Sol ist der preislich gleich positionierte Nachfolger von gpt-5.5: dieselbe Preisliste von $5/$30, aber fünfmal günstigere Cache-Lesevorgänge. Terra und Luna sind die kleineren Tiers zum halben beziehungsweise einem Fünftel dieses Preises. Sobald das Präfix stabil und mit einem Schlüssel versehen ist, reduziert der Cache-Rabatt von 90 % die Input-Seite stark. Wechselt daher so weit nach unten, wie es die Evals zur Output-Qualität zulassen, und lasst den Tier den Output-Preis bestimmen.

Weitere Leitfäden mit gemessenen Kosten aus dieser Reihe: Kosten für die Audiotranskription mit sieben ASR-Modellen, Kosten der Bilderzeugung und Preise für GPT Realtime Voice.

← Zurück zum Blog