GPT-5.5 vs GPT-5.4 vs Opus 4.7 — comparaison sur 56 tâches réelles de programmation

• Publication des résultats d’un benchmark comparant la qualité des patchs de trois modèles — GPT-5.5, GPT-5.4 et Opus 4.7 — sur 56 tâches réelles de programmation extraites de deux dépôts open source (Zod, graphql-go-tools)
• GPT-5.5 obtient le meilleur score sur tous les indicateurs : taux de tests réussis, équivalence avec les patchs humains et taux de réussite en revue de code (clean pass)
• Opus 4.7 génère les patchs les plus petits et présente un risque d’empreinte plus faible, mais montre un schéma d’échec récurrent avec des implémentations incomplètes dues à l’omission de travaux annexes
• Le simple passage des tests ne suffit pas à juger la qualité d’un patch ; une évaluation multicouche incluant l’acceptation par les reviewers est nécessaire
• Le classement d’un même modèle varie selon le dépôt, ce qui fait de l’exécution de benchmarks sur sa propre base de code un élément clé du choix du modèle

---

Vue d’ensemble du benchmark et environnement d’exécution

• Comparaison de trois modèles sur 56 tâches réelles de programmation au total : 27 dans Zod et 29 dans graphql-go-tools
• Chaque modèle a été exécuté avec sa configuration par défaut dans son agent harness officiel : Opus 4.7 avec Claude Code, GPT-5.4 et GPT-5.5 avec OpenAI Codex CLI
• Le niveau de reasoning de tous les modèles a été harmonisé sur high
• Utilisation du framework d’évaluation Stet, qui note non seulement la réussite aux tests, mais aussi l’équivalence comportementale, l’acceptabilité en revue de code, le risque d’empreinte, ainsi que des rubriques de savoir-faire (craft) et de discipline
• Une seule exécution par tâche avec seed unique ; le modèle utilisé pour juger l’équivalence et les rubriques est GPT-5.4

Résumé des résultats globaux

• GPT-5.5 arrive premier sur tous les indicateurs avec 38/56 tests réussis, 40/56 en équivalence avec les patchs humains et 28/56 clean pass
• Opus 4.7 obtient 33/56 tests réussis, 19/56 en équivalence et 10/56 clean pass, soit le score de qualité le plus bas
  • En contrepartie, il affiche le risque d’empreinte moyen le plus faible, à 0.20, ce qui lui donne l’avantage sur la taille des patchs
• GPT-5.4 obtient 31/56 tests réussis, 35/56 en équivalence et 11/56 clean pass
  • Avec un coût de 2,39 $ par tâche, c’est le moins cher, mais cela ne compense pas l’écart sur les clean pass
• GPT-5.5 affiche un temps moyen par tâche de 6 min 56 s, 201.8M tokens d’entrée et 0.72M tokens de sortie, ce qui en fait aussi le plus efficace

Analyse des performances par dépôt

• Zod (27 tâches) : GPT-5.5 et Opus réussissent tous deux 12 tests, mais GPT-5.5 mène sur la qualité de revue avec 10 clean pass contre 5 pour Opus
  • Opus garde l’avantage sur la taille des diff, ce qui crée dans Zod un véritable compromis
• graphql-go-tools (29 tâches) : GPT-5.5 domine nettement avec 26 tests réussis et 18 clean pass
  • Opus réussit 21 tests mais ne décroche que 5 clean pass, sa stratégie de petits patchs conduisant à des omissions dans le travail d’intégration

Indicateurs de qualité détaillés

• Réussite en revue de code : GPT-5.5 33/56, GPT-5.4 16/56, Opus 11/56
• Moyenne en revue de code (exactitude + sécurité vis-à-vis des bugs) : GPT-5.5 3.08, GPT-5.4 2.59, Opus 2.33
  • Exactitude (correctness) seule : GPT-5.5 3.16 vs GPT-5.4 2.60 vs Opus 2.11
  • Sécurité vis-à-vis de l’introduction de bugs : GPT-5.5 3.04 vs GPT-5.4 2.56 vs Opus 2.55
• Moyenne des évaluateurs personnalisés (8 rubriques) : GPT-5.5 2.62, GPT-5.4 2.40, Opus 2.33
• Score de savoir-faire (clarity/coherence/robustness) : GPT-5.5 arrive premier sur les trois sous-catégories
• Score de discipline (scope discipline/diff minimality) : GPT-5.5 mène de peu avec 2.36, contre 2.20 pour Opus
  • Opus est devant sur l’empreinte brute, mais GPT-5.5 l’emporte sur la discipline relative à la tâche

