Les débuts de Claude Sonnet 5.5 dans Agent Arena le placent troisième, mais hors de la frontière de Pareto

Claude Sonnet 5.5 a fait son entrée dans Agent Arena à la troisième place avec un score d’amélioration nette de 12,5 %, malgré son absence de la frontière de Pareto en matière de rapport coût-efficacité. Ce résultat place les modèles d’Anthropic aux trois premières positions. Il crée également une comparaison embarrassante au sein même de la gamme d’Anthropic.

L’instantané publié au lancement par Arena montrait que le coût médian par tâche de Sonnet était environ 73 % plus élevé que celui de Claude Opus 5.5, classé deuxième. Opus a également obtenu le meilleur score global. Cette combinaison signifie que Sonnet n’a apporté ni le meilleur résultat ni le coût le plus faible dans cette configuration précise.

Le résultat de Claude Sonnet 5.5 dans Agent Arena raconte donc deux histoires. Anthropic a conçu un autre modèle d’agent très compétitif, mais sa configuration Max n’offre pas l’avantage de valeur évident que les acheteurs pourraient attendre de Sonnet. Le véritable affrontement oppose Sonnet 5.5 Max à Opus 5.5 High, et non Anthropic à un autre fournisseur de modèles.

Cette distinction importe, car Anthropic présente Sonnet comme le complément plus rapide et moins coûteux d’Opus. L’évaluation comportementale en direct d’Arena mesure autre chose que les tarifs par token ou qu’un benchmark contrôlé en laboratoire. Elle mesure le comportement de sessions d’agent complètes, notamment leur durée, l’usage des outils, les corrections et les résultats produits.

Les résultats de Claude Sonnet 5.5 dans Agent Arena placent Anthropic aux commandes

Les débuts de Sonnet à la troisième place offrent à Anthropic un triplé en tête d’Agent Arena, mais le rang seul masque le compromis interne.

Arena a annoncé que Claude Sonnet 5.5 Max avait débuté avec un score d’amélioration nette d’environ 12,5 %. L’amélioration nette estime dans quelle mesure un modèle sélectionné modifie plusieurs signaux relatifs aux résultats des utilisateurs par rapport à la distribution de référence d’Arena.

Le modèle suivait Claude Fable 5.1 Max et Claude Opus 5.5 High au classement général. La page en direct d’Arena affichait plus de deux millions de sessions d’agent réparties sur des dizaines de modèles lorsque le résultat est apparu.

Sonnet 5.5 a également enregistré une amélioration de 8,1 points de pourcentage par rapport à Sonnet 5 High dans l’annonce d’Arena. L’ancien modèle se situait nettement plus bas au classement général. Ce gain générationnel est significatif, même si les deux entrées utilisent des réglages d’effort différents.

Le meilleur résultat par catégorie est venu de Chat. Selon l’instantané officiel du classement, Sonnet 5.5 s’y est classé premier avec un score d’amélioration nette de 15,6 %. Fable 5.1 et Opus 5.5 suivaient dans cette catégorie.

Son profil ne se limitait pas aux tâches conversationnelles. Le modèle était également en tête du signal de récupération bash d’Arena autour de la période de ses débuts. La récupération bash mesure l’efficacité avec laquelle un agent se rétablit après l’échec d’une commande.

Cette capacité est importante dans les flux de travail de programmation, de recherche et de gestion documentaire. Les agents réels rencontrent fréquemment des fichiers manquants, des paquets indisponibles, des commandes invalides ou des outils renvoyant des résultats inattendus. Un modèle qui reconnaît l’échec et s’adapte peut préserver un flux de travail par ailleurs utile.

Sonnet a également affiché un faible taux d’hallucinations d’outils. Dans ce contexte, une hallucination d’outil consiste à tenter d’appeler un outil que l’agent ne possède pas réellement. Même des erreurs peu fréquentes peuvent interrompre des flux de travail automatisés ou dérouter les utilisateurs.

Le classement agrégé combine plusieurs signaux de ce type, au lieu de mesurer un unique critère de réussite. Un modèle peut exceller en récupération tout en étant moins performant ailleurs, notamment en matière de contrôlabilité ou d’achèvement confirmé des tâches.

Le classement d’Arena comptait des milliers de sessions Sonnet 5.5. Il s’agit d’un échantillon comportemental significatif, mais le modèle disposait de moins d’observations que le leader présent depuis le plus longtemps. Des intervalles de confiance restaient visibles à côté des scores publiés.

