L’Artificial Analysis Coding Agent Index place Claude en tête, mais le coût rebat les cartes

Artificial Analysis a placé Claude Sonnet 5.5 en tête avec 68 points, mais ses nouveaux résultats sur les agents de programmation révèlent une réalité bien moins favorable côté coûts.

L’Artificial Analysis Coding Agent Index place Claude Code avec Sonnet 5.5 à l’effort maximal devant Gemini 4 Argon et GPT-6.1 Sol. Pourtant, le vainqueur consomme beaucoup plus de temps, de tokens et de dépenses API par tâche que ses nouveaux concurrents les plus proches.

Cette différence modifie la décision pratique des équipes de développement. Claude domine le benchmark composite, tandis que Codex avec GPT-6.1 Sol offre des résultats presque comparables en utilisant une fraction des ressources mesurées. Gemini 4 Argon se situe entre les deux, combinant un score global solide avec un avantage notable sur les tâches logicielles de longue durée.

Le billet de benchmark original présente les trois lancements comme de nouveaux leaders. Les résultats sous-jacents confirment leur importance, mais pas l’existence d’un simple podium à trois places. D’autres configurations, dont Claude Opus 5.5, figurent également près du sommet.

Plus important encore, chaque résultat correspond à un modèle, un réglage de raisonnement et un environnement d’agent. Le classement ne teste pas uniquement une intelligence abstraite du modèle. Il teste des systèmes de programmation complets tels que Claude Code, Codex et Antigravity CLI.

Cette distinction est au cœur du sujet. Les équipes ne choisissent plus uniquement le modèle au score le plus élevé. Elles déterminent combien valent un point de benchmark supplémentaire, en temps et en calcul.

Ce qui a changé dans l’Artificial Analysis Coding Agent Index

Les derniers résultats distinguent plus clairement que les comparaisons de modèles précédentes le leadership dans les benchmarks de l’efficacité opérationnelle.

Artificial Analysis évalue les agents de programmation sur des tâches de bout en bout plutôt que sur des questions isolées de complétion de code. Son index réunit la modification de dépôts, l’utilisation du terminal et la compréhension de bases de code en un seul score.

Claude Code exécutant Sonnet 5.5 à l’effort maximal est en tête avec 68 points. Ses résultats par composante sont de 72 % sur DeepSWE v1.1, 66 % sur Terminal-Bench 4.0 et 67 % sur SWE-Atlas-QnA.

Antigravity CLI exécutant Gemini 4 Argon obtient 64 points. Il atteint 79 % sur DeepSWE, 56 % sur Terminal-Bench et 56 % sur les questions de dépôt.

Codex avec GPT-6.1 Sol à l’effort xhigh obtient 63 points. Cette configuration affiche 73 % sur DeepSWE, 55 % sur Terminal-Bench et 61 % sur SWE-Atlas-QnA.

Ces totaux ne séparent Claude et Sol que de cinq points. Toutefois, Artificial Analysis a mesuré la configuration Claude avec environ 8,7 fois plus de tokens par tâche. Son exécution a également duré près de six fois plus longtemps.

Le coût API mesuré montre un écart encore plus large. La configuration Claude à l’effort maximal coûte environ 13,6 fois plus par tâche que Sol à xhigh dans Codex.

Gemini 4 Argon se place entre ces extrêmes. Son coût mesuré représente environ 5,6 fois celui de Sol, pour un avantage d’un point dans l’index. Il consomme environ 4,3 fois plus de tokens et prend plus de deux fois plus de temps.

La comparaison du benchmark raconte donc deux histoires. Claude affiche le score composite le plus élevé, tandis que Sol offre le meilleur rapport score-coût mesuré parmi ces trois configurations.

Artificial Analysis communique également plusieurs réglages d’effort pour Sonnet 5.5. Ce détail importe, car l’effort maximal n’est pas le réglage par défaut de Claude Code.

Sonnet 5.5 à l’effort xhigh obtient 63 points, soit le même score phare que Sol. Il utilise plus de deux fois les tokens de Sol et son coût mesuré est plus de trois fois supérieur.

