Sonnet 4.6 avec le serveur MCP de Sourcegraph devance Fable 5 : 0,698 contre 0,568

Claude Sonnet 4.6 avec le serveur MCP de Sourcegraph a obtenu 0,698 sur neuf tâches de CodeScaleBench et devance Claude Fable 5, qui a obtenu 0,568. Sonnet travaillait sans code source sur le disque et n'accédait à la base de code que par des outils de recherche. Fable 5 disposait d'un checkout local complet du dépôt et d'aucun retrieval. Le modèle économique a remporté six tâches sur neuf, et chaque point de qualité lui coûtait presque deux fois moins cher.

CodeScaleBench est le benchmark maison de Sourcegraph pour les agents de code évoluant dans de grandes bases de code multi-dépôts. La comparaison retient neuf tâches dont l'essentiel consiste à retrouver le bon code. Fable 5 est le premier modèle accessible au public de la gamme Anthropic de classe Mythos, un niveau au-dessus d'Opus. À sa sortie, il a affiché un état de l'art (state-of-the-art) sur la plupart des benchmarks publics, y compris les évaluations de code de Cursor et de Cognition.

Recherche contre lecture sur disque

Les conditions des deux configurations sont opposées.

• Sonnet 4.6 + serveur MCP de Sourcegraph. Aucun code source sur le disque. L'agent recherche dans le code, résout les symboles et suit les références entre dépôts.
• Fable 5 avec checkout local. Le dépôt entier est à portée de main, le modèle lit directement les fichiers, sans outils de retrieval.

Les chiffres finaux :

• Sonnet 4.6 avec Sourcegraph : score moyen de 0,698, victoire sur 6 tâches sur 9.
• Fable 5 avec code local : score moyen de 0,568.
• Le coût par point de qualité de Fable est presque deux fois plus élevé. Sonnet revient à environ la moitié.

Le modèle économique, doté d'un outil, fait donc mieux à la fois sur la qualité et sur le prix. Pour les équipes qui comptabilisent le coût de leurs agents, le second critère compte autant que le premier.

D'où vient exactement l'écart

L'avantage de Sonnet n'est pas réparti uniformément entre les tâches. L'essentiel vient des tâches qui exigent de retrouver comment un symbole est réellement utilisé dans plusieurs dépôts. Le traçage de vulnérabilités et le suivi des dépendances entre organisations arrivent en tête. C'est là que la lecture directe d'une copie locale apporte peu : le code recherché peut tout simplement ne pas s'y trouver, ou en être trop éloigné.

Sur les tâches simples, il n'y a presque pas de différence. Le traçage de configuration et la migration soignée sont réussis à un niveau élevé par les deux approches, avec des résultats proches. Quand le plafond est déjà atteint, il n'y a rien à gagner.

Il existe aussi un contre-exemple. Sur l'une des tâches portant sur des dépendances inter-organisations, le modèle de pointe disposant d'un checkout local complet a tout de même pris la tête. Ce détail plaide en faveur de la méthodologie : le test n'est pas calibré pour un vainqueur connu d'avance.

Sourcegraph a publié un results explorer. Pour chaque tâche, il présente côte à côte les exécutions des deux approches : prompt complet, dialogue et chaque appel d'outil. On y voit où un agent trouve le bon fichier et où l'autre n'y parvient jamais.

Les réserves à ne pas ignorer

Premièrement, il s'agit de neuf tâches, et non de l'ensemble de CodeScaleBench. L'accès à Fable 5 a été restreint quelques jours après sa sortie. La comparaison ne retient donc que les tâches dont les exécutions de Fable étaient valides et terminées avant cette échéance. L'auteur lui-même qualifie le résultat de signal précoce, et non de benchmark établi.

Deuxièmement, le benchmark appartient à l'entreprise qui vend l'outil gagnant. Cela n'annule pas la transparence des exécutions, mais une reproduction indépendante sur d'autres tâches ne serait pas superflue.

Troisièmement, le test mesure la navigation dans le code. Les tâches qui demandent un raisonnement approfondi à l'intérieur d'un seul fichier sont restées hors du champ. Sourcegraph en fait la prochaine direction de mesure, et c'est précisément là que l'avantage du retrieval pourrait disparaître.

Que vérifier en construisant un agent avec un budget limité

La conclusion pratique pour les équipes qui bâtissent des agents sur de vraies bases de code : avant de changer de modèle, mieux vaut évaluer la qualité de la recherche dans le code. Sur les tâches inter-dépôts, comme la recherche de vulnérabilités, l'analyse de dépendances ou l'évaluation de l'impact de modifications, l'association d'un modèle moins cher et d'un bon retrieval peut surpasser un modèle coûteux qui en est dépourvu.

Il vaut la peine de prendre 10–20 de vos tâches typiques et de les répartir en deux classes : « trouver où cela est utilisé » et « comprendre une portion complexe de code ». La première classe se teste avec un modèle intermédiaire et la recherche MCP, la seconde avec un modèle phare disposant du code en local. Il faut comparer le coût par unité de qualité, et pas seulement le score final. C'est sur cette métrique que Sonnet 4.6 avec Sourcegraph l'a emporté sur Fable 5.