Ces intervalles empêchent une lecture simpliste de l’ordre du classement. La troisième place est le rang affiché, mais les estimations proches comportent encore une incertitude statistique. Le résultat constitue un signal initial solide, et non un verdict définitif.

Le classement est également dynamique. Les modèles reçoivent des sessions supplémentaires, le comportement des utilisateurs évolue et la méthode d’évaluation peut changer. Les chiffres publics d’Arena avaient déjà légèrement évolué après la publication du message de lancement.

Cette dérive n’invalide pas l’annonce. Elle montre pourquoi toute affirmation concernant un classement en direct nécessite une date et une configuration. « Sonnet 5.5 se classe troisième » décrit un instantané, et non une propriété immuable du modèle.

Pourquoi la frontière de Pareto exclut Sonnet 5.5

Sonnet 5.5 Max manque la frontière de Pareto parce qu’Opus 5.5 High offre un meilleur score global à un coût médian par tâche inférieur.

Une frontière de Pareto regroupe les options qui ne sont pas dominées selon les dimensions mesurées. Ici, ces dimensions sont l’amélioration nette et le coût médian par tâche.

Un modèle appartient à cette frontière si aucune entrée concurrente n’est à la fois moins coûteuse et plus efficace. Un modèle se retrouve hors de la frontière lorsqu’une autre entrée améliore une dimension sans sacrifier l’autre.

Opus 5.5 High crée précisément ce problème pour Sonnet 5.5 Max. L’annonce d’Arena plaçait Opus devant en amélioration nette tout en montrant que le coût médian par tâche de Sonnet était environ 73 % plus élevé.

Cette comparaison ne signifie pas qu’Opus coûtera toujours moins cher. Elle signifie qu’Opus a produit un meilleur résultat en termes de rapport coût-performance dans les sessions mesurées par Arena et avec la configuration d’effort sélectionnée.

C’est le renversement central de cet article. Anthropic décrit Sonnet 5.5 comme un complément plus rapide et moins coûteux à Opus 5.5. Les données observées par Arena sur l’économie des tâches ont inversé cette relation pour les deux entrées du classement.

Les configurations comptent. Sonnet fonctionnait avec l’effort Max, tandis qu’Opus fonctionnait avec l’effort High. Les réglages d’effort déterminent la quantité de calcul et de raisonnement qu’un modèle applique avant d’achever une tâche.

Un effort accru peut améliorer les résultats difficiles, mais il peut aussi allonger les réponses et augmenter la consommation de tokens. Les chiffres d’Arena au niveau des tâches intègrent les conséquences de ces choix.

La propre annonce de Sonnet 5.5 d’Anthropic souligne un point connexe. L’entreprise affirme que Sonnet complète le plus efficacement Opus à des niveaux d’effort plus faibles, où les coûts par tâche diminuent.

Cette précision aide à réconcilier les deux récits. Sonnet peut afficher des tarifs publiés par token inférieurs tout en générant une tâche achevée plus coûteuse avec l’effort Max. Le prix par token et le coût par tâche sont liés, mais ne sont pas interchangeables.

Une tâche impliquant un raisonnement long, des appels d’outils répétés ou une production étendue peut coûter davantage, même si chaque token est facturé à un tarif inférieur. Les flux de travail d’agents amplifient cette différence, car le modèle choisit la quantité de travail à effectuer.

Arena a indiqué que Sonnet 5.5 Max générait bien davantage de tokens de sortie médians par tâche qu’Opus 5.5 High. Cet écart fournit un mécanisme plausible expliquant le coût plus élevé par tâche.

Il ne démontre pas un gaspillage. Une réponse plus longue peut contenir un travail plus complet, des artefacts plus riches ou une élaboration inutile. Le classement agrégé ne peut pas révéler quelle explication s’applique à chaque session.

La frontière de Pareto répond également à une question restreinte. Elle identifie des choix efficaces au sein des données observées par Arena, et non le meilleur modèle universel pour chaque organisation.

La latence, les contrôles de sécurité, la disponibilité du déploiement, la longueur du contexte et le style de sortie peuvent influer sur une décision de production. Aucun de ces facteurs ne disparaît parce qu’un point se situe hors d’une frontière à deux dimensions.

Les acheteurs ne devraient toutefois pas ignorer la domination. Lorsqu’une configuration obtient un score plus élevé et coûte moins cher dans le même environnement d’évaluation, la charge de la justification se déplace vers l’option dominée.