À l’effort high, Sonnet obtient 55 points. À l’effort medium, le réglage par défaut dans Claude Code, il en obtient 46. Ces résultats montrent à quel point le budget de raisonnement modifie le produit évalué.

Le même schéma apparaît dans les résultats de Sol. GPT-6.1 Sol à l’effort medium obtient 61 points, seulement deux de moins que sa configuration xhigh. Son coût mesuré et son temps d’exécution diminuent aussi fortement.

Le raisonnement maximal ne produit pas automatiquement le meilleur résultat. Dans l’évaluation publiée, le résultat de Sol à xhigh dépasse de trois points celui à l’effort maximal.

Ce résultat contre-intuitif rappelle que les benchmarks d’agents comportent de la variance. Davantage de temps d’inférence peut aider, mais aussi engendrer des trajectoires plus longues, des appels d’outils inutiles ou des remises en question improductives.

Le vainqueur du titre reste Claude Code avec Sonnet 5.5 à l’effort maximal. Le changement le plus conséquent est que les acheteurs peuvent désormais voir à quel point ses cinq derniers points sont coûteux.

Le benchmark mesure des systèmes, pas uniquement des modèles

Le score d’un agent de programmation reflète l’interaction entre un modèle, son environnement, ses outils et son budget de raisonnement.

La version 1.5 du Coding Agent Index utilise trois composantes pondérées à parts égales. D’après la méthodologie publiée de l’index, chacune teste une dimension différente du travail logiciel.

DeepSWE v1.1 contient 113 tâches de longue durée. Les agents doivent modifier des dépôts existants, tandis que des environnements de vérification distincts déterminent si leurs correctifs validés réussissent les tests.

Terminal-Bench 4.0 contient 66 tâches couvrant des domaines tels que l’ingénierie logicielle, le machine learning, la sécurité et l’administration système. Les agents travaillent dans des environnements en ligne de commande, puis des suites de tests évaluent leurs résultats.

SWE-Atlas-QnA contient 124 questions sur des dépôts. Ces tâches mesurent la capacité d’un agent à suivre du code inconnu et à expliquer son comportement avec précision.

Chaque tâche reçoit trois tentatives. Artificial Analysis calcule les résultats pass-at-one pour chaque composante, puis attribue aux trois composantes le même poids dans l’index composite.

Cette structure est plus large qu’un test conventionnel de génération de code. Elle récompense les agents capables d’inspecter des dépôts, de choisir des outils, d’utiliser des terminaux, de conserver le contexte et de se remettre de leurs erreurs.

Elle rend également l’environnement important. Un environnement est la couche logicielle qui relie un modèle aux fichiers, aux terminaux, aux instructions, à la gestion du contexte et à l’exécution des outils.

Claude Code, Codex et Antigravity CLI n’offrent pas des flux de travail identiques. Ils peuvent présenter le contexte différemment, encourager des schémas d’utilisation d’outils distincts ou imposer des limites différentes.

Par conséquent, le benchmark ne peut pas établir que Sonnet 5.5 est toujours un meilleur modèle de programmation que GPT-6.1 Sol. Il établit qu’une configuration testée de Claude Code a obtenu un score supérieur à une configuration testée de Codex.

La distinction apparaît dans les scores par composante. Gemini 4 Argon mène le trio sur DeepSWE avec 79 %, bien qu’il soit classé derrière Claude au total.

Sol dépasse de peu Sonnet à l’effort maximal sur DeepSWE. Claude construit son avance globale grâce à Terminal-Bench et SWE-Atlas-QnA, où ses marges sont plus importantes.

Les résultats décrivent donc des profils de capacité différents. Gemini semble le plus fort sur les modifications de dépôts de longue durée du benchmark. Claude paraît plus équilibré entre le travail en terminal et la compréhension des dépôts.

Sol reste compétitif sur les trois tout en utilisant moins de ressources mesurées. Il ne remporte aucune composante incluse face à ses deux concurrents, mais évite une faiblesse marquée.

