Sonnet 5.5 ou Opus 5.5 : à quel agent confier la tâche ?

Anthropic a lancé Claude Sonnet 5.5 le 28 septembre, six jours après Opus 5.5. À 2 $ par million de tokens en entrée et 10 $ par million en sortie, son tarif est deux fois inférieur à celui d'Opus 5.5 (4 $ et 20 $). De plus, sur la page de lancement, il se situe à quelques points seulement d'Opus 5.5 sur la plupart des tests et le dépasse même sur Terminal-Bench 4.0, un benchmark réalisé en interne par Anthropic. Pour une équipe qui fait tourner plusieurs agents de développement, la tentation est grande de basculer tous les agents sur Sonnet pour empocher la différence.

Pourtant, les graphiques détaillant les résultats par niveau d'effort figurant sur cette même page incitent à la prudence. Le score phare sur Terminal-Bench a été obtenu avec le niveau d'effort maximal de Sonnet, soit 12,54 $ par tentative. Avec des paramètres adaptés à un usage continu tout au long de la journée, la tendance s'inverse : Opus 5.5 avec un effort medium atteint 57,6 % pour 2,94 $, Sonnet 5.5 en effort high obtient 43,0 % pour 1,94 $, et Sonnet ne dépasse Opus en medium qu'au niveau xhigh, avec 61,5 % pour 5,30 $.

TL;DR

Par défaut, confiez les tâches bien délimitées à Sonnet 5.5 avec un effort medium. Réservez les travaux longs, ambigus ou transversaux à Opus 5.5 plutôt que de pousser Sonnet au niveau xhigh : sur les trois graphiques de code par niveau d'effort publiés par Anthropic, Opus en high surpasse Sonnet en xhigh pour un coût équivalent ou inférieur. Formalisez cette règle directement au niveau de l'Agent au lieu de vous fier à des préférences tacites : un Agent par combinaison de modèle et de niveau d'effort, des critères d'escalade explicites et une définition précise de ce qui est terminé (Definition of Done). Sharkly ne choisit ni le modèle ni l'effort : il garde la trace de ce que chaque Agent a accompli sur la Task.

Ce que confirment les chiffres du lancement

Voici le tableau récapitulatif du lancement, précisant le niveau d'effort derrière chaque résultat et l'entité qui a conduit l'évaluation :

Benchmark	Publié par	Sonnet 5.5	Opus 5.5
Terminal-Bench 4.0	Anthropic	70.6% (max)	66.4% (xhigh)
FrontierCode 1.1	Cognition	52.1% (xhigh), 46.2% (max)	54.4% (max)
CursorBench 4.0	Cursor	55.5% (max)	57.8% (max)
SWE-Bench Pro	System card d'Anthropic, effort max	81.3	89.9
HLE, avec outils	Anthropic	64.5%	67.7%
OSWorld 2.1	Anthropic	80.1%	81.8%

Deux réserves majeures s'imposent concernant la ligne Terminal-Bench. D'une part, la fiche système (system card) indique que des requêtes signalées ont affecté 10 % des essais d'Opus 5.5, contre seulement 1,5 % de ceux de Sonnet. D'autre part, les tests indépendants menés par Artificial Analysis ont mesuré Sonnet 5.5 à 63,6 %, et non 70,6 %. De son côté, SWE-Bench Pro affiche un écart de 8,6 points en faveur d'Opus. Le positionnement officiel d'Anthropic concorde d'ailleurs avec ce constat : Sonnet 5.5 est taillé pour les tâches quotidiennes bien définies et les corrections de bugs, tandis qu'Opus 5.5 « demeure nettement supérieur sur les projets complexes et ouverts ».

Ces chiffres globaux masquent également l'élément indispensable à l'établissement d'une règle de routage efficace : les scores et coûts par tâche sur les trois benchmarks de code, évalués à des niveaux d'effort réalistes en production.