Sonnet 5.5 Max a besoin d’un avantage spécifique à la charge de travail pour justifier son choix face à Opus 5.5 High. Son avance en Chat, sa rapidité, son style de sortie ou son comportement de récupération pourraient offrir cet avantage. Le classement global seul ne le fait pas.

La méthode d’Agent Arena change ce que signifie « meilleur »

Agent Arena mesure le comportement dans des flux de travail réels ; ses scores reflètent donc conjointement les choix des modèles, les réactions des utilisateurs, les outils et la dynamique des sessions.

Les benchmarks traditionnels présentent généralement un ensemble fixe de questions ou de tâches. Les chercheurs comparent ensuite les réponses à des solutions prédéterminées, à des jugements d’experts ou à des tests automatisés.

L’évaluation des agents d’Arena adopte une approche différente. Sa méthodologie d’évaluation tire des signaux de sessions réelles en Agent Mode plutôt que d’un ensemble de tests sélectionné.

Ces sessions peuvent s’étendre sur de nombreux tours. Les utilisateurs demandent aux modèles de créer des artefacts, de rechercher des sujets, d’écrire du code, d’analyser des fichiers et de se remettre d’échecs. Leurs actions ultérieures font partie des données d’évaluation.

Arena suit les retours explicites, notamment les signalements de réussite de tâche par les utilisateurs. La plateforme extrait aussi des signaux implicites tels que les éloges, les plaintes, les corrections, les téléchargements d’artefacts, les hallucinations d’outils et la récupération après une commande échouée.

La plateforme estime ensuite l’effet de traitement associé à chaque composant de l’agent. Arena appelle cette approche le traçage causal. Le modèle orchestrateur est un composant, tandis que les outils et les choix de harness peuvent devenir des composants supplémentaires.

Cette conception tente de séparer les effets du modèle des différences dans le trafic reçu par chaque modèle. Elle est plus ambitieuse qu’une simple moyenne de votes positifs.

Le score d’amélioration nette qui en résulte est agrégé. Arena calcule les effets pour des signaux individuels, puis les combine dans la mesure utilisée pour le classement.

Cette approche saisit des comportements que les tests statiques ne détectent pas. Un modèle peut connaître la bonne réponse tout en échouant à terminer un flux de travail. Il peut appeler un outil inexistant, ignorer une correction ou prétendre qu’un travail incomplet est terminé.

L’usage réel peut révéler ces échecs. Arena affirme que ses traces indiquent également si les utilisateurs délèguent des tâches entières, renforcent leur contrôle après une réponse initiale ou téléchargent les artefacts produits.

La présentation d’Agent Mode qui l’accompagne décrit la programmation comme la plus grande catégorie de tâches dans la répartition initiale de sa charge de travail. La recherche et la planification représentaient également des parts substantielles.

Cette répartition aide à expliquer pourquoi la récupération bash et la fiabilité des outils influencent les classements. Agent Arena n’évalue pas la qualité conversationnelle de manière isolée. La plateforme évalue des modèles fonctionnant dans un système doté d’outils.

Cette méthode introduit aussi des limites. Les utilisateurs d’Arena sont auto-sélectionnés, et leurs tâches ne représentent pas toutes les charges de travail d’entreprise. Les cas d’usage populaires peuvent influencer davantage l’agrégat que des cas rares mais critiques.

Les retours utilisateurs sont bruités. Un artefact téléchargé peut indiquer de la satisfaction, de la curiosité ou simplement le souhait d’inspecter le résultat. Un éloge formulé en langage naturel ne signifie pas toujours que le travail sous-jacent est correct.

Les ajustements causaux contribuent à corriger l’attribution inégale, mais ils ne peuvent pas transformer des traces observationnelles en un test contrôlé de chaque capacité. La méthodologie d’Arena devrait compléter les benchmarks reproductibles, et non les remplacer.

Le harness compte également. Les descriptions d’outils, les prompts système, le comportement du sandbox, les limites de temps et la conception de l’interface peuvent façonner les résultats. Un agent de production doté de composants différents peut se comporter différemment de son équivalent dans Arena.

C’est pourquoi le résultat de Claude Sonnet 5.5 dans Agent Arena doit être interprété comme une observation au niveau du système. Il n’isole pas le modèle brut de l’environnement qui l’entoure.

