Claude Sonnet 5.5 vs GPT-6 Sol : deux runtimes au même prix

Anthropic a lancé Claude Sonnet 5.5 le 28 septembre à 2 $ par million de tokens en entrée et 10 $ par million en sortie. OpenAI a sorti GPT-6 Sol le 22 septembre aux mêmes tarifs de 2 $ et 10 $. Six jours d'écart, une grille tarifaire identique, et chacun se positionne juste en dessous du modèle phare de son créateur. Pour une équipe cherchant à choisir le modèle par défaut de ses agents de code, le prix ne tranche absolument rien. Le véritable choix se joue entre Claude Code et Codex en tant que Runtime autour de chaque modèle, ainsi que sur le coût réel de chaque binôme par tâche accomplie.

Un comparatif rigoureux implique deux Runtimes, deux configurations, deux séries de résultats et un relecteur tentant désespérément de se souvenir quel terminal a généré quel diff. Choisir le modèle ne demande qu'une ligne de configuration. Les comparer relève d'un véritable chaos d'agents en miniature.

En résumé

Claude Sonnet 5.5 et GPT-6 Sol coûtent la même chose par token et se distinguent principalement par le Runtime dans lequel une équipe les exécute habituellement : Claude Code pour Sonnet 5.5, Codex pour Sol. Le tableau d'annonce d'Anthropic comprend quatre lignes comportant une colonne dédiée à GPT-6 Sol. Sonnet 5.5 l'emporte nettement sur trois d'entre elles ; la quatrième, FrontierCode, dépend de l'effort alloué. Le coût par tâche s'inverse selon le benchmark : sur FrontierCode, Sonnet 5.5 égale le meilleur résultat de Sol pour environ un cinquième du coût ; sur AA-Briefcase, le meilleur résultat de Sol revient à 2,67 $ par tâche, contre 29,19 $ pour Sonnet 5.5. Il ne s'agit toutefois que des chiffres d'un seul fournisseur. Pour départager Sonnet 5.5 et GPT-6 Sol, exécutez la même Task sur votre propre code via les deux Runtimes et mesurez le temps de revue humaine par modification acceptée. Conserver les deux est une option parfaitement légitime si la Task reste la source de vérité.

Ce que les chiffres publiés permettent réellement de comparer

Quatre lignes. L'article de lancement de Claude Sonnet 5.5 compare Sonnet 5.5, Sonnet 5, Opus 5.5 et GPT-6 Sol, et seules ces lignes indiquent un résultat pour Sol :

Il s'agit du tableau d'un seul fournisseur. La publication d'OpenAI sur Sol est parue six jours avant la sortie de Sonnet 5.5 ; le comparatif d'Anthropic est donc le seul tableau d'un éditeur à présenter les deux modèles. Les deux colonnes comportent toutefois une réserve liée à des bugs : les tests de Sonnet 5.5 par Artificial Analysis ont utilisé une version préliminaire affectée par un bug sur les sorties structurées (corrigé depuis), et OpenAI a récemment corrigé dans Sol un problème de compréhension d'images que les scores d'Artificial Analysis et de Surge AI ne reflètent peut-être pas.

La ligne FrontierCode est celle qu'une équipe d'ingénierie logicielle devrait examiner en priorité, car elle compare déjà les environnements d'exécution : 52,1 % contre 49,3 % correspond à Claude Code avec Sonnet 5.5 face à Codex CLI avec Sol, soit le binôme que vous déploieriez réellement en production. La note de bas de page sur le score au niveau maximal est tout aussi révélatrice. FrontierCode pénalise les modifications hors périmètre, et avec un effort maximal, Sonnet 5.5 a plus souvent déclenché la compétence de revue de code de Claude Code, qui délègue le travail à de multiples sous-agents. Dans deux cas analysés par Cognition, cela a entraîné un dépassement de délai ou des modifications en dehors du périmètre de la tâche. Plus d'effort, un diff plus vaste, et plus de temps passé en revue.

Aucun autre élément de la page ne comporte de chiffre pour Sol. Les graphiques d'effort de Terminal-Bench 4.0 et CursorBench 4.0 affichent GPT-5.6 Sol, car aucun chiffre concernant GPT-6 Sol n'a été publié.

Il existe un classement agrégé tiers. Au 29 septembre, Artificial Analysis attribue à l'endpoint de Sonnet 5.5 en effort maximal la note de 56 sur son Intelligence Index, le plaçant au 3ᵉ rang sur 216. Sol atteignait 48 le 23 septembre, lors de notre dernier relevé. Deux dates distinctes, un indice évolutif, et aucun de ces chiffres ne mesure les performances sur votre propre dépôt.