Benchmark	Sonnet 5.5 medium	Sonnet 5.5 high	Sonnet 5.5 xhigh	Opus 5.5 medium	Opus 5.5 high
Terminal-Bench 4.0	28.8%, $0.83	43.0%, $1.94	61.5%, $5.30	57.6%, $2.94	64.2%, $3.88
CursorBench 4.0	39.2%, $0.70	47.8%, $1.67	53.1%, $3.88	52.5%, $2.91	56.0%, $3.97
FrontierCode 1.1	36.5%, $0.24	49.4%, $0.42	52.1%, $1.59	54.6%, $0.80	54.0%, $1.09

Sonnet 5.5 représente l'option la plus économique avec les efforts medium et high, niveaux où ses scores sont également les plus faibles. Au-delà du niveau high, les courbes se croisent : Sonnet en xhigh coûte plus cher qu'Opus en medium sur les trois benchmarks, et se fait distancer par Opus en high sur chacun d'eux pour un coût équivalent ou moindre. Le modèle économique cesse d'être avantageux dès lors qu'on exige de lui les capacités d'un modèle haut de gamme. Les coûts de Sonnet sur CursorBench ne sont que des estimations fournies par Anthropic, et aucune de ces tâches ne reflète fidèlement votre propre base de code : considérez donc ce point de bascule comme une hypothèse à valider en conditions réelles.

Formaliser la règle de routage

Nos précédents articles recommandaient d'associer les modèles aux rôles des Agents, d'attribuer les tâches aux agents selon leur nature et de traduire ces paliers en règles claires. L'arrivée de Sonnet 5.5 y ajoute une dimension déterminante. Sur Terminal-Bench, le coût unitaire d'un même modèle varie d'un facteur 15 entre medium et max (0,83 $ contre 12,54 $) : une instruction telle que « router vers Sonnet » ne constitue donc pas une règle exploitable tant qu'elle ne stipule pas le niveau d'effort.

