Claude Opus 5.5 vs GPT-6 Sol : choisir le runtime par défaut de votre Crew

Une seule ligne dans un seul fichier de configuration décide où iront la majorité des tokens de votre équipe ce trimestre. Le 22/09/2026, les deux candidats pour cette ligne ont changé en même temps : Anthropic a livré Claude Opus 5.5, OpenAI a livré GPT-6 Sol et GPT-6 Luna. Si vous faites tourner plusieurs agents de codage en parallèle, la question n'est pas de savoir quel modèle est le plus intelligent. C'est de savoir lequel vos Agents utilisent par défaut, et l'effet que cela a sur la file de travail qui attend qu'une personne l'accepte.

Il y a un piège dans les données, qu'il vaut la peine de connaître avant de lire l'un ou l'autre des articles de lancement. OpenAI a comparé Sol à Claude Opus 5. Pas à Opus 5.5. Opus 5.5 n'existait pas quand cet article a été écrit, et il est sorti quelques heures plus tard à 4 $ par million de tokens en entrée, contre 5 $ pour Opus 5. Chaque mention « dépasse Opus 5 à une fraction du coût » dans l'article d'OpenAI est donc mesurée contre un modèle qui a été supplanté le jour même. Cela ne rend pas les chiffres faux. Cela en fait les derniers chiffres publiés plutôt que les chiffres actuels.

TL;DR

Un Runtime par défaut, c'est le modèle que vos Agents utilisent quand personne n'a choisi autrement — autrement dit, dans la plupart des exécutions. Choisissez-le selon trois axes : le coût par tâche terminée, le temps qu'il tient une tâche avant d'avoir besoin de vous, et ce qu'il fait quand il se retrouve bloqué. D'après les chiffres publiés, Sol est moins cher par tâche terminée, même si la seule comparaison publiée porte sur Opus 5 ; et c'est Opus 5.5 qui reste sur une longue tâche sans s'arrêter. Personne n'a confronté les deux sur un même harnais, alors considérez les deux articles de lancement comme des affirmations de fournisseurs et tranchez sur votre propre dépôt.

Ce que chaque fournisseur a réellement publié

Anthropic affirme qu'Opus 5.5 coûte 40 % de moins à exécuter qu'Opus 5, génère sa sortie environ 30 % plus vite et reste sur la tâche pendant 18 heures ou plus. La sortie maximale est de 128 k tokens, et un mode rapide est facturé séparément à 8 $ / 40 $.

OpenAI affirme que Sol et Luna sont chacun 50 % moins chers que le tarif promotionnel de GPT-5.6. Le mot « promotionnel » est d'OpenAI lui-même, et il compte : la comparaison porte sur un tarif remisé, pas sur le tarif catalogue de GPT-5.6. OpenAI précise aussi que GPT-6 Astra « reste notre meilleur modèle sur tous les plans », un rappel utile que Sol est l'offre au meilleur rapport qualité-prix de sa propre famille, et non son modèle phare.

Axe 1 : le coût par tâche terminée, pas le coût par million de tokens

Le prix des tokens n'est qu'une approximation de ce que vous payez réellement. Un modèle deux fois moins cher qui a besoin de trois tentatives coûte plus cher qu'un modèle qui réussit du premier coup. OpenAI publie le coût par tâche en même temps que le score, ce qui est inhabituellement direct.

La première ligne est celle que tout le monde cite. Sol en raisonnement extra-high obtient un meilleur score que Claude Opus 5 en raisonnement max, pour environ 9 % du coût par tâche d'Opus 5. Multipliez 0,27 $ par 11,1 et Opus 5 au max atterrit près de 3 $ par tâche sur ce harnais — un calcul de notre part à partir des deux chiffres d'OpenAI, pas un nombre qu'OpenAI a imprimé.

Appliquez maintenant le piège. Anthropic situe Opus 5.5 à 40 % de moins à exécuter qu'Opus 5, donc ce chiffre de 3 $ est périmé. Il ne baisse pas simplement des mêmes 40 % pour autant, car le coût par tâche dépend du nombre de tokens qu'un modèle consomme pour y arriver, et pas seulement du tarif catalogue. L'écart publié était important, l'un de ses côtés a bougé le jour même d'un montant annoncé, et personne n'a refait la comparaison. Si vous voulez ce chiffre pour votre base de code, faites la comparaison sur votre propre dépôt plutôt que d'attendre qu'un labo la fasse pour vous.

Pour donner l'échelle : OpenAI indique que son chercheur médian dépense plus de 600 $ par jour en agents de codage, et le 90e percentile 7 000 $ par jour. Le coût par tâche cesse vite d'être une abstraction.

Axe 2 : combien de temps il tient la tâche

Les deux fournisseurs ont répondu au même problème, mais pas au même endroit.

Anthropic y a répondu dans le modèle. Opus 5.5 reste sur la tâche pendant 18 heures ou plus. Une exécution qui dépasse votre journée de travail change la façon de superviser : vous cessez de la surveiller et vous vous mettez à y revenir, ce qui ne fonctionne que si l'exécution rend compte quelque part qui n'est pas un terminal que vous avez fermé.

OpenAI y a répondu dans le cache. GPT-6 applique 90 % de réduction sur les lectures d'entrée mises en cache, augmente les taux de succès du cache par défaut et, ce qui compte pour le travail des agents, ne casse plus le cache quand vous changez l'effort de raisonnement ou l'ensemble des outils disponibles. Des points de rupture explicites vous permettent de choisir où se termine un préfixe mis en cache. GitHub rapporte plus de 50 % de tokens de prompt en moins à retraiter, sur des milliards de requêtes. Une longue exécution d'agent, c'est surtout le même contexte lu de nombreuses fois : c'est donc un correctif sur le coût de la durée, pas sur la durée elle-même.