Le coût par tâche accomplie, et non par token

Des tarifs au token identiques ne disent pas grand-chose de la facture finale, car le nombre de tokens consommés par tâche dépend du modèle, du niveau d'effort et du Runtime. La page de lancement d'Anthropic publie les scores et les coûts par tâche selon l'effort pour deux des benchmarks communs :

Examinez d'abord FrontierCode. En configuration high, Sonnet 5.5 obtient 49,4 % pour 0,42 $ par tâche, faisant jeu égal avec le meilleur résultat de Sol (49,3 % à 2,07 $) ; le résumé d'Anthropic évoque « environ un cinquième du coût par tâche ». Mais le détail crucial se trouve plus bas : au niveau medium, Sonnet 5.5 tombe à 36,5 %, soit un score inférieur à celui de Sol en low, or medium est l'effort par défaut de Claude Code pour Sonnet 5.5. Le guide de prompting d'Anthropic conseille de démarrer à high, ou à medium pour le codage par agent sur des tâches bien spécifiées. Le paramètre que personne ne modifie peut donc faire basculer la comparaison.

AA-Briefcase, un benchmark orienté travail intellectuel et bureautique, montre la tendance inverse. Le meilleur score de Sol coûte 2,67 $ par tâche, tandis que celui de Sonnet 5.5 revient à 29,19 $ — environ onze fois plus cher — pour un score certes plus élevé. Le réglage de Sonnet 5.5 le plus proche du coût maximal de Sol, à savoir medium à 1,64 $, obtient 1461 contre 1483. Deux modèles identiques, mais une conclusion opposée sur celui qui s'avère le plus économique à résultat équivalent.

La mise en cache réduit l'écart et modifie la donne. Sonnet 5.5 facture la lecture d'entrées en cache à 0,10 $ par million, avec une écriture en cache de 5 minutes à 2,50 $ (tarifs Anthropic). GPT-6 applique une réduction de 90 % sur les lectures d'entrées en cache, soit 0,20 $ sur un tarif de base de 2 $ ; une lecture en cache coûte donc deux fois moins cher sur Sonnet 5.5. La nuance réside dans ce qui invalide le cache : OpenAI indique que modifier l'effort de raisonnement ou les outils disponibles ne l'invalide plus, tandis que le guide de prompting d'Anthropic pour Sonnet 5.5 précise que changer l'effort global entre les requêtes invalide le cache, et renvoie vers un paramètre bêta d'effort par message. Les agents qui ajustent leur effort en cours de tâche le ressentiront directement sur la facture.

Aucun de ces chiffres ne correspond à votre coût par modification acceptée. Une exécution peu coûteuse qui exige deux relances et une longue revue est en réalité la plus onéreuse.

Comment trancher sur votre propre base de code

Soumettez la même Task aux deux Runtimes et mesurez le temps qu'une personne passe à valider le résultat. La méthode détaillée se trouve dans comment comparer les agents de code sur votre propre base de code ; voici le protocole de configuration pour ce binôme.

Sharkly ne choisit pas les modèles à votre place. La documentation sur les Agents est sans équivoque : « L'Agent utilise le modèle par défaut du Runtime. Il ne garantit ni n'affiche de nom de modèle spécifique. Modifiez les modèles dans la configuration des outils du Runtime ou de Computer, pas au niveau de l'Agent. » La configuration du modèle s'effectue donc sur Computer :

• Claude Code avec claude-sonnet-5-5. Nécessite Claude Code v2.1.284 ou ultérieur. Le modèle default de Claude Code est Opus 5.5 pour les offres Pro, Max, Team, Enterprise et l'API Anthropic ; un Computer exécute donc Opus tant que personne ne le modifie, et l'alias sonnet ne renvoie vers Sonnet 5.5 que sur l'API Anthropic. Figez l'identifiant complet et confirmez avec claude --model claude-sonnet-5-5 sur cet hôte. Le guide exécuter des agents Sonnet 5.5 dans Sharkly détaille la procédure complète.
• Codex avec gpt-6-sol. Configurez le modèle dans les paramètres de Codex sur ce Computer ; l'article exécuter des agents GPT-6 Sol dans Sharkly décrit les étapes à suivre.
• Répertoire de travail temporaire sur les deux Agents. Chaque exécution dispose d'un répertoire isolé, et les exécutions adossées à un dépôt peuvent préparer un worktree vierge, garantissant ainsi que les deux tentatives ne partagent jamais le même checkout.