Cet équilibre compte en usage de production. Une équipe qui maintient un grand dépôt peut accorder davantage de valeur à l’achèvement des correctifs qu’aux réponses aux questions sur le dépôt. Une autre peut avoir besoin d’un travail fiable en terminal dans des environnements variés.

Le chiffre unique de l’index aide les lecteurs à balayer le paysage. Il ne doit pas remplacer les résultats par composante lors du choix d’un outil pour une charge de travail définie.

Artificial Analysis regroupe également les données de tokens, de coûts et de temps sur la même suite de benchmarks. La télémétrie manquante est exclue de la moyenne concernée au lieu d’être traitée comme nulle.

Son calcul des coûts prend en compte les tokens d’entrée ordinaires, les entrées mises en cache, les écritures de cache, le raisonnement et les tokens de sortie lorsque les fournisseurs facturent ces catégories séparément. Il représente le coût API à l’usage par token, et non la tarification par abonnement.

Le coût rapporté exclut aussi plusieurs dépenses opérationnelles. Il ne comprend pas l’intégration d’ingénierie, la revue humaine, la préparation des environnements, les contrôles de sécurité ni les conséquences d’un correctif défectueux.

Ces exclusions n’affaiblissent pas la comparaison. Elles définissent ce à quoi elle peut répondre : la quantité d’utilisation de modèle consommée par les agents évalués dans ce test.

Elles expliquent aussi pourquoi l’exécution de benchmark la moins chère ne produira pas toujours la pull request acceptée la moins coûteuse. Un résultat plus faible peut entraîner des coûts supplémentaires de revue, de correction et de réexécution.

Les équipes devraient donc évaluer à la fois le coût direct d’inférence et le coût par résultat réussi. L’index publié fournit des éléments utiles, mais ne calcule pas cette mesure commerciale complète.

Claude Sonnet 5.5 remporte la performance au prix d’une forte pénalité d’efficacité

L’avance de Claude est réelle dans ce benchmark, mais l’effort maximal transforme un modeste avantage de score en un engagement considérable de ressources.

Anthropic a publié Sonnet 5.5 le 28 septembre 2026. L’entreprise le présente comme un complément plus rapide et moins coûteux à Opus 5.5 pour les tâches quotidiennes délimitées, le débogage et la création de documents.

Les détails de sortie du modèle d’Anthropic mettent en avant l’effort ajustable. Les réglages plus bas privilégient la vitesse et l’économie, tandis que les réglages plus élevés donnent au modèle davantage de temps pour raisonner et vérifier son travail.

Les résultats d’Artificial Analysis montrent les deux aspects de cette conception. Faire passer Sonnet de l’effort medium à l’effort maximal fait progresser son index de 46 à 68.

Cette amélioration de 22 points est substantielle. Elle s’accompagne d’environ 21 fois plus de tokens, de plus de dix fois le temps d’exécution et de près de 23 fois le coût API mesuré.

L’effort maximal produit également des trajectoires d’agent très longues. Artificial Analysis relève environ 266 tours par tâche et 27,7 millions de tokens au total pour la configuration en tête.

Ces chiffres ne signifient pas que chaque tâche réelle consommera les mêmes ressources. Ils montrent le comportement moyen sur une suite de benchmarks exigeante comprenant des centaines de tentatives de tâches.

Ils expliquent également comment le modèle l’emporte. La configuration la plus performante ne produit pas simplement une réponse plus intelligente avec le même budget. Elle passe beaucoup plus de temps à interagir avec son environnement.

Cette stratégie porte ses fruits dans le score composite. Claude devance Gemini de quatre points et Sol de cinq. Il affiche également les meilleurs résultats du trio sur deux des trois benchmarks par composante.

La prime devient plus difficile à justifier lorsque les réglages d’effort inférieurs de Claude entrent dans la comparaison. Sonnet à xhigh égale le score de 63 points de Sol, mais consomme davantage de tokens, de temps et de dépenses mesurées.

À l’effort high, Claude accuse huit points de retard sur Sol xhigh. Son utilisation des ressources se rapproche de celle de Sol, mais l’écart de performance devient significatif.