Utilisez Opus 5.5 par défaut quand votre Task typique est une migration, un gros refactoring ou tout ce dont l'interruption en cours de route coûte plus cher que les tokens. Utilisez Sol par défaut quand votre Task typique est bornée, répétée de nombreuses fois par jour et peu coûteuse à relancer. La plupart des équipes ont les deux cas de figure, et c'est pourquoi le choix du défaut importe moins que d'être délibéré sur les exceptions.

Axe 3 : ce qu'il fait quand il est bloqué

Cet axe n'a pas de benchmark, et c'est pourtant lui qui génère les tickets au support.

Artificial Analysis, un tiers plutôt que l'un ou l'autre des fournisseurs, a mesuré les variantes de raisonnement « max » à 115,2 tokens de sortie par seconde pour Sol, avec 102,15 secondes avant le premier token, et à 153,9 tokens par seconde pour Luna, avec 124,23 secondes. Ce sont des configurations à effort maximal, et vous devriez les confirmer sur la fiche actuelle avant de parier dessus. C'est la forme qui compte : à effort de raisonnement élevé, les modèles bon marché ne sont pas ceux qui démarrent vite.

Un agent qui réfléchit depuis 102 secondes et un agent qui est planté sont identiques dans un terminal. Tout comme un agent qui a terminé il y a 40 minutes et un agent qui s'est arrêté pour poser une question que personne n'a vue. Aucune sortie de modèle ne corrige cela. Un statut qui remonte jusqu'à la Task, oui : In Progress, Waiting for human, Failed, Ready for release, avec le journal et la question attachés. Les agents font la recherche, exécutent, testent et rendent compte. Les humains donnent la direction, accordent l'autorité et acceptent le résultat.

Accordez à la façon dont chaque Runtime signale sa progression et ses échecs la même importance qu'au tableau de benchmarks. Vous lirez le statut cent fois par semaine, et le benchmark une fois.

Ne mettez pas les deux tableaux de benchmarks côte à côte

Les deux fournisseurs ont publié un chiffre AutomationBench cette semaine. OpenAI a rapporté un score de 33,2 % pour Sol en raisonnement extra-high sur AutomationBench 1.0.6. Anthropic a rapporté 40,0 % pour Opus 5.5 sur AutomationBench. Les deux ont rapporté OSWorld 2.0, à 60,5 % et 81,8 % respectivement, et le chiffre d'OpenAI porte sur l'ensemble hors ligne.

Ce n'est pas une confrontation directe. Réglages de raisonnement différents, au moins une variante de benchmark différente, des harnais différents, aucun chiffre de coût par tâche partagé, et chaque test réalisé par la partie qui y a intérêt. Les posts qui comparent Opus 5.5 à GPT-6 Astra sur des chiffres précis sont des tweets, pas des données de fournisseurs. Artificial Analysis publie bien un index commun, qui place Opus 5.5 à 58 et premier sur 212 modèles, Sol à 48 et Luna à 37 — mais c'est un agrégat tiers, pas une mesure de votre base de code.

La décision qui survivra au prochain lancement

Écrivez le défaut noir sur blanc. Pas comme une préférence que quelqu'un garde en tête, mais comme une règle rattachée à l'Agent : cet Agent fait tourner ce Runtime, ces Tasks lui sont destinées, et voici l'Agent moins cher qui prend celles de routine. Quelque chose comme ceci, gardé là où l'équipe le lit :

Default Runtime: Claude Code on claude-opus-5-5
  Tasks: migrations, wide refactors, anything that fails badly halfway
Second Runtime: Codex on gpt-6-sol
  Tasks: bounded, repeated many times a day, cheap to retry
Escalation: a Sol Task that fails twice returns to the Task for a person,
  it does not silently re-run on the expensive Runtime

C'est ce qui transforme quel modèle pour quelle tâche en débit, et cela survit au prochain lancement, parce que quand la réponse change, vous modifiez une règle au lieu de demander à six personnes ce qu'elles utilisent. Deux labos ont sorti leur meilleure offre au rapport qualité-prix le même jour, et l'un a mesuré ses performances contre un modèle devenu obsolète quelques heures plus tard. Un Runtime par défaut que vous pouvez changer à un seul endroit vaut mieux que de faire le bon choix cette semaine.

Ce que ni l'un ni l'autre des lancements n'a changé, c'est la file d'attente. Le coût par tâche terminée a chuté fortement des deux côtés, si bien qu'un budget fixe achète désormais plusieurs fois plus de travail d'agent terminé que la semaine dernière. Il n'achète pas une seule heure de relecture supplémentaire. La capacité de relecture est le plafond, et une baisse de prix pousse le volume contre ce plafond au lieu de le soulager. Gardez l'objectif, l'exécution, les blocages, le diff et la relecture humaine visibles au même endroit, de la demande à la livraison, et le Runtime par défaut devient un réglage plutôt qu'un pari.

Sharkly ne fait pas tourner le modèle et ne le choisit pas à votre place. C'est la couche partagée de Task, de Computer, de contexte et de relecture autour des outils qui s'en chargent. Si vous voulez continuer à utiliser plusieurs agents de codage plutôt que de vous engager dans un seul écosystème, c'est le problème autour duquel il est conçu. Connectez un Computer, créez un Agent sur chaque Runtime, et confiez-leur la même Task banale.