Terminal-Bench et Coding Agent Index : pourquoi GPT-5.6 prend l'avantage sur les agents de coding en production
En production, un agent de coding ne se juge pas à un score académique, mais à sa capacité à terminer le travail : en un minimum d'étapes, d'appels d'outils et de tokens. C'est sur ce terrain, celui de Terminal-Bench 2.1 et du Coding Agent Index, que GPT-5.6 prend l'avantage sur Claude. Voici pourquoi, et où passe la limite : l'avantage est réel mais loin d'être total.
Analyse d'ingénieurs SFEIR, partenaire Anthropic et Google Cloud. Le parti pris de cet article est technique et opérationnel : nous ne cherchons pas à couronner un modèle, mais à identifier quel benchmark regarder quand on met des agents au travail dans une CI/CD, et comment lire ses chiffres sans se faire piéger.
Le problème : vos agents coûtent cher parce qu'ils tâtonnent
La plupart des équipes qui mettent des agents de coding en production font le même constat au bout de quelques semaines : la facture ne vient pas de là où on l'attendait. Les agents consomment trop de tokens, multiplient les appels d'outils, et se bloquent sur les tâches longues, les fameux stuck runs. Le prix par token ne dit rien du coût réel par tâche résolue : un modèle « pas cher » qui fait dix allers-retours d'outils là où un autre en fait trois peut coûter davantage, et livrer plus lentement.
C'est un point que nous martelons dans notre analyse de l'illusion du prix par token : la dépense d'un cycle agentique suit l'ingestion, pas la génération. Le bon indicateur n'est donc pas le tarif affiché, mais le nombre d'étapes, de tokens de sortie et de reprises qu'il faut pour arriver au bout. Et c'est exactement ce que mesurent (imparfaitement, mais mieux que les autres) les deux benchmarks agentiques que nous allons examiner.
Terminal-Bench 2.1 : le benchmark le plus proche du réel
Terminal-Bench mesure la capacité à mener des tâches d'ingénierie en ligne de commande : planification, itération, coordination d'outils, récupération après erreur. C'est le test que les équipes DevOps et plateforme devraient regarder en priorité, parce qu'il ressemble à ce qu'un agent fait vraiment dans un pipeline : ouvrir un terminal, lancer des commandes, lire des sorties, corriger, recommencer.
| Modèle | Terminal-Bench 2.1 (scores officiels OpenAI) |
|---|---|
| GPT-5.6 Sol Ultra | 91,9 % |
| GPT-5.6 Sol | 88,8 % |
| Claude Mythos 5 | 88 % |
| GPT-5.6 Terra | 87,4 % |
| GPT-5.5 | 85,6 % |
| GPT-5.6 Luna | 84,7 % |
| Claude Fable 5 | 83,1 % |
| Claude Opus 4.8 | 78,9 % |
Deux enseignements plus intéressants que le classement lui-même. D'abord, Terra (87,4 %) est étonnamment proche de Sol (88,8 %) : pour beaucoup de tâches CI/CD, Terra mérite d'être le modèle par défaut, à moitié prix du flagship. Ensuite, Luna (84,7 %) dépasse ici la génération précédente, ce qui en fait un cheval de trait redoutable pour la première passe, à un cinquième du prix de Sol. Autrement dit, ce tableau ne dit pas « prenez Sol » : il dit « vous pouvez router intelligemment sans presque rien sacrifier ».
Une réserve de méthode, à garder en tête : ces scores sont auto-reportés par OpenAI. Attention aux sources secondaires qui citent Terra à 82,5 % ou 84,3 % : ce sont des chiffres pré-lancement erronés ; la table officielle donne 87,4 %. De même, le score de Fable 5 varie selon les mesures (83,1 % dans la table OpenAI, jusqu'à 84,6 % chez Artificial Analysis en harness uniforme). Un benchmark reste un point de repère, pas un verdict.
Coding Agent Index : le vrai juge, c'est le coût par tâche
L'Artificial Analysis Coding Agent Index associe le modèle à un harness agentique et combine DeepSWE, Terminal-Bench v2 et SWE-Atlas-QnA. Sol (en mode max, dans le harness Codex) mène à 80, contre 77,4 pour Terra, 77,2 pour Fable 5 et 74,6 pour Luna2.
Mais l'intérêt de cet index n'est pas le score : c'est le coût. Selon Artificial Analysis, Sol coûte environ 40 % de moins par tâche que Fable 5 (dans Claude Code) et environ 10 % de moins qu'Opus 4.8, en utilisant moins de la moitié des tokens de sortie. OpenAI, de son côté, formule l'avantage à « environ un tiers moins cher ». Retenez l'ordre de grandeur : performance de tête, à un tiers à 40 % de moins. C'est là que se joue la vraie bataille en production : pas dans le dernier point de pourcentage, mais dans le rapport résultat/facture.
Attention toutefois : cet index a été produit avec le soutien d'OpenAI en pré-lancement, et les comparaisons Sol/Fable 5 utilisent parfois des harnesses différents (Codex pour Sol, Claude Code pour Fable). Ce n'est pas strictement « apples-to-apples ». Comme nous l'expliquons dans la critique des benchmarks frontier, la performance réelle vient de l'attelage modèle + harnais : un même modèle change de score selon le harnais qui l'entoure. Le chiffre est un indice, pas une preuve.
Le mode ultra et les sous-agents : puissance, mais facture
Le mode ultra (réservé à Sol) ne fait pas tourner une seule chaîne de raisonnement : il décompose la tâche et lance des sous-agents en parallèle (quatre par défaut, entraînés à coopérer et à communiquer pendant la tâche) avant de fusionner les résultats. C'est ce qui fait passer Terminal-Bench de 88,8 % à 91,9 %.
Le revers est mécanique : chaque sous-agent consomme ses propres tokens. En estimation d'API, un run Sol standard sur Terminal-Bench coûte de l'ordre de 1,70 $, contre un peu plus de 5 $ en ultra. Ce facteur trois n'est justifié que sur des tâches vraiment dures et décomposables. La règle d'ingénierie est simple : ne l'activez jamais par défaut dans une boucle d'agent, sinon votre facture le remarquera avant vous. Le parallélisme d'agents est un multiplicateur de coût qui ne se déclenche qu'à bon escient, un principe que nous détaillons dans le guide du routing multi-modèles.
Les retours terrain confirment : moins d'étapes, moins de tokens
Au-delà des benchmarks, les plateformes qui ont intégré GPT-5.6 rapportent des gains cohérents sur ce qui compte en production :
- Un éditeur d'outils de développement rapporte « environ 25 % d'étapes en moins et 35 à 48 % d'appels d'outils en moins » que la génération précédente, avec une amélioration du taux de réussite et une baisse d'environ 15 % des stuck runs.
- Un service de review de pull requests indique avoir battu la génération précédente sur le F1 « en utilisant environ trois fois moins de tokens par PR et avec une latence médiane environ deux fois plus basse ».
- Le programmatic tool calling (le modèle écrit et exécute du code pour orchestrer les outils et filtrer les résultats intermédiaires) réduit encore « les tokens, les allers-retours vers le modèle et le besoin de supervision ».
Ces trois signaux pointent dans la même direction : GPT-5.6 a été optimisé pour faire plus avec chaque token. En production agentique, c'est souvent plus décisif qu'un point de benchmark supplémentaire : le coût et la latence d'un agent se logent dans le nombre d'étapes et d'appels d'outils, pas dans la qualité brute d'une réponse isolée.
La nuance à ne pas oublier : SWE-Bench Pro
Soyons rigoureux, car un article honnête ne cache pas le tableau qui dérange. Sur SWE-Bench Pro (résolution end-to-end d'issues GitHub réalistes), Claude reste nettement devant : Fable 5 à 80 %, Mythos 5 à 80,3 %, contre 64,6 % pour Sol. C'est un écart d'environ 15 points sur un test que beaucoup jugent plus proche du travail logiciel de fond.
OpenAI a certes publié, la veille de son lancement, un audit estimant qu'environ 30 % des tâches de ce benchmark seraient « cassées » et retirant sa recommandation d'usage4. L'argument technique mérite d'être entendu, mais son timing invite à la prudence. Pour l'architecture, la planification de haut niveau et les tâches longues et réalistes, Claude conserve un avantage qu'aucun score de terminal ne vient effacer.
En clair : ne choisissez pas, routez
Le verdict d'ingénieur se résume en une phrase : GPT-5.6 gagne sur le terminal et les agents en production ; Claude gagne sur les tâches longues, réalistes et la planification. Le bon choix n'est pas « l'un ou l'autre » : c'est de router chaque tâche vers le bon modèle, et de le prouver sur vos évals, avec votre code.
C'est aussi pourquoi la vraie variable d'ajustement n'est pas le modèle mais le harnais : à modèle égal, la qualité de l'ingénierie qui l'entoure (guides en amont, capteurs de retour, mémoire, garde-fous) pèse davantage que deux points de benchmark. Un bon benchmark vous dit où commencer à chercher. Il ne vous dit jamais quoi mettre en production. Ça, seul votre pipeline peut le trancher. Pour passer du « quel modèle ? » au « comment les faire travailler ensemble », lisez notre panorama de la famille GPT-5.6 et notre guide de choix Sol / Terra / Luna.
Sources
- OpenAI — annonce de GPT-5.6 (Sol / Terra / Luna), 9 juillet 2026 : tables de benchmarks officielles, dont Terminal-Bench 2.1. Scores auto-reportés par OpenAI ; se méfier des chiffres secondaires pré-lancement (Terra 82,5 %/84,3 % erronés ; table officielle : 87,4 %). À recouper sur sources primaires. openai.com
- Artificial Analysis — Coding Agent Index (DeepSWE + Terminal-Bench v2 + SWE-Atlas-QnA) et coûts par tâche. Index produit avec le soutien d'OpenAI en pré-lancement ; comparaisons Sol/Fable 5 sur harnesses différents (Codex vs Claude Code), non strictement « apples-to-apples ». artificialanalysis.ai
- OpenAI — « Separating signal from noise in coding evaluations », 8 juillet 2026 : audit estimant ~30 % de tâches SWE-Bench Pro « cassées », retrait de recommandation. Publié la veille du lancement — à interpréter avec prudence. openai.com
- Analyse first-party SFEIR de la consommation d'un cycle agentique (matière interne « Tokens & SDLC v3 »), d'après Bai et al., arXiv 2604.22750 (2026) : la facture suit l'ingestion (ratio 153:1), non la génération. arXiv 2604.22750
Articles similaires
GPT-5.6 Sol, Terra, Luna : comment OpenAI rebat les cartes du coding agentique et du pricing
Le 9 juillet 2026, OpenAI a rendu GPT-5.6 généralement disponible, non pas un modèle mais trois : Sol, Terra, Luna. Lecture d'ingénieurs, chiffrée et sans parti pris : ce que la famille change pour le coût d'inférence, le routing entre modèles et l'équilibre concurrentiel avec Claude.
Sol, Terra, Luna : comment choisir et optimiser les coûts dans la famille GPT-5.6
Avec GPT-5.6, OpenAI ne vend plus un modèle mais une échelle de prix-performance : un facteur 5× entre Luna et Sol. Bien exploitée, elle divise votre facture ; mal exploitée, elle la multiplie. Le guide de décision SFEIR pour choisir le bon tier et optimiser le prompt caching.
Pourquoi le sommet du leaderboard ne vous dit pas quel modèle choisir
À défaut du prix, on arbitre sur les benchmarks. Mauvais réflexe : un classement mesure des capacités moyennes sur des tests standardisés, pas la performance sur votre legacy. La précision plafonne, la variance explose, et l'écart au sommet compte moins que le harnais. Que mesurer à la place.
Un modèle par tâche : le guide du routing multi-modèles
Faire tourner toute une usine logicielle sur un seul modèle frontier, c'est payer le tarif du raisonnement pour lire des logs. La mécanique du routage multi-modèles : un modèle par phase, une passerelle unique, l'isolation des sous-agents et la règle qui dit quand le multi-agents mérite son coût.