GPT-5.6 Prompting Guide: Defaults kosten 1,5x und 10x mehr

Für gutes Prompting mit GPT-5.6 kommt es vor allem auf zwei Request-Parameter an. Beide verwenden standardmäßig die teurere Einstellung. In unserer Matrix mit 50 Calls kosteten Requests ohne reasoning_effort 1,5-mal so viel wie mit dem expliziten Wert "none", obwohl die Antworten identisch waren. Ein nicht markiertes, stabiles Präfix wird bei jedem Call zum Zehnfachen des Cache-Read-Tarifs abgerechnet. Aus den Messungen in unserem Kostenleitfaden zu GPT-5.6 ergibt sich dieses Playbook für die Request-Struktur: wie ein sauber aufgebauter Request aussieht, wie der Effort je nach Aufgabe eingestellt wird, wie der Prompt aufgebaut sein muss, damit der Cache greift, und was bei der Migration von GPT-5.5-Prompts nicht mehr funktioniert.

TL;DR

• Setze reasoning_effort bei jedem GPT-5.6-Request explizit. In unserer Matrix mit 4 Aufgaben kostete das Weglassen 1,5-mal so viel wie "none", bei identischen Antworten.
• Zulässig sind die Effort-Stufen von none bis xhigh. "max" führt bei Sol und Terra zu einem 400-Fehler.
• Markiere stabile Präfixe mit expliziten Cache-Breakpoints. Reads werden mit 10% des Input-Tarifs abgerechnet, Writes mit dem 1,25-Fachen. Markiere daher nur Inhalte, die tatsächlich wiederverwendet werden, nicht alles, was lediglich stabil aussieht.
• prompt_cache_options und Breakpoints führen bei GPT-5.5 und älteren Modellen zu einem 400-Fehler. Der Rollout braucht daher ein Versions-Gating.

Wie sollte ein GPT-5.6-Request aufgebaut sein?

Nimm diese Struktur als Ausgangspunkt und entferne alles, was du nicht brauchst. Die beiden entscheidenden Stellschrauben sind explizit gesetzt, statt die teuren Defaults zu übernehmen:

{
  "model": "gpt-5.6-terra",
  "reasoning_effort": "low",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    { "role": "system", "content": "…stable instructions…",
      "prompt_cache_breakpoint": { "mode": "explicit" } },
    { "role": "user", "content": "…the part that changes per request…" }
  ]
}

Für die Reihenfolge gilt: Alles Stabile steht vor dem Breakpoint, alles Request-spezifische dahinter. Dynamische Inhalte wie Zeitstempel, Benutzernamen oder bei jedem Call wechselnde abgerufene Dokumente gehören nie in den markierten Block. Ändert sich auch nur ein Byte, wird der gesamte Block erneut mit dem 1,25-fachen Write-Aufschlag abgerechnet. Der prompt_cache_key sorgt dafür, dass wiederholte Requests denselben Cache erreichen. Verwende pro Tenant oder Session einen stabilen Key und beachte das dokumentierte Soft Limit von etwa 15 Requests pro Minute und Key.

Wie sollte reasoning_effort eingestellt werden?

Immer explizit. Die einzige Einstellung, die du vermeiden solltest, ist gar keine. In unseren Messungen kosteten Requests ohne reasoning_effort 1,5-mal so viel wie Requests mit "none". Die Antworten waren in der gesamten Matrix identisch. Zulässig sind none, low, medium, high und xhigh. "max" wird mit einem 400-Fehler abgelehnt, der die gültigen Werte auflistet. Bei unserem einzeiligen Mathematiktest mit Luna brachte die jeweilige Stufe Folgendes:

In unserer Untersuchung zur Aufschlüsselung des Token-Verbrauchs war GPT-5.6 die einzige Modellfamilie, die diesen Test auch bei vollständig deaktiviertem Reasoning korrekt löste. Damit ist none ein gut vertretbarer Default für Extraktion, Klassifizierung, Formatierung und Retrieval-orientierte Calls. Wenn das Modell Reasoning verwendet, sind diese Token nicht sichtbar und werden zum vollen Output-Tarif abgerechnet. Beim Mathematikbeispiel mit Default-Einstellung entfielen 88% der Output-Kosten auf eine Gedankenkette, die nicht einsehbar ist. Erhöhe die Stufe nur, wenn deine Evals zeigen, dass die Aufgabe sie braucht, nicht weil der Default die zusätzlichen Token ohnehin verbraucht.

Wie muss ein Prompt aufgebaut sein, damit sich der Cache lohnt?

Ordne den Prompt nach Stabilität und markiere die einzelnen Schichten: zuerst die Systemanweisungen, dann die Tool-Definitionen und anschließend die Referenzdokumente. Jede Schicht endet an einem Breakpoint. Der variable User-Turn folgt nach der letzten Markierung. Pro Request sind vier Cache Writes möglich. Im standardmäßigen impliziten Modus verbraucht ein automatischer Breakpoint an der neuesten Message bereits einen davon. Der explizite Modus stellt alle vier zur Verfügung und sorgt vor allem dafür, dass nur markierte Inhalte gecacht werden.

Der entscheidende Vorteil ist die partielle Wiederverwendung, und sie lässt sich messen. Bei einem stabilen Block A und einem ausgetauschten Ende B wurde nur dieses Ende neu berechnet: Von einem Prompt mit 2.431 Token wurden 1.212 zum Cache-Tarif gelesen und 1.210 neu mit dem Write-Aufschlag geschrieben. Die Abrechnung stimmte bis auf die letzte Stelle mit der Preisliste überein. Daraus folgen drei Regeln für die Budgetplanung:

