The builder’s guide to GPT‑5.6
Technical lessons from startups in production
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:
- Reuse work already performed: by allowing reasoning to be persisted(s'ouvre dans une nouvelle fenêtre) across model turns and using native compaction(s'ouvre dans une nouvelle fenêtre) 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.
- Parallel decomposition where appropriate: using native multi-agent orchestration(s'ouvre dans une nouvelle fenêtre) allows coordinating multiple agents across parallel workstreams to finish complex tasks faster.
- Move deterministic work into code: using programmatic tool calling(s'ouvre dans une nouvelle fenêtre) 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.
Utilisés ensemble, ces éléments peuvent faire une différence spectaculaire. Par exemple, dans ARC-AGI-3, GPT‑5.6 Sol a obtenu 13,3 % avec le harnais standard. Après l’activation du raisonnement conservé et du compactage, le résultat a toutefois bondi à 38,3 %, avec environ six fois moins de tokens de sortie. Aucun changement au modèle, mais des performances presque triplées. Vous pouvez en savoir plus dans notre étude du harnais ARC-AGI-3.
Les flux de travail agentiques comportent souvent deux types de travail :
- Les tâches qui exigent du jugement
- Le travail qui consiste surtout à déplacer, filtrer et combiner des données
Lorsqu’un agent récupère 100 documents réglementaires, les filtre par date et repère les transactions pertinentes, le modèle ne devrait pas avoir à raisonner sur chaque résultat intermédiaire dans ses fenêtres contextuelles. L’appel programmatique d’outils permet à GPT‑5.6 d’écrire du JavaScript pour orchestrer les outils, exécuter en parallèle des appels indépendants et traiter leurs sorties en dehors des fenêtres contextuelles. Le modèle peut ainsi se concentrer sur ce qui exige de l’intelligence : exercer son jugement.
Pour les tâches complexes et parallélisables, répartir les actions et le raisonnement entre plusieurs flux de travail d’agents accélère l’exécution tout en augmentant l’intelligence. Dans ces configurations, l’agent principal est chargé d’orchestrer les sous-agents et de leur déléguer des tâches. Les sous-agents poursuivent leurs objectifs en parallèle, puis transmettent leurs résultats à l’agent principal pour la synthèse finale. Les équipes peuvent commencer à tirer parti du multi-agent de façon native en activant le mode multi-agent(s'ouvre dans une nouvelle fenêtre) dans l’API Responses. C’est aussi ainsi que fonctionne le réglage de capacité Ultra dans ChatGPT.
“Qualia déploie des équipes d’agents sur des problèmes de recherche ouverts, et GPT‑5.6 Sol a simplement fait mouche. Il a montré une nette amélioration par rapport à GPT‑5.5, a terminé plus vite que presque tous les autres modèles testés et est rapidement devenu notre modèle OpenAI de prédilection.”
“GPT‑5.6 est le meilleur orchestrateur que nous ayons vu chez OpenAI. Nous lui avons soumis six spécifications à la fois — pour les rédiger, les créer et en discuter — et il a tout suivi sans compromettre la qualité.”
Même si GPT‑5.6 évalue bien le nombre approprié de sous-agents et le moment de les créer, son comportement multi-agent est très facile à orienter. Indiquer au modèle quand faire appel aux sous-agents peut augmenter la probabilité qu’il ne crée des agents que lorsque la dépense supplémentaire en tokens produira de meilleures performances.
Dans toute la famille de modèles, la durée de vie du cache d’invites a été portée à au moins 30 minutes, et les points d’arrêt du cache peuvent maintenant être définis de façon déterministe dans les fenêtres contextuelles d’un modèle. Les jeunes pousses ont ainsi pu améliorer considérablement leur taux de succès du cache.
En plus de définir des points d’arrêt du cache, continuer d’utiliser une prompt_cache_key(s'ouvre dans une nouvelle fenêtre) appropriée augmente la probabilité que les requêtes soient acheminées vers le même moteur d’inférence que celui ayant déjà traité le même préfixe, ce qui réduit la latence.
Ce qui ressort de ces exemples, c’est à quel point l’économie de la création d’agents a changé.
Les cas d’utilisation qui exigeaient autrefois un modèle de pointe à chaque étape peuvent maintenant obtenir des résultats comparables ou supérieurs à une fraction du coût, grâce à de plus petits modèles, à l’ajustement de l’effort de raisonnement et à des choix architecturaux efficaces.
Nous avons hâte de voir ce que vous allez créer!
- 2026
- Plateforme API
À propos des auteurs
Ce guide a été élaboré par Samarth Madduru(s'ouvre dans une nouvelle fenêtre), Prashant Mital(s'ouvre dans une nouvelle fenêtre), Dave Leo(s'ouvre dans une nouvelle fenêtre) et Julien Reiman(s'ouvre dans une nouvelle fenêtre), à partir de leur expérience de collaboration étroite avec des jeunes pousses développant sur GPT‑5.6, des premiers essais jusqu’à la production.