À l’effort medium, Claude devient beaucoup moins coûteux et plus rapide que dans sa configuration maximale. Cependant, son score se situe 17 points sous Sol xhigh et 18 points sous Gemini.

Ces résultats ne sont pas contradictoires. Anthropic permet aux utilisateurs d’acheter davantage de raisonnement au moment du test, et le benchmark montre que ce raisonnement supplémentaire peut améliorer l’achèvement des tâches.

Le compromis concerne l’échelle. Un développeur individuel peut accepter une exécution longue et coûteuse pour une migration difficile. Une entreprise qui traite des milliers de changements de routine fait face à un calcul différent.

Le meilleur réglage peut aussi varier au sein d’un même flux de travail. Une équipe peut utiliser l’effort medium pour l’exploration, high pour l’implémentation et maximal uniquement pour les échecs persistants.

Cette stratégie de routage préserverait l’accès aux capacités maximales de Claude sans appliquer son budget de ressources le plus élevé à chaque ticket. Elle exige des mesures et des règles d’escalade claires.

La victoire de Claude dans les benchmarks est donc particulièrement pertinente pour les tâches où la qualité d’exécution prime sur toutes les autres contraintes. Citons notamment les correctifs difficiles couvrant plusieurs dépôts, les migrations fragiles ou les incidents dont le coût d’échec est élevé.

Elle est moins décisive pour la maintenance à fort volume. Les mises à jour de dépendances, les petits refactorings, la génération de tests et les corrections de bugs courantes privilégient souvent une qualité acceptable à un coût prévisible.

C’est pourquoi l’Artificial Analysis Coding Agent Index ne devrait pas devenir un raccourci pour les décisions d’achat. Le résultat de 68 points représente une configuration de pointe, et non un choix par défaut automatique.

GPT-6.1 Sol et Gemini 4 Argon mettent Claude sous pression de différentes manières

Sol défie Claude sur l’efficacité, tandis qu’Argon le défie sur le travail de longue haleine dans les dépôts.

OpenAI a présenté GPT-6.1 Sol le 29 septembre, un jour après la sortie de Sonnet 5.5 par Anthropic. Google a suivi avec Gemini 4 Argon le 30 septembre.

Ce calendrier a permis à Artificial Analysis de comparer trois nouvelles configurations de pointe en quelques jours. Leurs positions dans le benchmark révèlent davantage de différenciation que ne le suggèrent leurs descriptions de lancement.

OpenAI présente Sol comme un modèle proche du niveau phare, destiné au code, à l’utilisation d’ordinateurs et au travail professionnel à moindre coût. Sa fiche modèle Sol propose cinq niveaux de raisonnement, de faible à maximum.

Dans le Coding Agent Index, xhigh est le meilleur réglage testé pour Sol. Il obtient 63 points, contre 60 pour l’effort maximum.

Ce résultat remet en cause l’idée selon laquelle le plus grand budget de raisonnement est toujours le plus sûr. Il suggère que les équipes devraient évaluer les réglages d’effort plutôt que de sélectionner par défaut le niveau le plus élevé.

Le principal atout de Sol est sa constance par unité de ressource. La configuration xhigh achève une tâche moyenne en environ 15,5 minutes et consomme 3,2 millions de tokens.

Claude à effort maximal nécessite environ 90 minutes et 27,7 millions de tokens. Gemini demande environ 34,5 minutes et 13,7 millions de tokens.

Sol affiche aussi des performances compétitives dans chaque composante. Son résultat de 73 % sur DeepSWE dépasse les 72 % de Claude, même s’il reste derrière les 79 % de Gemini.

Ses scores sur Terminal-Bench et les questions sur les dépôts restent inférieurs à ceux de Claude. Ces écarts créent le différentiel composite de cinq points.

Pour de nombreuses organisations, cet écart sera acceptable. La moindre consommation de ressources de Sol permet davantage de tentatives, un déploiement plus large ou des vérifications supplémentaires avec le même budget.