Cette distinction est particulièrement importante lorsqu’on compare Arena aux évaluations d’Anthropic. Anthropic publie des scores de benchmarks fixes avec des réglages de modèle documentés. Arena observe un travail ouvert créé par ses utilisateurs.

Les deux répondent à des questions utiles. L’une demande si un modèle peut résoudre une évaluation définie. L’autre demande comment un agent se comporte lorsque des personnes lui confient du travail réel via une plateforme spécifique.

Le véritable affrontement oppose Sonnet Max à Opus High

Le concurrent le plus redoutable d’Anthropic dans ce résultat est Anthropic lui-même, car Opus remet en question le rôle d’efficacité attendu de Sonnet.

La famille Claude offre traditionnellement aux acheteurs une hiérarchie reconnaissable. Opus cible les travaux les plus exigeants, Sonnet équilibre performances et coût d’exploitation, tandis que Haiku répond aux cas d’usage à plus fort volume.

Anthropic reprend ce positionnement dans ses documents relatifs à Sonnet 5.5. L’entreprise présente le modèle comme adapté aux tâches quotidiennes bien définies, aux corrections de bugs, aux documents soignés, aux présentations et aux feuilles de calcul.

Opus 5.5 reste l’option destinée aux travaux complexes et ouverts nécessitant un jugement soutenu. Anthropic affirme que les tests internes et externes continuent de juger Opus plus performant dans ces situations.

Le classement d’Agent Arena confirme la partie capacité de cette distinction. Opus se classe globalement devant Sonnet. L’élément surprenant est la relation observée entre coût et tâche.

Avec l’effort Max, Sonnet a consacré suffisamment de temps ou de tokens pour perdre son avantage d’efficacité. Le réglage de l’effort devient donc un élément de décision produit, et non un simple détail d’implémentation.

Un acheteur qui comparerait les noms des modèles sans examiner leurs configurations passerait à côté de cette nuance. « Sonnet contre Opus » est une formulation trop large. La vraie question est de savoir quel modèle, niveau d’effort, prompt, ensemble d’outils et règle d’arrêt répond le mieux à une charge de travail donnée.

Anthropic expose des contrôles d’effort afin de permettre aux développeurs d’équilibrer qualité, vitesse et consommation. Sa documentation des modèles décrit également une grande fenêtre de contexte et une capacité de sortie substantielle.

Ces capacités rendent possibles des flux de travail longs. Elles ne garantissent pas qu’un raisonnement plus long produise des résultats proportionnellement meilleurs.

Un agent de programmation peut tirer parti d’étapes de révision supplémentaires lorsqu’il modifie un dépôt complexe. Le même comportement peut devenir une surcharge inutile lorsqu’il corrige un petit défaut clairement délimité.

Un agent de recherche peut nécessiter plusieurs recherches et vérifications de sources pour une affirmation contestée. Il ne devrait pas appliquer le même processus à une simple vérification factuelle.

Les organisations ont donc besoin d’un routage propre à chaque charge de travail. Les tâches courantes peuvent commencer avec un effort plus faible, tandis que les tâches incertaines ou importantes peuvent être orientées vers une configuration plus puissante.

Le résultat de la catégorie Chat complique utilement cette règle. Sonnet a dominé Chat tout en se classant troisième au total. Les équipes axées sur le travail interactif pourraient valoriser son comportement conversationnel davantage que sa position agrégée.

La récupération Bash fournit un autre facteur de différenciation possible. Les développeurs qui exécutent des flux de travail fragiles en ligne de commande peuvent préférer un modèle qui rebondit efficacement après des commandes échouées.

Ces avantages nécessitent toutefois une validation locale. Arena ne publie pas les prompts de chaque organisation, ses outils privés, ses limites de sécurité ou ses tests d’acceptation.

Le balayage des trois premières places par Anthropic exerce également une pression sur les fournisseurs concurrents. OpenAI, Google, DeepSeek, Moonshot et d’autres laboratoires doivent rivaliser avec une famille de configurations Claude.

Ce balayage ne doit toutefois pas être interprété comme une domination durable du marché. Agent Arena évolue à mesure que de nouveaux modèles arrivent et que davantage de sessions s’accumulent.

Un concurrent moins coûteux peut remodeler la frontière de Pareto sans prendre la première place. Il lui suffit d’offrir un meilleur point d’efficacité aux acheteurs qui n’ont pas besoin du score absolument le plus élevé.