La réussite aux tests n’est pas le critère final

• Dans Zod, Opus et GPT-5.5 sont à égalité avec 12 tests réussis, mais le clean pass est de 10 pour GPT-5.5 contre 5 pour Opus
• Dans graphql-go-tools, le même schéma est amplifié : GPT-5.5 obtient 26 tests réussis / 18 clean pass, contre 21 tests réussis / 5 clean pass pour Opus
• Cas du PR GraphQL #1001 : les trois modèles ont réussi les tests et obtenu l’équivalence, mais seul GPT-5.5 passe la revue de code
  • Les deux autres ont reçu des avertissements sur la forme de l’API, l’exposition d’objets HTTP bruts et la robustesse des frontières de hook

Différences concrètes mises en évidence en revue de code

• Tâche sur les codecs asynchrones et les valeurs par défaut dans Zod : les trois modèles échouent aux tests
  • Opus modifie 8 fichiers, mais manque des éléments sémantiques clés (autoriser undefined dans la valeur par défaut, conserver la définition synchrone du codec)
  • GPT-5.4 modifie 11 fichiers et obtient l’équivalence, mais restreint excessivement une API adjacente (prefault)
  • GPT-5.5 échoue aussi aux tests, mais couvre plus proprement le comportement du schéma et du build, obtenant les meilleures notes en exactitude et en risque de bug