Cette comparaison ne démontre pas que Sol est universellement plus économique. Les prix des fournisseurs peuvent évoluer, les schémas de mise en cache diffèrent, et les charges de travail internes peuvent produire des distributions de tokens différentes.

Elle établit toutefois une hypothèse solide qui mérite d’être testée. Si les tâches d’une équipe ressemblent à celles du benchmark, Codex avec Sol pourrait offrir un meilleur équilibre coût-performance que Claude à effort maximal.

Gemini 4 Argon exerce une pression d’un autre type. Google a présenté Argon comme un modèle destiné au raisonnement soutenu à travers des flux de travail professionnels complexes.

L’annonce d’Argon par Google décrit des usages internes liés à la migration de code, à l’optimisation de la mémoire, à la recherche et à la cybersécurité. Ces exemples restent des affirmations de l’entreprise tant qu’ils ne sont pas reproduits indépendamment.

Le Coding Agent Index apporte des éléments tiers pour une partie de ce récit. Le résultat de 79 % d’Argon sur DeepSWE est le plus élevé parmi les trois systèmes mis en avant.

Ce résultat correspond à l’accent mis par Google sur le travail de longue durée. Il suggère qu’Argon mérite une attention particulière pour les modifications étendues de dépôts, même si Claude domine l’index global.

Le score plus faible d’Argon sur les questions liées aux dépôts réduit son résultat composite. Son score de 56 % est inférieur de cinq points à celui de Sol et de onze points à celui de Claude.

Le modèle ne bénéficie pas non plus de l’efficacité mesurée de Sol. Argon gagne un point agrégé sur Sol tout en nécessitant plus de quatre fois plus de tokens par tâche.

Cela ne rend pas cette configuration irrationnelle. Un taux d’achèvement DeepSWE plus élevé peut justifier l’usage de ressources supplémentaires pour les organisations confrontées à des travaux d’implémentation difficiles.

La question importante est l’adéquation à la charge de travail. Sol semble attrayant comme généraliste efficace, tandis qu’Argon envoie un signal plus fort pour la modification de dépôts sur de longues durées.

Claude reste le leader équilibré en matière de performances dans son réglage le plus agressif. La pression du marché vient de concurrents qui rendent différentes parties de cette avance moins précieuses.

C’est une image concurrentielle plus saine qu’un classement universel. Elle offre aux équipes d’ingénierie des options distinctes plutôt que trois marques de modèles presque interchangeables.

Elle renforce aussi l’importance de maintenir des flux de travail portables. Les équipes devraient éviter de lier leurs prompts, leurs pratiques de revue et leur préparation du contexte à un seul modèle, sauf si le bénéfice est mesurable.

Un registre consultable des exigences, décisions et modifications antérieures peut rendre ces comparaisons plus cohérentes. Les équipes peuvent utiliser une base de connaissances d’ingénierie pour préserver ce contexte entre les essais d’agents.

L’objectif n’est pas de changer de modèle chaque semaine. Il s’agit de rendre le changement et l’évaluation possibles lorsque la frontière des performances évolue.

Ce que les chiffres ne démontrent pas

Une avance de cinq points dans un benchmark ne garantit pas un meilleur code, un déploiement plus sûr ou un coût total d’ingénierie inférieur dans une organisation réelle.

Artificial Analysis publie davantage de détails méthodologiques que de nombreux opérateurs de classements. Ses tâches composantes, nombres de tentatives, méthodes de notation et définitions d’efficacité sont documentés.

Malgré cela, un benchmark reste un échantillon. Il ne peut représenter tous les langages, toutes les structures de dépôts, tous les environnements de dépendances, toutes les politiques de sécurité ou toutes les normes de revue.

L’index attribue un poids égal à ses trois composantes. Une entreprise réelle accorde rarement une valeur exactement identique aux questions sur les dépôts, aux opérations de terminal et à l’achèvement de correctifs.

Une organisation peut consacrer l’essentiel de son temps à des services TypeScript dotés de tests étendus. Une autre peut maintenir du code C embarqué, des pipelines de données ou des systèmes financiers réglementés.