Ensuite, formalisez le protocole d'essai avant de lancer la moindre exécution :

Task:    SH-312, one real Task, same description and starting commit for both runs
Run A:   Claude Code Agent, claude-sonnet-5-5, effort: medium (Claude Code default) or high
Run B:   Codex Agent, gpt-6-sol, effort: whatever Codex on that Computer is set to, written here
Accept:  the same acceptance test for both
Record:  accepted y/n, human review minutes, reruns, files touched outside scope,
         provider cost from your own Anthropic and OpenAI bills
Decide:  after several Tasks of each kind you actually assign, not one

Assignez la Task à un premier Agent et démarrez le second en le mentionnant dans un commentaire ; Sharkly permet à une mention explicite de lancer un Agent même s'il n'est pas l'Assignee. Les deux exécutions renvoient leurs résultats sur la même Task : ainsi, deux diffs, deux exécutions de tests et toutes les questions éventuelles sont regroupés dans un fil unique au lieu de deux historiques de défilement séparés. La variante sur un bogue unique, assortie d'une grille d'évaluation, est présentée dans Claude Code vs Codex sur le même bogue.

Accordez la priorité absolue au temps de revue humaine. Le guide de prompting d'Anthropic précise que Sonnet 5.5 ajoute des tests, de la documentation et de petits fichiers quel que soit le niveau d'effort, fait des points d'étape précoces sur les longues tâches en low et medium, et lance des cycles de revue supplémentaires ou des sous-agents de relecture en xhigh et max. Quel que soit le comportement de Codex avec Sol dans des situations équivalentes, le test le mettra en lumière. Tout cela se répercute sur le temps de revue, alors que rien de tout cela n'apparaît dans le score d'un benchmark.

Pourquoi « les deux » est une réponse parfaitement valable

Les données publiées ne désignent aucun vainqueur universel, et vos propres essais n'en feront peut-être pas émerger non plus. Un résultat partagé constitue une conclusion en soi, pas un échec.

Choisissez un seul Runtime si vos tests ne révèlent aucune différence significative une fois le temps de revue décompté, ou si une petite équipe préfère gérer un abonnement unique et une seule configuration. Si vous utilisez exclusivement Claude Code et appréciez une approche axée sur le terminal, vous n'aurez peut-être besoin d'aucune couche de gestion. Conservez les deux si les performances varient selon le type de tâche, ou si vous souhaitez pouvoir changer de modèle par défaut le mois prochain sans reconstruire l'ensemble de votre flux de travail. Et l'échéance du mois prochain n'est pas une vue de l'esprit : Opus 5.5, Sol et Luna sont sortis le même jour, suivis de Sonnet 5.5 six jours plus tard.

Garder les deux ne fonctionne que si la Task — et non le Runtime — sert de référence centrale. Aucun autre modèle ne sait interpréter les blocs de réflexion de Sonnet 5.5 ; ainsi, lorsqu'une Task passe d'un Agent Claude Code à un Agent Codex, le raisonnement interne reste en arrière et seul ce qui est consigné sur la Task est transmis. Les décisions, hypothèses et questions en suspens doivent figurer dans la description ou en commentaire. L'article faire cohabiter Claude Code et Codex sur une même base de code détaille l'usage au quotidien, et Sonnet 5.5 ou Opus 5.5 aborde l'aiguillage côté Claude.

Les agents explorent, exécutent, testent et rendent compte. Les humains fixent le cap, accordent les autorisations et valident le résultat. Le Runtime peut changer chaque trimestre ; le contexte, l'avancement, les blocages, les résultats et la revue humaine doivent rester visibles au même endroit, de la demande initiale jusqu'à la mise en production.

La version de ce débat parue la semaine dernière, Opus 5.5 vs GPT-6 Sol, souffrait du problème inverse concernant les preuves fournies : l'article d'OpenAI comparait Sol à un modèle Claude rendu obsolète quelques heures plus tard. Définissez votre modèle par défaut, mesurez son efficacité sur votre code et gardez le Runtime sous la forme d'un simple paramètre ajustable. Si vous souhaitez continuer à exploiter plusieurs agents de code sans vous enfermer dans un seul écosystème, c'est précisément ce pour quoi Sharkly a été conçu. Connectez un Computer, créez un Agent par Runtime et confiez à chacun la même vraie Task.