Nature de la tâche	Agent (modèle d'exécution)	Effort	Justification
Correction de bug avec scénario de reproduction et test ciblé	Sonnet 5.5	medium	Le guide de prompting d'Anthropic préconise medium pour le code agentique sur des tâches bien spécifiées
Échafaudage de tests, documentation, changelog, montée de version des dépendances	Sonnet 5.5	medium	Périmètre strict, vérification peu coûteuse, moins d'un dollar par tâche sur l'ensemble des graphiques
Fonctionnalité circonscrite à un seul module, critères d'acceptation précis	Sonnet 5.5	high	Toujours plus économique qu'Opus en medium sur chaque benchmark ; palier supérieur de rentabilité pour Sonnet
Triage nocturne ou à fort volume	Sonnet 5.5	low, avec étape de vérification	Le coût par exécution le plus faible, mais en low, le modèle peut signaler la fin du travail sans lancer les tests
Refactorisation complexe ou ambiguë, migration, modifications transversales	Opus 5.5	medium ou high	En high, surpasse Sonnet en xhigh sur l'ensemble des benchmarks pour un coût similaire ou plus avantageux
Planification : structuration d'une demande vague en Tasks exploitables	Opus 5.5	high	Les problématiques ouvertes et complexes représentent précisément le domaine où Anthropic garantit la supériorité d'Opus
Revue du code ou des livrables d'un autre Agent	Opus 5.5, puis validation humaine	high	Un second modèle examine les éléments de preuve ; un relecteur humain valide le résultat final

C'est sur les conditions d'escalade qu'une telle règle prend toute sa valeur. Lorsqu'un Agent Sonnet est en difficulté, le réflexe immédiat est souvent d'augmenter son niveau d'effort. Les benchmarks prouvent pourtant qu'il vaut mieux changer de modèle : une Task qui requiert Sonnet en xhigh est, chiffres à l'appui, une tâche taillée pour Opus en high. Définissez vos propres seuils ; voici des exemples concrets pour vous guider :

Un contrôle donné a échoué à deux reprises. Un relecteur transfère la Task à l'Agent Opus en joignant le journal d'erreurs ; aucun rejeu silencieux sur un palier plus élevé n'est autorisé.
La modification impacte un volume de fichiers supérieur à la limite allouée à un worker (par exemple huit fichiers), ou touche à un chemin non mentionné dans la Task.
L'Agent soulève une interrogation de conception architecturale, et non une simple précision relative à la formulation de la Task.
Une classe de Tasks donnée ne réussit avec Sonnet qu'en dépassant le niveau high. Basculez cette catégorie vers l'Agent Opus dès le Sprint suivant.

Le raisonnement fonctionne aussi en sens inverse : les Tasks Opus menées à bien systématiquement dès la première tentative avec des diffs minimes gagnent à être redescendues d'un palier.

L'impact de chaque modèle sur la file de revue

Une règle qui n'encadre que le modèle et l'effort reste incomplète. L'autre versant consiste à formaliser ce que signifie « terminé », car chaque palier remet au relecteur un résultat de nature bien différente, alors même que la revue humaine représentait déjà le principal goulet d'étranglement avant ces sorties. Baisser le coût d'exécution multiplie les diffs, pas les heures disponibles des relecteurs.

Le guide de prompting d'Anthropic pour Sonnet 5.5 décrit sans détour ce que constatera un relecteur :

Aux niveaux low et medium, il sollicite rapidement l'utilisateur sur les tâches agentiques au long cours : sur un tableau de bord, cela se traduit par une Task bloquée à 2 h du matin dans l'attente d'une validation humaine. Un intervenant sur Hacker News a justement imputé à ce comportement un score de seulement 7,4 % sur un benchmark personnalisé (alors que Sonnet 5 atteignait 17,8 %).
Au niveau low, il a tendance à sauter la phase de vérification et à présenter le code comme achevé sans exécuter la suite de tests. La mention « terminé » par un Agent de triage n'a aucune valeur en l'absence du retour des tests.
Quel que soit le niveau d'effort, il produit spontanément des tests, de la documentation et des fichiers annexes que personne n'a sollicités. Si certains ajouts s'avèrent utiles, l'ensemble alourdit inévitablement la masse de diffs à inspecter.
Aux niveaux xhigh et max, il déclenche des cycles de revue additionnels ou fait appel à des sous-agents de vérification. La documentation de lancement souligne que c'est pour cette raison que Sonnet 5.5 a obtenu un score plus faible sur FrontierCode au niveau max qu'au niveau xhigh : il sollicite plus volontiers la capacité de revue de code intégrée à Claude Code, qui se déploie sur une multitude de sous-agents. Dans deux cas analysés par Cognition, cela a entraîné un dépassement de délai (timeout) ou des éditions hors périmètre. Ce sont là les anomalies les plus coûteuses à gérer en revue, car elles imposent un examen minutieux ligne par ligne.

Opus 5.5 pèse différemment sur la file de relecture. Anthropic souligne qu'il peut rester focalisé sur une tâche pendant 18 heures d'affilée tout en générant jusqu'à 128k tokens en sortie : sa contrainte majeure tient donc au volume produit plutôt qu'au bruit parasite, et le dossier de transmission structuré attendu par le relecteur s'impose tout autant dans son cas.

La définition de ce qui est terminé doit par conséquent figurer explicitement dans les consignes de l'Agent worker, que Sharkly injecte à chaque exécution :

Agent: sonnet-worker  (Claude Code, claude-sonnet-5-5, effort medium)

Done means:
- The checks named in the Task ran. Paste each command and its exit
  code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
  created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.

Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.

Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.

Exploiter les deux paliers au sein de Sharkly

Sharkly ne choisit pas le modèle à votre place et n'en règle pas l'effort. La documentation consacrée aux Agents l'indique clairement : « L'Agent applique le modèle par défaut du Runtime. Il ne garantit ni n'affiche aucun modèle particulier. La sélection du modèle s'effectue dans la configuration de l'outil Runtime ou Computer, et non sur l'Agent. » Aucun paramètre d'intensité de réflexion n'est présent sur l'Agent. Un palier correspond en réalité à une configuration de Claude Code au sein d'une ressource Computer ; l'Agent constitue l'interface par laquelle l'équipe lui délègue du travail.

La logique est donc directe : un Agent par palier. L'Agent sonnet-worker opère sur un Computer doté d'une configuration Claude Code pointant vers claude-sonnet-5-5, tandis qu'opus-lead tourne sur une machine paramétrée avec claude-opus-5-5. Un Computer pouvant être un conteneur logiciel, l'ajout d'un second palier n'exige nullement l'achat d'un ordinateur portable supplémentaire. Trois aspects techniques issus de la documentation de configuration des modèles de Claude Code garantissent qu'un palier corresponde exactement à sa dénomination :

Spécifiez l'identifiant complet. L'alias générique sonnet ne renvoie vers Sonnet 5.5 que sur l'API native d'Anthropic (Bedrock et Google Cloud le font pointer vers Sonnet 4.5), et Sonnet 5.5 impose Claude Code v2.1.284 ou une version plus récente.
Le modèle default de Claude Code est Opus 5.5 sur les forfaits Pro, Max, Team, Enterprise ainsi que sur l'API : une ressource Computer vierge de configuration personnalisée constitue donc de fait un palier Opus.
Le niveau d'effort par défaut de Sonnet 5.5 dans Claude Code est medium, ce qui coïncide avec le palier worker défini ci-dessus. Tout ajustement se règle au niveau du Computer, jamais sur l'Agent.

Comme Sharkly ne peut identifier de façon fiable le modèle précis exploité par un Runtime, intégrez la désignation du palier dans le nom de l'Agent et mettez à jour conjointement l'intitulé et la configuration. Le guide de configuration de Sonnet 5.5 récapitule les différentes étapes.

Pour les travaux nécessitant l'intervention coordonnée des deux paliers sur une seule Task, optez pour une Crew. Une Crew est un ensemble réutilisable d'humains et d'Agents sous la houlette d'un Agent leader. En désignant opus-lead comme coordinateur et des workers Sonnet comme membres, le leader analyse la Task, traite une partie du problème ou délègue un volet à un membre via une mention, après quoi chaque collaborateur consigne ses résultats au sein de cette même Task. Ce schéma concrétise l'architecture d'orchestration par Opus évoquée par les contributeurs de Hacker News, tout en restituant les transitions de façon lisible pour une personne. Pour les interventions modestes et parfaitement délimitées, dispensez-vous de la Crew et affectez directement la tâche à sonnet-worker.

L'alias opusplan proposé par Claude Code applique une logique similaire dans le cadre d'une session unique : Opus intervient pour la conception du plan, et Sonnet prend le relais pour l'implémentation. La composante Sonnet ne renvoie toutefois vers Sonnet 5.5 que sur l'API Anthropic ; sur Bedrock, Google Cloud ou Foundry, elle charge une mouture plus ancienne. Cette option convient parfaitement lorsqu'un développeur unique mène et inspecte la session d'un bout à l'autre ; privilégiez deux Agents dès lors qu'un tiers doit tracer sans équivoque qui a conçu la solution et qui l'a codée.

Une frontière demeure absolument étanche entre les deux paliers : le fil de raisonnement. Les blocs de pensée (thinking blocks) de Sonnet 5.5 sont strictement inféodés au modèle et à la session en cours. Aucun modèle tiers ne peut y avoir accès, et Sonnet 5.5 ne dispose d'aucune visibilité sur les réflexions d'Opus 5.5. Le partage du système de fichiers d'une Crew transmet des fichiers de code, mais en aucun cas l'état de la session de l'Agent précédent. Les arbitrages du leader ne parviennent au travailleur que s'ils sont explicitement documentés sur la Task, une problématique qui fait l'objet d'un article à part entière.

Cette approche ne modifie en rien la répartition finale des rôles. Les Agents explorent, exécutent, testent et synthétisent. Les humains fixent les objectifs, délèguent l'autorité et valident les livrables. Les dépenses mentionnées précédemment sont directement répercutées sur votre facture d'accès aux modèles, la consommation s'effectuant via vos souscriptions ou clés API configurées en amont. L'assignation, les traces d'exécution, les interrogations, le résultat et la validation humaine restent ancrés au niveau de la Task, indépendamment du modèle qui dominera les classements au prochain trimestre. Cette cohérence transcende par ailleurs les différents fournisseurs d'IA, comme l'illustre le comparatif entre Sonnet 5.5 et GPT-6 Sol. Si votre ambition est de faire collaborer plusieurs agents de programmation sans vous lier les mains à un écosystème fermé, c'est très exactement pour répondre à ce défi que Sharkly a été conçu.