GPT-5.6 Prompting-Leitfaden: Zwei Defaults, die 1,5x und 10x mehr kosten

Gutes Prompting mit GPT-5.6 läuft im Wesentlichen auf zwei Request-Parameter hinaus, und beide stehen per Default auf der teuren Einstellung. In unserer Matrix mit 50 Aufrufen kostete das Weglassen von reasoning_effort das 1,5-fache gegenüber "none" bei identischen Antworten; einen stabilen Prefix nicht zu markieren, kostet bei jedem Aufruf das 10-fache des Cache-Lesepreises. Dieser Leitfaden ist das Request-Shape-Playbook, das sich direkt aus den Messungen in unserem GPT-5.6-Kostenleitfaden ergibt: Wie ein sauber geformter Request aussieht, wie man den Effort-Regler pro Aufgabe einstellt, wie man einen Prompt aufbaut, damit der Cache greift, und was kaputtgeht, wenn man Prompts von GPT-5.5 übernimmt.

TL;DR

• Setze reasoning_effort bei jedem GPT-5.6-Request explizit: Weglassen kostete in unserer 4-Aufgaben-Matrix das 1,5-fache von "none" bei identischen Antworten.
• Zulässige Effort-Werte reichen von none bis xhigh; "max" liefert auf Sol wie auf Terra einen 400.
• Markiere stabile Prefixe mit expliziten Cache-Breakpoints: Cache-Lesevorgänge kosten 10 % des Input-Preises, Schreibvorgänge 1,25x. Markiere also das, was sich wiederholt, nicht das, was nur stabil aussieht.
• prompt_cache_options und Breakpoints liefern bei GPT-5.5 und älter einen 400; sichere das Rollout per Versions-Gate ab.

Wie sollte ein GPT-5.6-Request aussehen?

Nimm dieses Grundgerüst und lösche, was du nicht brauchst. Es setzt die beiden Hebel explizit, statt die teuren Defaults zu erben:

{
  "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…" }
  ]
}

Die Regel dahinter für die Reihenfolge: Alles Stabile steht vor dem Breakpoint, alles Request-Spezifische danach. Alles Dynamische (Timestamps, User-Namen, pro Aufruf unterschiedliche abgerufene Dokumente) darf niemals im markierten Block liegen, denn ein einziges geändertes Byte verrechnet den Block erneut mit dem 1,25x-Schreibaufschlag. Der prompt_cache_key leitet Wiederholungen auf denselben Cache; verwende einen stabilen Key pro Tenant oder Session, und beachte das dokumentierte Soft-Limit von etwa 15 Requests pro Minute je Key.

Wie sollte man reasoning_effort setzen?

Immer explizit. Die einzige Einstellung, die man vermeiden sollte, ist keine Einstellung. In unseren Messungen kosteten Requests ohne reasoning_effort das 1,5-Fache von Requests, die auf "none" festgelegt waren – bei über die gesamte Matrix identischen Antworten. Erlaubt sind die Werte none, low, medium, high, xhigh; "max" wird mit einem 400 abgelehnt, der den gültigen Bereich auflistet. Was der Regler bei unserem einzeiligen Mathe-Test brachte, auf Luna:

GPT-5.6 war in unserer Studie zur Anatomie der Token-Nutzung die einzige Familie, die bei diesem Test auch mit komplett abgeschaltetem Thinking korrekt blieb. Damit ist none ein vertretbarer Default für Extraktion, Klassifizierung, Formatierung und Retrieval-artige Calls. Wenn das Modell doch reasoniert, sind die Tokens unsichtbar und werden zum vollen Output-Tarif abgerechnet: 88 % der Output-Kosten im Mathe-Beispiel mit Default-Einstellung waren nicht lesbare Chain-of-Thought. Dreh den Regler hoch, wenn deine Evals sagen, dass die Aufgabe es braucht – nicht weil der Default es ohnehin schon ausgegeben hat.

Wie baut man einen Prompt auf, damit sich der Cache lohnt?

Schichte den Prompt nach Stabilität und markiere die Schichten: zuerst die System-Instructions, dann die Tool-Definitionen, dann die Referenzdokumente, jede endet an einem Breakpoint, und der volatile User-Turn kommt nach der letzten Markierung. Du hast vier Cache-Writes pro Request; im impliziten Default-Modus verbraucht ein automatischer Breakpoint auf der letzten Nachricht einen davon. Der explizite Modus gibt dir also alle vier und cacht vor allem nur das, was du markierst.

Die Teilwiederverwendung ist der Gewinn, und sie ist messbar. Mit einem stabilen Block A und einem ausgetauschten Ende B rechnete der Zähler nur das Ende neu ab: 1.212 Tokens zum Cache-Tarif zurückgelesen, 1.210 frisch zum Aufschlag geschrieben, aus einem Prompt mit 2.431 Tokens – auf die Stelle genau mit dem Tarif abgeglichen. Daraus folgen drei Budget-Regeln:

• Reads kosten 10 % des Input-Tarifs, ein warmer geschichteter Prefix drückt also die Input-Seite der Rechnung.
• Writes kosten das 1,25-Fache, ein markierter Block, der nie wieder gelesen wird, kostet also 25 % mehr, als hätte man ihn nicht gecacht. Markiere, was sich wiederholt, nicht alles, was stabil aussieht.
• Bei vollständigen Wiederholungen kann die gematchte Länge unter die Markierung rutschen (1.897 gecacht bei einem Write von 2.422 Tokens in einer Messung), also budgetiere über den Rabatt-Tarif, nicht über exakte Match-Zahlen; unsere Studie zu Cache-Mindestwerten enthält die Untergrenzen pro Familie.

Die ttl: "30m"-Untergrenze ist ein garantiertes Minimum, keine Obergrenze, und liegt beim 6-Fachen von Claudes Default von 5 Minuten; einen 24-Stunden-Tier gibt es nicht mehr, wer für Daily-Batch-Workloads auf die verlängerte Aufbewahrung gesetzt hat, sollte den Break-even neu rechnen.

Was bricht, wenn man Prompts von GPT-5.5 portiert?

Zwei Dinge brechen laut und eines still. Laut: prompt_cache_options und prompt_cache_breakpoint liefern bei GPT-5.5 und älter einen sauberen 400 (prompt_cache_options is not supported on this model), jeder gemeinsam genutzte Prompt-Builder braucht also ein Version-Gate. Ebenfalls laut: "max"-Effort, den manche 5.5-Configs mitschleppten, wird abgelehnt.

Still, und teurer: GPT-5.6 reasoniert per Default, wo ein 5.5-Workload das Reasoning vielleicht aus hatte. Ein portierter Prompt, der reasoning_effort nie setzt, fängt sich beim gleichen Tarif die 1,5-fache Auslassungssteuer ein. Die Cache-Migration läuft andersherum: Die automatische Prefix-Erkennung von 5.5 brauchte kein Markup, ließ sich aber weder auslösen noch debuggen; auf 5.6 tut derselbe Prompt gar nichts, bis du ihn markierst, und meldet dann jeden Write in usage.prompt_tokens_details.cache_write_tokens, wo ein Miss als Null in einem selbst angelegten Feld auftaucht statt als Stille.

Auf welchem Tier sollte der Prompt laufen?

Dieselbe Request-Form läuft auf allen drei Tiers, die Tier-Wahl ist also eine Preisfrage und keine Prompting-Frage: Sol zu $5/$30 pro Million Token, Terra zur Hälfte, Luna zu einem Fünftel. Sobald der Präfix stabil, gekeyt und warm ist, drückt der Cache-Read-Rabatt die Input-Seite auf jedem Tier flach, und damit wird der Output-Preis zum entscheidenden Faktor. Geh so weit runter, wie es die Output-Quality-Evals zulassen. Die vollständige Tier-Rechnung inklusive des Break-even für den Write-Aufschlag pro Tier steht im Cost Guide.

FAQ

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

Nein. Requests mit "max" liefern einen 400 zurück, der none bis xhigh als gültige Werte auflistet – auf Sol wie auf Terra. Workloads, die das Maximum wollen, sollten xhigh explizit senden.

Funktionieren die Cache-Breakpoints auf GPT-5.5?

Nein. GPT-5.5 und älter lehnen prompt_cache_options und Breakpoint-Marker mit einem 400 ab. Auf diesen Modellen bist du auf die automatische Präfix-Erkennung zurückgeworfen, die sich nicht triggern, keyen oder debuggen lässt. Behandle das Cache-Verhalten dort als Best-effort und schalte jeden Prompt-Builder, der die neuen Felder ausgibt, per Version-Gate frei.

Wie viele Breakpoints sollte ein Prompt tatsächlich nutzen?

So viele Layer, wie sich wirklich wiederholen, bis zum Budget: vier Writes pro Request, von denen einer vom impliziten Auto-Breakpoint verbraucht wird, sofern du nicht in den expliziten Modus wechselst. Ein typischer geschichteter Prompt braucht zwei oder drei (Instructions, Tools, Reference-Block). Ein fünfter Marker wird ohne Fehler akzeptiert, teilt sich aber einfach die Write-Slots, da ein späterer Marker alles davor abdeckt.

Alle Zahlen in diesem Guide wurden über das Synthorai-Gateway an den Day-one-Modellen von GPT-5.6 gemessen und stimmen mit dem Live-Meter usage.cost überein; Methodik und Rohdaten stehen im Cost Guide und in der Studie zu den Cache-Minima. Prüf gegen deine eigenen Usage-Daten; Raten und akzeptierte Werte können sich ändern.

← Zurück zum Blog