Cette dynamique importe davantage qu’un graphique de podium. Les marchés des agents récompensent les modèles qui atteignent un résultat acceptable avec un comportement prévisible et une utilisation maîtrisée des ressources.

La concurrence interne d’Anthropic peut renforcer ce marché. Opus établit une référence de haute qualité, tandis que Sonnet doit se justifier par sa vitesse, la qualité de ses interactions ou une efficacité ajustée.

Pour les acheteurs, ce résultat met en garde contre les hypothèses établies au niveau de la famille. Le positionnement produit fournit une hypothèse de départ. Les mesures sur des tâches achevées déterminent si cette hypothèse résiste au contact du travail réel.

Ce que le classement ne démontre pas

Le classement ne prouve pas que Sonnet est globalement moins économique qu’Opus, car le résultat couvre des configurations précises et des sessions utilisateurs variables.

L’incertitude la plus claire concerne l’effort. Arena a comparé Sonnet en mode Max à Opus en mode High, et non les deux modèles avec un budget de raisonnement identique.

Cette différence de configuration est légitime pour un classement en direct, car les utilisateurs rencontrent des variantes de produit réelles. Elle est moins utile pour isoler l’effet du modèle sous-jacent.

Une comparaison équitable testerait plusieurs niveaux d’effort sur le même ensemble de tâches. Elle enregistrerait la réussite des tâches, la latence, les appels d’outils, le volume d’entrée, le volume de sortie et les corrections humaines nécessaires.

Les données en direct d’Arena répondent à une autre question. Elles montrent ce qui s’est passé dans des sessions naturellement générées et attribuées via la plateforme.

La maturité de l’échantillon constitue une autre réserve. Les nouveaux modèles ont initialement moins de sessions et des intervalles d’incertitude plus larges que les entrées établies. Leur classement peut évoluer à mesure que l’usage augmente.

Les chiffres de lancement et le classement en direct ultérieur montrent déjà de modestes différences. Le coût médian par tâche est calculé sur une période glissante, de sorte qu’une évolution du mélange de charges de travail peut modifier le chiffre.

Une vague de tâches de programmation complexes pourrait accroître à la fois l’usage de tokens et le coût par tâche. Un mélange ultérieur dominé par des sessions Chat plus courtes pourrait les réduire.

La prime rapportée de 73 % doit donc être considérée comme un ratio instantané. Elle est suffisamment marquée pour expliquer l’exclusion de Pareto au lancement, mais pas suffisamment permanente pour servir à une budgétisation de long terme.

Le score lui-même est également multidimensionnel. Un agrégat unique peut masquer la force d’un modèle sur un signal et sa faiblesse sur un autre.

Les résultats de Sonnet en tête dans Chat et en récupération Bash l’illustrent. Une équipe pourrait rationnellement le sélectionner pour ces propriétés tout en acceptant un classement global inférieur.

Les taux d’hallucinations d’outils exigent une prudence similaire. De petites différences de pourcentage peuvent être significatives sur le plan statistique ou opérationnel, mais elles ne décrivent pas la gravité de chaque erreur.

Appeler le mauvais outil de recherche est gênant. Tenter une opération destructive invalide est plus grave. Un taux unique ne communique pas cette distinction.

Aucun classement public ne peut tester pleinement les conditions confidentielles d’une entreprise. Les modèles se comportent différemment avec des dépôts privés, de longs documents internes, des API propriétaires et des instructions propres à chaque organisation.

Les exigences de sécurité et de conformité ajoutent d’autres contraintes. Le rang d’un modèle ne peut pas déterminer si son parcours de déploiement satisfait aux exigences de résidence des données, de conservation ou de contrôle d’accès.

Anthropic avance également plusieurs affirmations de performance et d’efficacité fondées sur ses propres tests. Ces affirmations méritent une formulation prudente, car le fournisseur a conçu les tests et contrôlé l’environnement.

L’entreprise indique que Sonnet 5.5 nécessite généralement moins de tokens que son prédécesseur. Cette comparaison ne résout pas la question de savoir pourquoi Sonnet Max a utilisé davantage de ressources qu’Opus High dans les sessions observées par Arena.

La conclusion la plus crédible reste limitée. Sonnet 5.5 a réalisé des débuts solides, mais la configuration Max testée n’offrait pas d’avantage coût-performance par rapport à Opus 5.5 High.