• Reads kosten 10% des Input-Tarifs. Ein aufgewärmtes, geschichtetes Präfix senkt damit die Input-Seite der Rechnung.
• Writes kosten das 1,25-Fache. Wird ein markierter Block nie wieder gelesen, kostet das Caching 25% mehr als ein Request ohne Cache. Markiere nur Inhalte, die wiederverwendet werden, nicht alles, was stabil aussieht.
• Bei vollständigen Wiederholungen kann die erkannte Länge vor der Markierung enden. In einem Test wurden von einem Write mit 2.422 Token nur 1.897 aus dem Cache gelesen. Plane daher mit dem rabattierten Tarif, nicht mit exakten Trefferzahlen. Unsere Untersuchung zu Cache-Mindestgrößen enthält die Untergrenzen je Modellfamilie.

Die Untergrenze ttl: "30m" ist eine garantierte Mindestdauer, keine Obergrenze. Sie ist sechsmal so lang wie Claudes Default von 5 Minuten. Eine 24-Stunden-Stufe gibt es nicht mehr. Daily-Batch-Workloads, die auf die längere Aufbewahrungsdauer gesetzt haben, sollten daher den Break-even neu berechnen.

Was funktioniert bei der Migration von GPT-5.5-Prompts nicht mehr?

Zwei Probleme sind sofort sichtbar, eines bleibt unauffällig. Sichtbar: prompt_cache_options und prompt_cache_breakpoint führen bei GPT-5.5 und älteren Modellen zu einem klaren 400-Fehler (prompt_cache_options is not supported on this model). Jeder gemeinsam genutzte Prompt Builder benötigt deshalb ein Versions-Gating. Ebenfalls sichtbar: Die in manchen 5.5-Konfigurationen verwendete Effort-Stufe "max" wird abgelehnt.

Unauffällig, aber teurer: GPT-5.6 verwendet standardmäßig Reasoning, während es bei einem GPT-5.5-Workload möglicherweise deaktiviert war. Ein migrierter Prompt, der reasoning_effort nicht setzt, zahlt bei derselben Preisliste den 1,5-fachen Aufschlag für das Weglassen. Beim Cache verläuft die Migration umgekehrt: Die automatische Präfixerkennung von 5.5 brauchte keine Markierungen, ließ sich aber weder gezielt auslösen noch debuggen. Bei 5.6 bewirkt derselbe Prompt nichts, bis du ihn markierst. Danach wird jeder Write in usage.prompt_tokens_details.cache_write_tokens ausgewiesen. Ein Miss erscheint dann als Null in einem von dir erzeugten Feld, statt überhaupt nicht gemeldet zu werden.

Welche Modellstufe sollte den Prompt ausführen?

Dieselbe Request-Struktur funktioniert auf allen drei Stufen. Die Wahl der Stufe ist daher eine Preisfrage und keine Frage des Promptings: Sol kostet $5/$30 pro Million Token, Terra die Hälfte und Luna ein Fünftel. Sobald das Präfix stabil, per Key zugeordnet und aufgewärmt ist, reduziert der Cache-Read-Rabatt die Input-Kosten auf jeder Stufe. Damit wird der Output-Preis zum entscheidenden Unterschied. Wechsle so weit nach unten, wie es die Evals zur Output-Qualität erlauben. Die vollständige Berechnung für alle Stufen, einschließlich des Break-even für den Write-Aufschlag, steht im Kostenleitfaden.

FAQ

Unterstützt GPT-5.6 reasoning_effort: “max”?

Nein. Requests mit "max" führen bei Sol und Terra zu einem 400-Fehler, der none bis xhigh als gültige Werte auflistet. Workloads, die die höchste Stufe benötigen, sollten explizit xhigh senden.

Funktionieren die Cache-Breakpoints mit GPT-5.5?

Nein. GPT-5.5 und ältere Modelle lehnen prompt_cache_options und Breakpoint-Markierungen mit einem 400-Fehler ab. Bei diesen Modellen bleibt nur die automatische Präfixerkennung. Sie lässt sich weder gezielt auslösen noch über einen Key steuern oder debuggen. Behandle das Cache-Verhalten dort als Best Effort und versieh jeden Prompt Builder, der die neuen Felder ausgibt, mit einem Versions-Gating.

Wie viele Breakpoints sollte ein Prompt tatsächlich verwenden?

So viele Schichten, wie tatsächlich wiederverwendet werden, bis zum verfügbaren Limit: vier Writes pro Request. Im impliziten Modus belegt der automatische Breakpoint einen davon. Im expliziten Modus stehen alle vier zur Verfügung. Ein typischer geschichteter Prompt benötigt zwei oder drei Breakpoints für Anweisungen, Tools und Referenzblock. Eine fünfte Markierung wird ohne Fehler akzeptiert, teilt sich aber lediglich die Write-Slots mit den anderen, da eine spätere Markierung alle vorherigen Inhalte einschließt.

Alle Zahlen in diesem Leitfaden wurden am ersten Tag der GPT-5.6-Modelle über das Synthorai-Gateway gemessen und mit dem Live-Zähler unter usage.cost abgeglichen. Methodik und Rohmessungen stehen im Kostenleitfaden und in der Untersuchung zu Cache-Mindestgrößen. Prüfe die Werte anhand deiner eigenen Nutzungsdaten. Preise und zulässige Werte können sich ändern.

← Zurück zum Blog