Leur classement interne peut différer du classement public. Un modèle qui excelle sur DeepSWE peut tout de même rencontrer des difficultés avec des frameworks propriétaires ou du code historique mal documenté.

La notation pass-at-one compresse également d’importantes différences de qualité. Deux correctifs peuvent tous deux réussir une vérification automatisée tout en différant en maintenabilité, sécurité, lisibilité ou adéquation architecturale.

L’inverse peut également se produire. Une solution partielle utile peut échouer à une condition du vérificateur et recevoir le même résultat binaire qu’une tentative inutilisable.

SWE-Atlas-QnA introduit une autre dépendance. Artificial Analysis utilise un juge automatisé pour déterminer si les réponses relatives aux dépôts satisfont tous les critères requis.

L’évaluation automatisée permet de mener des évaluations à grande échelle. Elle peut néanmoins hériter d’ambiguïtés, de biais de modèle ou d’erreurs de notation, particulièrement pour des explications comportant plusieurs formulations valides.

Les moyennes agrégées du benchmark masquent aussi la dispersion. Le coût moyen ne révèle pas si la plupart des tâches sont prévisibles alors qu’un petit groupe génère des trajectoires extrêmement longues.

Cette variance compte pour la budgétisation. Un service peut tolérer une moyenne modérée tout en subissant des exécutions individuelles qui consomment un nombre excessif de tokens ou occupent des environnements pendant des heures.

Le comportement des agents peut aussi évoluer après les mises à jour de produits. La sélection d’outils, la compression du contexte, la logique de nouvelle tentative et les instructions système cachées peuvent changer sans nouveau nom de modèle public.

Pour cette raison, le benchmark doit être considéré comme une mesure datée. Il ne constitue pas une propriété permanente de Claude Code, Codex, Antigravity CLI ou de leurs modèles sous-jacents.

Claude à effort maximal illustre le risque de lire un résultat de pointe comme une expérience par défaut. La configuration évaluée consomme bien davantage de ressources que le réglage moyen par défaut de Claude Code.

L’index compare également les dépenses API facturées au token. Les limites d’abonnement, les tarifs d’entreprise négociés, le traitement régional et l’infrastructure interne peuvent modifier l’économie réelle d’une équipe.

Les coûts humains sont également absents. Un agent plus lent peut être acceptable s’il travaille de manière asynchrone. Un agent plus rapide peut avoir plus de valeur lorsqu’un développeur attend un retour.

La charge de revue est une autre variable non résolue. Un correctif bon marché qui nécessite une inspection approfondie peut coûter davantage au total qu’un correctif coûteux accepté après une courte revue.

La sécurité exige une prudence similaire. Aucun des scores mis en avant ne démontre à lui seul qu’un agent respecte le principe du moindre privilège, résiste à des instructions malveillantes dans un dépôt ou évite de divulguer du contexte sensible.

Google a limité la disponibilité initiale d’Argon tout en menant un travail de sécurité par étapes. Ce déploiement signifie que les preuves de son utilisation publique pourraient rester plus limitées que ne le laisse penser l’attention accordée au benchmark.

Les affirmations des fournisseurs exigent également une attribution prudente. Anthropic, OpenAI et Google mettent chacun en avant des résultats d’évaluation favorables issus de suites et de réglages différents.

Ces résultats peuvent être exacts sans être directement comparables. Des harnais, jeux de tâches, budgets et règles de notation différents produisent souvent des leaders différents.

Le benchmark Artificial Analysis améliore la comparabilité en exécutant les configurations dans un même cadre. Il ne peut éliminer chaque différence introduite par les agents propriétaires et les interfaces de modèles.

Les responsables de l’ingénierie devraient reproduire un petit essai interne avant de standardiser un choix. Un jeu de test utile comprend des tickets terminés, des cas d’échec connus et des contraintes représentatives de dépôt.

Les réviseurs devraient évaluer la correction, les modifications inutiles, la sécurité, la couverture de tests, la qualité des explications et le temps jusqu’à l’acceptation. Les dépenses en tokens devraient être enregistrées à côté de ces résultats.

