La sortie de Claude Sonnet 5.5 affiche un score de 70,6 % sur un benchmark malgré une grille tarifaire inchangée
Anthropic a publié Claude Sonnet 5.5 avec un score annoncé de 70,6 % sur Terminal-Bench 4.0, tout en maintenant inchangés ses tarifs publiés pour les tokens Sonnet.
C’est cette combinaison qui constitue la véritable information. Anthropic ne demande pas aux développeurs de payer davantage par token pour son nouveau modèle de référence au quotidien. L’entreprise affirme également que le modèle génère des résultats plus de 30 % plus vite et utilise moins de tokens pour de nombreuses tâches.
Le lancement officiel compare ce résultat de 70,6 % aux 10,3 % de Sonnet 5. Il place également Sonnet 5.5 au-dessus du score annoncé de 66,4 % pour Opus 5.5 sur le même benchmark.
Ces chiffres font de la sortie de Claude Sonnet 5.5 bien plus qu’une simple mise à jour de modèle. Ils mettent sous pression la séparation traditionnelle entre un modèle par défaut rapide et un modèle premium réservé aux tâches difficiles.
Toutefois, ce résultat phare nécessite du contexte. Les configurations de benchmark, l’effort de raisonnement, l’architecture agentique, les mécanismes de repli et l’utilisation des tokens peuvent modifier sensiblement à la fois les scores et les coûts d’exploitation.
Les tests indépendants présentent déjà une situation plus complexe que le graphique de lancement d’Anthropic. Sonnet 5.5 semble très compétitif, mais ses meilleurs résultats ne se traduisent pas automatiquement par le déploiement de production le moins coûteux.
La sortie de Claude Sonnet 5.5 modifie le calcul du modèle par défaut
Anthropic positionne Sonnet 5.5 comme le modèle que les équipes peuvent utiliser par défaut, et non comme une alternative limitée à Opus.
Le modèle est devenu disponible le 28 septembre 2026, dans les applications et sur la plateforme développeurs d’Anthropic. Anthropic indique également qu’il est disponible via Amazon Web Services, Google Cloud et Microsoft Azure.
La sortie cible le codage bien délimité, la correction de bugs, la création de documents, les présentations, les feuilles de calcul et les flux de travail agentiques quotidiens. Anthropic continue de positionner Opus 5.5 pour les travaux ouverts nécessitant un jugement soutenu.
Cette distinction est importante, car de nombreuses charges de travail en entreprise se rapprochent davantage de la catégorie Sonnet. Une réponse de support, une revue de code, une révision de document ou une analyse structurée nécessitent rarement un raisonnement maximal à chaque demande.
Anthropic indique que Sonnet 5.5 a généré des résultats plus de 30 % plus vite que Sonnet 5. L’entreprise affirme également que le modèle peut réduire le coût total des tâches malgré des tarifs publiés par token inchangés.
Cette affirmation dépend de l’efficacité sur les tâches. Un modèle peut conserver une grille tarifaire inchangée tout en devenant moins coûteux par tâche achevée s’il utilise moins de tokens, d’outils ou de tentatives.
Anthropic a fourni plusieurs exemples de premiers clients pour étayer cet argument. Slack a signalé environ 14 % de tokens de sortie en moins dans ses évaluations hors ligne de Slackbot, sans modifier ses prompts.
Zendesk a indiqué que les tickets de support étaient traités 20 % plus vite dans ses tests. Atlassian a déclaré que ses agents Rovo pouvaient fonctionner jusqu’à 30 % plus vite qu’avec Sonnet 5.
Balyasny Asset Management a testé le modèle sur 2 441 tâches financières privées. L’entreprise a signalé une utilisation de tokens par réponse nettement inférieure à celle de Sonnet 5 pour les travaux d’analyse, d’extraction, de prévision et de recherche.
Il s’agit d’exemples de lancement sélectionnés par les entreprises, et non de comparaisons contrôlées couvrant toutes les charges de travail. Ils illustrent néanmoins ce qu’Anthropic souhaite voir les acheteurs mesurer : le travail accompli plutôt que les prix isolés des tokens.
Le changement pratique va donc au-delà d’un score de benchmark. Les équipes qui évaluent le modèle doivent comparer ensemble la latence, les taux de réussite, les tentatives, les appels d’outils et le temps de revue.
Un modèle plus rapide qui achève correctement davantage de tâches peut modifier la capacité des files d’attente et l’expérience utilisateur. Il peut aussi réduire l’effort humain consacré à la correction de travaux incomplets.
La sortie comprend un nouvel identifiant de modèle, claude-sonnet-5-5. Les développeurs migrant depuis Sonnet 5 doivent mettre à jour plus que cet identifiant dans certaines configurations.
Le guide de migration d’Anthropic documente des changements concernant les paramètres de raisonnement, la sélection forcée d’outils, les blocs de contenu et les outils d’utilisation d’ordinateur. Certains anciens modèles de requêtes renvoient des erreurs.
Par exemple, le raisonnement est exécuté par défaut lorsque les développeurs omettent le champ concerné. Les applications qui supposent que le premier bloc retourné contient toujours du texte normal peuvent donc échouer.
Le modèle remplace également le raisonnement initial désactivé par un réglage between_tools aux niveaux d’effort pris en charge. Ce comportement importe pour les applications conçues autour de réponses à faible latence ou de budgets de raisonnement prévisibles.
Ces détails de compatibilité compliquent l’idée d’une mise à niveau sans coût. Les tarifs publiés peuvent rester inchangés, mais le travail de migration et le temps d’évaluation entraînent toujours des coûts opérationnels.
C’est pourquoi les équipes devraient traiter Sonnet 5.5 comme un nouvel environnement d’exécution, et non comme un simple meilleur point de contrôle derrière le même contrat d’API.
Un score de 70,6 % sur Terminal-Bench exerce une pression au-dessus de Sonnet
La comparaison surprenante n’oppose pas Sonnet 5.5 à son prédécesseur. Elle oppose Sonnet 5.5 à la gamme premium Opus d’Anthropic.
Terminal-Bench évalue des agents travaillant via une interface en ligne de commande. Les tâches exigent que les modèles inspectent des environnements, utilisent des outils, modifient des artefacts et réalisent des objectifs en plusieurs étapes.
La version 4.0 comprend 66 tâches proposées par la communauté et examinées par les mainteneurs. Ses catégories incluent les logiciels, les sciences, l’apprentissage automatique, les opérations, le matériel, la sécurité et les médias.
La méthodologie du benchmark met l’accent sur les artefacts finaux plutôt que sur des explications convaincantes. Un agent obtient du crédit lorsque son travail réussit l’évaluation, et non lorsque sa réponse semble simplement plausible.
Anthropic rapporte un résultat de 70,6 % pour Sonnet 5.5 et de 10,3 % pour Sonnet 5. L’entreprise rapporte 66,4 % pour Opus 5.5 au niveau d’effort le plus élevé évalué pour ce modèle.
L’écart entre les deux générations de Sonnet est inhabituellement important. Il indique que quelque chose au-delà d’une amélioration incrémentale de la qualité linguistique a changé dans la pile de codage agentique d’Anthropic.
Le résultat inverse également la hiérarchie attendue des produits sur ce test précis. Un membre de gamme moins coûteux aurait dépassé le modèle premium d’Anthropic sur des travaux complexes en terminal.
Cela ne signifie pas que Sonnet 5.5 est universellement meilleur qu’Opus 5.5. Anthropic indique explicitement qu’Opus reste plus performant sur les missions complexes et ouvertes nécessitant un jugement soutenu.
D’autres évaluations publiées confirment cette nuance. Sur CursorBench 4.0, Sonnet 5.5 a obtenu 55,5 %, tandis qu’Opus 5.5 a atteint 57,8 %.
Sur GDPval-AA v2.1, qui évalue des tâches professionnelles, les scores annoncés étaient de 1 844 pour Sonnet 5.5 et de 1 846 pour Opus 5.5. Les modèles y étaient presque au même niveau.
FrontierCode a produit un autre résultat mitigé. Sonnet 5.5 a atteint 52,1 % avec un réglage d’effort, tandis qu’Opus 5.5 a obtenu 54,4 %.
Ensemble, ces résultats décrivent un renversement plus limité. Sonnet 5.5 semble particulièrement performant lorsqu’une tâche présente des objectifs clairs, des outils utilisables et des conditions d’achèvement vérifiables.
Opus conserve un avantage lorsque la réussite dépend d’un jugement ambigu, d’une planification plus large ou du maintien de la qualité tout au long d’une mission ouverte.
Pour les développeurs, cette répartition encourage le routage des modèles. Un système peut envoyer l’implémentation courante et les tâches agentiques limitées à Sonnet, tout en réservant Opus à l’architecture ou aux cas d’escalade difficiles.
Les documents de lancement d’Anthropic proposent un exemple de cette répartition. Un créateur a décrit l’utilisation d’Opus pour établir l’architecture d’un jeu, puis le recours à Sonnet 5.5 pour l’implémenter.
Cette association de modèles est plus importante qu’une simple victoire au classement. Elle suggère que le raisonnement premium et l’exécution à fort volume pourraient devenir des étapes distinctes d’un même flux de travail.
Le même schéma convient au travail documentaire et de connaissance. Un modèle premium pourrait définir un plan d’analyse, tandis que Sonnet gère l’extraction, la rédaction, les révisions et la mise en forme.
Les équipes qui construisent déjà une base de connaissances d’ingénierie peuvent tester cette structure sur la documentation des dépôts et les enregistrements de revue. Leurs propres résultats acceptés comptent davantage qu’un classement générique.
Si Sonnet 5.5 gère systématiquement l’étape d’exécution, Opus subit une pression au sein même de la famille de produits d’Anthropic. Les développeurs se demanderont pourquoi chaque tâche à l’apparence difficile nécessite le modèle premium.
Cette question devient particulièrement importante lorsque le modèle moins coûteux répond aussi plus vite. La latence détermine souvent si les utilisateurs tolèrent un agent dans une boucle de codage interactive.
Le bond sur le benchmark reflète une meilleure boucle agentique, pas seulement de meilleures réponses
Le résultat de Claude Sonnet 5.5 au benchmark suggère une utilisation plus efficace des outils, mais Anthropic n’a pas isolé une cause unique expliquant l’intégralité de cette hausse.
Les benchmarks agentiques mesurent un système combiné. Le modèle sous-jacent importe, mais les prompts, les outils, l’effort de raisonnement, la gestion du contexte, les limites de temps et le comportement de repli comptent également.
Anthropic indique que les premiers testeurs ont observé moins d’étapes et davantage d’appels d’outils regroupés. Lovable a signalé environ deux fois moins d’exécutions shell et près d’un tiers d’appels d’outils en moins dans ses évaluations internes de codage.
CodeRabbit a également indiqué que Sonnet 5.5 utilisait moins de tokens de sortie et faisait preuve d’un meilleur jugement pour des tâches de niveaux de complexité différents. L’entreprise a relevé moins de recherches web inutiles qu’avec Sonnet 5.
Ces observations offrent un mécanisme plausible pour l’amélioration sur Terminal-Bench. Un agent qui explore moins au hasard peut préserver du temps et du contexte pour les actions qui modifient l’artefact final.
L’efficacité des outils affecte également la fiabilité. Chaque commande shell, action dans le navigateur ou requête externe crée une nouvelle occasion d’échec, de latence ou de sortie mal formée.
Un modèle qui choisit un chemin valide plus court peut donc améliorer les taux d’achèvement sans produire une prose radicalement meilleure. Le travail en terminal récompense ce type de discipline.
Anthropic a ajouté cinq niveaux d’effort pour Sonnet 5.5. Ce réglage contrôle la durée pendant laquelle le modèle raisonne et vérifie son travail avant ou entre les actions.
Un effort plus élevé peut améliorer les tâches difficiles, mais il consomme également davantage de tokens et de temps. Anthropic recommande aux équipes d’évaluer plusieurs réglages plutôt que de transposer les anciennes hypothèses issues de Sonnet 5.
Cette recommandation est facile à négliger. Le meilleur résultat d’un benchmark reflète généralement une configuration délibérée, tandis que les systèmes de production utilisent souvent un réglage par défaut ou contrôlé par les coûts.
Le graphique de lancement présente le chiffre de 70,6 % dans le cadre d’évaluation d’Anthropic. Des évaluateurs indépendants peuvent obtenir des résultats différents en modifiant le harnais ou le niveau d’effort.
Artificial Analysis, par exemple, a signalé 64 % lors de sa propre exécution de Terminal-Bench 4.0. Son évaluation indépendante place Sonnet 5.5 parmi les principaux modèles, mais souligne une utilisation intensive des tokens à effort maximal.
L’organisation a constaté que Sonnet 5.5 consommait plus de tokens de sortie par tâche de l’Intelligence Index que tout autre modèle qu’elle avait mesuré. Ce résultat remet en question un discours simpliste sur l’efficacité.
Il n’y a pas de contradiction nécessaire entre ces deux constats. Sonnet 5.5 peut être efficace à des réglages inférieurs et gourmand en tokens lorsqu’il est poussé vers sa capacité maximale mesurée.
La distinction entre le tarif et la consommation totale est cruciale. Une grille tarifaire inchangée ne garantit pas une facture inchangée lorsque le modèle raisonne plus longtemps.
Anthropic affirme qu’un effort faible ou moyen peut dépasser les meilleurs scores de Sonnet 5 pour une fraction du coût par tâche accomplie dans plusieurs évaluations. Les tests indépendants suggèrent que l’effort maximal présente un profil différent.
Les acheteurs en production devraient donc évaluer une courbe, et non un seul point. La comparaison utile met en regard la réussite des tâches, la latence, les tokens, les tentatives et la revue humaine.
Une équipe de développement pourrait commencer avec un ensemble représentatif de tâches de dépôt. Ces tâches devraient inclure des corrections de bugs, des refactorisations, la création de tests, des changements de dépendances et la navigation dans du code inconnu.
Chaque exécution devrait utiliser le même environnement et les mêmes contrôles d’acceptation. Les évaluateurs devraient noter si le correctif fonctionne, reste dans le périmètre et nécessite une correction humaine.
Le test devrait également comptabiliser les appels d’outils échoués et le temps écoulé. Ces mesures révèlent si un score plus élevé se traduit réellement par une meilleure boucle de développement.
Les équipes devraient répéter l’exercice à plusieurs niveaux d’effort. Si un effort moyen accomplit la plupart des tâches courantes, l’effort maximal peut augmenter les coûts sans apporter suffisamment de valeur supplémentaire.
La meilleure configuration peut varier au sein d’un même produit. Un assistant interactif rapide nécessite des paramètres différents de ceux d’un agent de migration nocturne assorti de validations approfondies.
C’est le mécanisme central de cette sortie. Anthropic donne aux développeurs davantage de contrôle sur la quantité de calcul que Sonnet consacre aux tâches, tout en revendiquant de meilleurs résultats sur l’ensemble de cette plage.
Ce que les chiffres ne permettent pas de trancher
Le résultat phare du benchmark est crédible en tant que résultat rapporté, mais il ne suffit pas à établir la fiabilité en production ni des économies universelles à lui seul.
La première limite concerne la sensibilité à la configuration. Le score de 70,6 % d’Anthropic et celui de 64 % d’Artificial Analysis décrivent tous deux Sonnet 5.5, mais proviennent de configurations d’évaluation différentes.
La deuxième limite concerne le comportement de repli. Certains systèmes d’évaluation peuvent rediriger une requête refusée ou non prise en charge vers un autre modèle dans des conditions définies.
Artificial Analysis a observé un repli sur une faible fraction de ses tâches. Vals documente également le repli côté fournisseur comme un facteur pouvant influencer l’interprétation des classements.
Le repli n’est pas intrinsèquement inapproprié. Il peut représenter le comportement réel du produit reçu par les clients, en particulier lorsque les fournisseurs utilisent le routage pour maintenir la sécurité ou la disponibilité.
Cependant, un résultat assisté par repli répond à une question différente d’un résultat obtenu avec un modèle seul. Les acheteurs devraient savoir s’ils évaluent un modèle, une passerelle de fournisseur ou un agent géré dans son ensemble.
La troisième limite concerne la saturation des benchmarks. Un score de 70,6 % laisse une marge d’échec significative, mais il réduit aussi la capacité du benchmark à distinguer les futurs modèles.
Lorsque les principaux systèmes accomplissent la plupart des tâches, les cas limites difficiles prennent davantage d’importance. De petites modifications du prompt ou du harnais d’évaluation peuvent aussi faire évoluer les classements sans transformer l’expérience utilisateur habituelle.
Terminal-Bench reste utile parce que ses tâches exigent de véritables actions et produisent des artefacts vérifiables. Néanmoins, aucun benchmark unique ne représente chaque base de code, chaîne d’outils, politique de sécurité ou processus d’approbation.
La quatrième limite est l’utilisation totale des ressources. Artificial Analysis a constaté que la configuration à effort maximal de Sonnet 5.5 utilisait environ 193 000 tokens de sortie par tâche de son Intelligence Index.
Cette mesure ne décrit pas chaque requête. Elle montre toutefois pourquoi les équipes ne devraient pas déduire le coût d’une tâche achevée à partir du seul tarif publié par token.
À effort maximal, Artificial Analysis a placé Sonnet 5.5 en dehors de la frontière d’efficacité la plus favorable de sa comparaison. D’autres configurations proposaient des équilibres différents.
La cinquième limite concerne le comportement de sécurité. Anthropic affirme que Sonnet 5.5 est son premier modèle Sonnet lancé avec des protections cyber similaires à celles utilisées pour ses modèles les plus capables.
Les requêtes cyber à plus haut risque peuvent basculer vers Sonnet 5. Le modèle comprend également des classificateurs destinés à bloquer les tentatives d’extraction de son raisonnement.
Ces protections répondent à des capacités plus puissantes, mais elles peuvent créer de nouveaux schémas de refus. Un flux de travail de sécurité légitime peut se comporter différemment après une migration.
Les protections cyber représentent donc à la fois une mesure de sécurité et une variable opérationnelle. Les équipes de sécurité ont besoin de cas d’évaluation couvrant le travail défensif autorisé.
La sixième limite concerne la sélection des partenaires de lancement. Les témoignages clients d’Anthropic fournissent des données concrètes, mais l’entreprise a choisi les exemples figurant dans son annonce.
Slack, Zendesk, Box, Lovable, Atlassian et d’autres partenaires ont testé des charges de travail importantes pour eux. Leurs résultats n’établissent pas les mêmes gains pour des applications non liées.
Un système de recherche d’informations financières, un agent de code et un flux de travail de support client imposent des exigences différentes à un modèle. Ils appliquent aussi des normes différentes concernant les erreurs acceptables.
Les équipes devraient reproduire les améliorations annoncées avec leurs propres données et évaluateurs. Un modèle qui économise des tokens mais augmente le temps de revue n’a pas amélioré le flux de travail global.
L’inverse peut aussi se produire. Un modèle qui utilise davantage de tokens peut rester économique s’il évite les échecs, réduit les nouvelles tentatives ou accomplit un travail qui exigeait auparavant une escalade.
C’est pourquoi l’interprétation la plus solide reste conditionnelle. Sonnet 5.5 semble déplacer la frontière entre capacités et coûts, surtout pour le travail agentique circonscrit.
Cette sortie n’élimine pas la nécessité d’Opus, d’évaluations personnalisées ou de revue humaine. Elle rend plus importante la décision de savoir quand utiliser chacun d’eux.
Trois signaux montreront si Sonnet 5.5 transforme le marché
Le prochain test consiste à savoir si les développeurs reproduisent les résultats d’Anthropic à des niveaux d’effort ordinaires et déplacent de vraies charges de travail loin des modèles premium.
Le premier signal est la réplication indépendante des benchmarks. Les évaluateurs devraient publier les résultats avec les paramètres d’effort, les détails du harnais, le nombre de replis, la consommation de tokens et les échecs au niveau des tâches.
Un résultat reproduit proche du score d’Anthropic renforcerait l’affirmation selon laquelle Sonnet 5.5 représente une amélioration majeure des agents. Une forte variation ferait de la configuration l’élément le plus important de l’histoire.
L’écart entre 70,6 % et 64 % montre déjà pourquoi la divulgation est importante. Les deux scores indiquent de solides performances, mais impliquent des comparaisons différentes avec les systèmes concurrents.
Le deuxième signal est le routage en production. Il faudra observer si les outils de code et les plateformes d’entreprise font de Sonnet 5.5 leur modèle par défaut pour les agents courants.
Le positionnement par défaut compte davantage que la simple disponibilité facultative. Il révèle si les fournisseurs font confiance à la latence, à la fiabilité, au comportement de refus et à l’économie des tâches achevées du modèle.
Un passage d’Opus à Sonnet pour le travail d’implémentation soutiendrait la stratégie produit d’Anthropic. Une adoption limitée suggérerait que le raisonnement premium fournit encore une fiabilité essentielle.
Les premiers témoignages suggèrent davantage un routage qu’un remplacement généralisé. CodeRabbit prévoit de migrer d’abord les revues simples et modérées, puis d’étendre ce mouvement en fonction des résultats.
Cette approche est judicieuse. Elle traite la sélection de modèle comme une politique opérationnelle plutôt que comme une préférence de marque.
Le troisième signal est le coût par tâche achevée selon les niveaux d’effort. Les acheteurs devraient rechercher des mesures incluant les tokens de sortie, les appels d’outils, les nouvelles tentatives, la latence et l’intervention des évaluateurs.
Si un effort moyen préserve l’essentiel du gain au benchmark, Sonnet 5.5 renforce son argument en tant que choix par défaut à fort volume. Si l’effort maximal est régulièrement nécessaire, l’avantage économique se resserre.
Les développeurs doivent également surveiller les erreurs de migration. Le nouveau comportement de réflexion, les règles de choix d’outils, les replis de sécurité et le traitement des blocs de contenu peuvent affecter les intégrations existantes.
La documentation d’Anthropic conseille aux équipes de relancer leurs analyses par niveau d’effort et de réétalonner les coûts. Cette instruction est plus importante que la grille tarifaire inchangée.
La sortie de Claude Sonnet 5.5 remet finalement en cause une hypothèse familière : le modèle premium est toujours le choix le plus sûr pour les travaux agentiques sérieux.
Les propres résultats d’Anthropic montrent Sonnet devant Opus sur un benchmark de terminal important. D’autres tests favorisent encore Opus, notamment lorsque le jugement soutenu compte.
Cela crée une division du travail plus nette. Sonnet 5.5 peut prendre en charge une exécution rapide et circonscrite, tandis qu’Opus reste la voie d’escalade pour les décisions ambiguës.
L’impact sur le marché dépendra de la capacité de cette division à résister au contact de vrais dépôts, documents, files de support et contrôles de sécurité.
Les équipes qui évaluent Claude Sonnet 5.5 devraient commencer par les tâches achevées, et non par des prompts isolés. Constituez un ensemble de tests fixe, exécutez plusieurs niveaux d’effort et consignez chaque nouvelle tentative.
Comparez le modèle à la fois avec Sonnet 5 et avec l’alternative premium déjà utilisée en production. Incluez le travail de migration, le temps des évaluateurs, les refus et les appels d’outils échoués.
Posez ensuite la question décisive : Claude Sonnet 5.5 accomplit-il suffisamment de travail réel, avec une fiabilité suffisante, pour devenir votre nouveau choix par défaut ?
