The builder’s guide to GPT‑5.6

The GPT‑5.6 model family makes frontier-level agent performance dramatically more affordable, while also advancing the frontier of what is possible.

In this guide, we show how startups are using smarter model selection and new API controls that help with reasoning continuity, multi-agent orchestration, and programmatic tool calling to build faster, more capable agents at a fraction of the cost.

Since GPT‑5, each model generation has sought to tackle longer-horizon tasks with fewer tokens. GPT‑5.6 continues that trajectory: stronger agent performance, lower costs, with minimal changes to the underlying harness.

The improvements in top-line cost efficiency are compounded with increased accuracy at lower reasoning efforts. For example, on Agents’ Last Exam, GPT‑5.6 Sol at “low” reasoning outperformed GPT‑5.5 at “high” reasoning when the harness was kept constant. We’ve seen similar success stories in production testing where startups report seeing significant cost improvements across a range of workflows by reducing the reasoning effort from the prior defaults.

Historically, upgrading to a flagship model at the highest reasoning available has been the best option for long-horizon use cases. This has been in large part due to these models being significantly more capable than cost-optimized models at handling longer contexts and tool calling. This has changed with the 5.6-family: with more test-time compute, Luna and Terra can often perform similar to GPT‑5.4 and 5.5 while being significantly cheaper.

Consider tasks in BrowseComp: a search-based benchmark that tests a model’s ability to search for obscure facts. Three months ago, GPT‑5.5 (Extra High) scored 84.36% on this benchmark for a total cost of $33.27. At launch, GPT‑5.6 Luna (Extra High) delivers essentially the same performance, scoring 84.04% at a cost of $1.33. We’ve since reduced prices further. Read more on our latest price cuts.

The smaller 5.6-family models are a strong fit for high-volume workloads, latency-sensitive interactions, and repeated steps within agentic workflows. For example, if you’re operating a legal-tech startup that parses handwritten memos prior to agentic analysis, instead of using a frontier model for the entire use case, you can now use Terra or Luna for extraction and register significant cost savings.

In addition to making GPT‑5.6 more performant out of the box, we also shipped new primitives to the Responses API to unlock further gains. We trained GPT‑5.6 end-to-end with three complementary architectural interventions that enable agents to operate more efficiently:

1. Reuse work already performed: by allowing reasoning to be persisted⁠(wird in einem neuen Fenster geöffnet) across model turns and using native compaction⁠(wird in einem neuen Fenster geöffnet) to compress long-running conversations, the model can maintain coherence in its work across longer task horizons without getting confused or having to reconstruct prior context.
2. Parallel decomposition where appropriate: using native multi-agent orchestration⁠(wird in einem neuen Fenster geöffnet) allows coordinating multiple agents across parallel workstreams to finish complex tasks faster.
3. Move deterministic work into code: using programmatic tool calling⁠(wird in einem neuen Fenster geöffnet) to filter, aggregate, and orchestrate tool outputs outside the model’s context window, reserving model tokens for judgment and reducing cost, latency, and context rot.

Zusammen eingesetzt können diese Funktionen einen enormen Unterschied bewirken. Bei ARC-AGI-3 erzielte GPT‑5.6 Sol mit dem Standard-Harness beispielsweise 13,3 %. Nachdem beibehaltenes Reasoning und Kontextverdichtung aktiviert worden waren, stieg der Wert auf 38,3 %, bei rund sechsmal weniger Ausgabe-Token. Keine Änderungen am Modell, aber fast die dreifache Leistung. Mehr dazu erfährst du in unserer Untersuchung des ARC-AGI-3-Harness.

Agenten-Workflows umfassen häufig zwei Arten von Arbeit:

1. Aufgaben, die Urteilsvermögen erfordern
2. Arbeit, bei der Daten vor allem verschoben, gefiltert und kombiniert werden

Wenn ein Agent 100 Unterlagen abruft, nach Datum filtert und relevante Transaktionen ermittelt, sollte das Modell nicht jedes Zwischenergebnis in seinem Kontextfenster analysieren müssen. Mit programmatischen Tool-Aufrufen kann GPT‑5.6 JavaScript schreiben, um Tools zu orchestrieren, unabhängige Aufrufe parallel auszuführen und deren Ergebnisse außerhalb des Kontextfensters zu verarbeiten. So kann sich das Modell auf das konzentrieren, was Intelligenz erfordert: Sachverhalte zu beurteilen.

Bei komplexen, parallelisierbaren Aufgaben lassen sich Aktionen und Reasoning auf mehrere Arbeitsabläufe von Agenten verteilen. Dadurch werden Aufgaben schneller und mit höherer Intelligenz erledigt. In solchen Konfigurationen orchestriert der primäre Agent die untergeordneten Agenten und delegiert Aufgaben an sie. Die untergeordneten Agenten verfolgen ihre Ziele parallel und übermitteln ihre Ergebnisse schließlich zur abschließenden Zusammenführung an den primären Agenten. Teams können native Multi-Agenten-Funktionen nutzen, indem sie in der Responses API Multi-Agenten aktivieren⁠(wird in einem neuen Fenster geöffnet). So funktioniert auch die Fähigkeitseinstellung Ultra in ChatGPT.

GPT‑5.6 erkennt zwar zuverlässig, wie viele untergeordnete Agenten angemessen sind und wann sie eingesetzt werden sollten, doch das Multi-Agenten-Verhalten lässt sich sehr gezielt steuern. Anweisungen dazu, wann das Modell untergeordnete Agenten aufrufen soll, erhöhen die Wahrscheinlichkeit, dass es Agenten nur dann einsetzt, wenn der zusätzliche Token-Verbrauch die Leistung verbessern würde.

Für die gesamte Modellfamilie wurde die Gültigkeitsdauer des Prompt-Caches auf mindestens 30 Minuten verlängert. Zudem lassen sich Cache-Haltepunkte nun deterministisch im Kontextfenster eines Modells festlegen. Dadurch konnten Start-ups ihre Cache-Trefferquote deutlich erhöhen.

Zusätzlich zum Festlegen von Cache-Haltepunkten erhöht die weitere Verwendung eines geeigneten prompt_cache_key⁠(wird in einem neuen Fenster geöffnet) die Wahrscheinlichkeit, dass Anfragen dieselbe Inferenz-Engine erreichen, die zuvor dasselbe Präfix verarbeitet hat. Das verringert die Latenz.

Diese Beispiele zeigen vor allem, wie stark sich die wirtschaftlichen Rahmenbedingungen für die Entwicklung von Agenten verändert haben.

Anwendungsfälle, die früher bei jedem Schritt ein Frontier-Modell erforderten, können heute zu einem Bruchteil der Kosten vergleichbare oder bessere Ergebnisse erzielen. Dafür werden kleinere Modelle eingesetzt, der Reasoning-Aufwand angepasst und effiziente Architekturentscheidungen getroffen.

Wir sind gespannt, was ihr entwickelt!