La métrique obtenue devrait être le travail accepté par dollar ou le travail accepté par heure d’ingénieur. Un score composite public peut guider la sélection des candidats, mais il ne peut remplacer cette mesure.

Trois signaux détermineront si l’avance de Claude compte

La prochaine phase sera déterminée par les performances avec les réglages par défaut, l’économie des modifications acceptées et la stabilité des benchmarks à travers les mises à jour.

Le premier signal concerne les performances avec des réglages d’effort pratiques. Les configurations maximales attirent les titres, mais les réglages par défaut façonnent la plupart des usages quotidiens.

Sonnet 5.5 à effort moyen obtient un score bien inférieur à son résultat maximal. Sol ne perd que deux points lorsqu’il passe de xhigh à moyen dans les données publiées.

Si Anthropic réduit cet écart entre les réglages par défaut, le plafond de 68 points de Claude deviendra plus pertinent pour les équipes ordinaires. Si l’écart persiste, l’argument de l’efficacité de Sol se renforcera.

Le deuxième signal est le coût par modification acceptée. Les benchmarks publics mesurent actuellement les dépenses API par tâche, et non le parcours complet allant de la demande au code fusionné.

Les équipes devraient surveiller si les fournisseurs ou des évaluateurs indépendants publient des résultats ajustés en fonction de la revue. Ceux-ci devraient inclure les nouvelles exécutions, le temps de correction humaine et les régressions découvertes après vérification.

Le surcoût de Claude est plus facile à justifier si ses correctifs nécessitent moins de revue. L’avantage de Sol devient plus fort si son inférence moins coûteuse ne crée pas de travail de correction supplémentaire.

Argon pourrait dominer cette mesure sur les modifications complexes de dépôts si sa force sur DeepSWE se transpose en production. Son score agrégé seul ne peut répondre à cette question.

Le troisième signal est la stabilité du classement. Les agents de code évoluent par les mises à jour de modèles, les révisions de harnais, les politiques d’outils et les améliorations de la gestion du contexte.

Un leader stable devrait conserver sa position à travers des exécutions répétées et des versions de benchmark. De grands changements après de petites mises à jour système réduiraient la confiance dans des écarts de score étroits.

Artificial Analysis publie déjà les résultats par composante, les métriques d’efficacité et les révisions méthodologiques. Les futures réexécutions montreront si l’écart de cinq points représente une séparation durable ou des effets temporaires de configuration.

Les équipes de développement n’ont pas besoin d’attendre un benchmark parfait. Elles peuvent prendre dès maintenant une décision circonscrite.

Commencez par un ensemble de tâches internes représentatives. Comparez Claude à plusieurs niveaux d’effort avec Sol et Argon, là où l’accès le permet.

Maintenez cohérents les autorisations de l’agent, l’instantané du dépôt et les critères de réussite. Consignez le temps écoulé, les tokens, les échecs, le temps de revue et l’acceptation ou non de la modification finale.

N’utilisez une configuration à effort élevé que lorsque la tâche justifie cette montée en puissance. Les travaux courants devraient commencer avec le réglage le moins coûteux qui satisfait le seuil d’acceptation de l’équipe.

Refaites la comparaison après les mises à jour importantes des modèles ou du harnais d’évaluation. L’Artificial Analysis Coding Agent Index est utile précisément parce que la frontière évolue.

Pour l’instant, son message est clair. Claude Sonnet 5.5 détient le meilleur score publié parmi les trois nouvelles configurations, mais il ne domine pas toutes les définitions pratiques de la première place.

GPT-6.1 Sol présente un profil d’efficacité convaincant, tandis que Gemini 4 Argon domine le trio pour le travail de longue haleine sur un dépôt. Le bon choix dépend du résultat qu’une équipe valorise.

Votre organisation paierait-elle un important surcoût en ressources pour cinq points d’indice supplémentaires, ou financerait-elle davantage de tentatives et de vérifications avec Sol ? Testez cette question sur votre propre travail fusionné avant de choisir une configuration par défaut.