• Validation de compatibilité GraphQL Apollo (PR #1169) : les trois modèles réussissent les tests, mais seul GPT-5.5 obtient à la fois l’équivalence et la validation en revue
  • Opus modifie 11 fichiers, mais omet la validation des feuilles enum/wrapped scalar
  • GPT-5.4 modifie 12 fichiers et élargit trop le périmètre avec des métadonnées de validation inconditionnelles
  • GPT-5.5 modifie 10 fichiers (dont 6 hors tests), soit le plus petit nombre, tout en implémentant exactement le comportement visé

Caractéristiques et limites d’Opus 4.7

• Produit des patchs conservateurs, précis et à faible empreinte
• Particulièrement à l’aise quand la tâche est locale et que la surface de changement est réduite
• Schéma d’échec récurrent : il implémente le comportement central sans terminer le travail annexe (companion work)
  • Cas des arbres Node/Deno parallèles dans Zod : Opus ne modifie que 4 fichiers et réussit les tests, tandis que GPT-5.5 en modifie 11 en incluant toute la surface de déploiement parallèle → équivalence avec le patch humain
• Dans graphql-go-tools, c’est plus marqué : sur le PR #1155 (champ scalaire répétitif de datasource gRPC et autres changements sur la surface du moteur), Opus ne parvient même pas à générer un patch, tandis que GPT-5.5 réussit tests, équivalence et revue
• Distinction clé : les petits patchs d’Opus relèvent de la discipline sur les tâches locales, mais d’une implémentation inachevée sur les tâches d’intégration

Évolution de GPT-5.4 vers GPT-5.5

• GPT-5.4 trouve souvent la bonne direction, mais échoue à l’exécution
  • Dans Zod, il atteint 18 équivalences (autant que GPT-5.5), mais ne réussit que 9 tests
• GPT-5.5 conserve les comportements d’intégration larges tout en générant moins de patchs cassés
• Comparaisons concrètes :
  • Générateur schema→TypeScript : Opus et GPT-5.5 implémentent un visiteur récursif, tandis que GPT-5.4 classe mal la tâche en générant un fichier de guide du dépôt
  • Correctif du parseur récursif : les deux modèles GPT adoptent une approche de suivi du nombre de visites, mais GPT-5.5 est plus concis en supprimant de l’état inutile
  • Validation CIDR : GPT-5.5 met aussi à jour le miroir Deno, alors que GPT-5.4 ne le répercute pas (problème d’hygiène du dépôt)
• Sur le PR #1232 de graphql-go-tools (déduplication d’un single fetch identique + réécriture des références de dépendances), seul GPT-5.5 réussit tests, équivalence et revue
• Schéma général : GPT-5.5 accomplit davantage du travail d’intégration répétitif nécessaire pour transformer une correction locale intelligente en changement réellement déployable dans le dépôt

Compromis entre taille des patchs et coût

• Taille moyenne des patchs dans graphql-go-tools : GPT-5.5 environ 33 KB, GPT-5.4 27 KB, Opus 19 KB
• Score d’empreinte : Opus 0.19, GPT-5.4 0.32, GPT-5.5 0.34
• Les grands patchs augmentent la difficulté de revue, le risque de conflit et l’exposition à des chemins sensibles
  • Dans des workflows centrés sur l’auditabilité, Opus garde donc un avantage réel
• En revanche, si la diff minimality est évaluée relativement à la tâche, GPT-5.5 passe légèrement devant
  • Point clé : un patch de 5 KB qui oublie une surface nécessaire n’est pas plus minimal qu’un patch de 20 KB qui accomplit réellement la tâche
• Comparaison des coûts :
  • Dans Zod, Opus et GPT-5.5 sont proches (Opus 45.53 $ vs GPT-5.5 46.69 $)
  • Dans graphql-go-tools, Opus consomme 186.1M tokens d’entrée / 934K de sortie / 8.56 h d’agent, tandis que GPT-5.5 se limite à 151.4M / 431K / 4.16 h, ce qui le rend bien plus efficace

Résumé des comportements par modèle

• Opus 4.7 — portée insuffisante (under-reach) : conservateur, précis, faible empreinte, fort sur les tâches locales mais fragile sur les surfaces annexes que les tests ne couvrent pas complètement ; son mode d’échec est « tests réussis mais changement non équivalent »
• GPT-5.4 — bonne forme, mauvaise exécution : la direction est souvent correcte mais l’ensemble reste irrégulier, avec des miroirs obsolètes, des refactorings inutiles et des patchs parfois mieux notés par les juges que par les tests
• GPT-5.5 — plus large, plus grande empreinte : plus complet sur les surfaces d’intégration, meilleur sur les mises à jour de code périphérique, le passage en revue et la transformation de l’intention en code effectif ; le risque, en cas d’erreur, est une erreur touchant davantage de fichiers

Différences de comportement des agents

• Dans graphql-go-tools, Opus effectue en moyenne 3.17 appels explicites de planification par tâche, contre 0 pour GPT-5.5
• Opus effectue 10.2 appels de patch par tâche, GPT-5.5 9.9, soit des niveaux comparables
• GPT-5.5 lance environ deux fois plus d’appels shell et davantage d’appels de recherche, tandis qu’Opus dépense plus de budget en planification et réécriture de patchs
• Dans ce dépôt, une exploration plus large du dépôt s’est révélée plus efficace qu’une réflexion plus poussée sur des patchs étroits

Pourquoi ces résultats comptent

• La vraie question n’est pas « quel modèle est le meilleur ? », mais « dans ce dépôt, avec ce harness, et sur les types de tâches réellement déployés, à quels patchs de quel modèle peut-on faire confiance ? »
• Dans Zod, GPT-5.5 et Opus sont dans une relation de compromis ; dans graphql-go-tools, GPT-5.5 affiche une supériorité nette
• Les benchmarks publics aplatissent souvent le comportement des modèles en un chiffre agrégé unique, alors que dans le code réel il faut raisonner en termes de décisions de workflow selon la base de code et les critères propres

Points d’attention

• 56 tâches restent un échantillon réduit ; une seule tâche peut faire varier de plusieurs points les ratios au niveau d’un dépôt
• Tous les modèles n’ont été exécutés qu’une fois par tâche ; certains résultats serrés pourraient s’inverser en cas de nouvelle exécution
• Le modèle chargé de juger l’équivalence et les rubriques étant GPT-5.4, un biais de famille de modèles est possible
  • Cela n’explique toutefois pas l’ensemble des résultats : GPT-5.5 dépasse nettement GPT-5.4, l’avantage d’Opus sur l’empreinte reste présent, et nombre de ses échecs d’équivalence proviennent d’omissions concrètes de fichiers
• Les résultats sont conditionnés par le harness : Claude Code et Codex CLI diffèrent par le system prompt, la boucle de planification et la surface d’outils
  • Exécuter Opus via l’API Codex, ou GPT-5.5 dans Claude Code, pourrait faire varier les résultats
  • Les chiffres présentés reflètent le comportement des modèles dans les harness réellement utilisés par les ingénieurs

Conclusion clé

• GPT-5.5 est le meilleur modèle de déploiement par défaut sur ces deux dépôts
• Opus 4.7 reste un modèle à faible empreinte, à privilégier quand une diff étroite est le critère principal
• GPT-5.4 est le moins cher par tâche, mais cela ne suffit pas à compenser son retard sur les clean pass
• Les tests seuls masquent le résultat le plus important
• Le classement d’un même modèle varie selon les dépôts, ce qui est précisément la raison d’être essentielle des benchmarks sur son propre dépôt

[shakespeares]

Par moments, on a l’impression qu’ils se mettent d’accord.