Toute conclusion plus large nécessite davantage de preuves. Les affirmations selon lesquelles Sonnet serait intrinsèquement inefficace, ou Opus serait toujours le meilleur achat, dépassent ce que les données d’Arena permettent d’établir.

Trois signaux détermineront si le compromis de Sonnet tient

Les résultats à effort réduit, un écart stable de coût par tâche et les performances sur des charges de travail reproductibles détermineront si le profil de lancement de Sonnet est structurel ou temporaire.

Le premier signal concerne Sonnet 5.5 avec des réglages d’effort inférieurs. Anthropic affirme que le modèle complète le plus efficacement Opus lorsqu’il fonctionne avec moins d’effort.

Si les entrées Sonnet à effort réduit conservent une grande partie de son amélioration nette tout en réduisant la consommation par tâche, l’exclusion actuelle de Pareto paraîtra propre à la configuration. Ce résultat renforcerait le positionnement produit d’Anthropic.

Si Sonnet perd trop de performances à mesure que l’effort diminue, le résultat Max devient plus conséquent. Les acheteurs feraient face à un choix plus difficile entre le comportement le plus puissant de Sonnet et son rôle d’efficacité prévu.

Le deuxième signal concerne la relation glissante du coût médian par tâche. Arena devrait accumuler davantage de sessions pour Sonnet 5.5 comme pour Opus 5.5.

Un écart persistant, combiné au maintien du score supérieur d’Opus, renforcerait le constat de dominance. Sonnet aurait besoin de forces propres à certaines catégories pour justifier sa place.

Un resserrement ou un renversement affaiblirait l’interprétation du lancement. Cela pourrait indiquer que les premières sessions Sonnet étaient exceptionnellement longues, que le comportement des utilisateurs a changé ou que le modèle a reçu des mises à jour de réglage.

Les lecteurs devraient surveiller les intervalles de confiance en parallèle des classements affichés. Un faible changement de position importe moins lorsque les plages d’incertitude se chevauchent largement.

Le troisième signal est un test indépendant sur des charges de travail d’agents reproductibles. Les équipes ont besoin d’évaluations qui rejouent les mêmes tâches de programmation, de recherche et de documentation sur les deux modèles.

Ces tests devraient évaluer les artefacts finaux, et non seulement les réponses. Ils devraient également enregistrer les corrections, la récupération après échec, le délai d’achèvement et la consommation de ressources.

Un agent qui termine une tâche dès la première tentative peut être moins coûteux qu’un autre aux taux de tokens inférieurs qui exige trois corrections. Le temps de revue humaine doit entrer dans le même calcul.

Les organisations devraient constituer un ensemble de tâches représentatif à partir de leurs propres flux de travail. La suppression des données privées peut rendre ces tâches sûres pour une évaluation répétée.

Les dossiers d’évaluation nécessitent également du contexte. Une base de connaissances consultable peut conserver les prompts, les réglages des modèles, les fichiers sources, les notes des réviseurs et les résultats acceptés afin de permettre des comparaisons ultérieures.

Cette pratique importe parce que les modèles et les plateformes en direct évoluent. Une décision prise à partir d’un instantané du classement d’octobre peut devenir obsolète après une mise à jour de modèle ou un changement de routage.

Les équipes devraient commencer par des projets pilotes restreints. Comparez Sonnet et Opus sur des tâches dont la réussite peut être évaluée objectivement, puis élargissez après avoir mesuré les schémas d’échec.

Pour les agents conversationnels, incluez des corrections de suivi et des demandes ambiguës. Pour les agents de programmation, incluez des commandes défaillantes, des tests incomplets et des conventions propres au dépôt.

Pour les agents de recherche, testez la qualité des citations, la sélection des sources, le traitement des contradictions et la capacité du modèle à signaler clairement les affirmations non résolues. Une réponse longue et soignée n’est pas automatiquement correcte.

Les débuts de Claude Sonnet 5.5 dans Agent Arena établissent que le modèle appartient au premier plan du marché des agents. Ils n’établissent pas que l’effort Max constitue son meilleur point de fonctionnement.

C’est désormais la décision que les acheteurs doivent tester. Sonnet conserve-t-il ses forces dans Chat et la récupération à un niveau d’effort inférieur, ou Opus demeure-t-il à la fois plus puissant et plus économique ?

La prochaine mise à jour du classement apportera une réponse. Une évaluation contrôlée fondée sur votre travail réel apportera celle qui compte.