Le classement Niklaus Harness teste Kimi Code, Hermes, Pi, Claude Code et Codex au-delà des réputations de marque

Joël Niklaus a comparé neuf harnais d’agents de programmation à travers 28 849 essais, remettant en cause l’idée selon laquelle le choix d’un modèle suffit à trancher la question des performances. Le classement Niklaus Harness évalue le logiciel qui dirige le travail d’un modèle tout en contrôlant le modèle sous-jacent et les paramètres de raisonnement. Ses premiers résultats placent plusieurs outils reconnus dans une plage de précision similaire, les différences d’efficacité et de reproductibilité compliquant la désignation d’un vainqueur.

La comparaison inclut Kimi Code, Hermes Agent, Pi, Claude Code, Codex, OpenCode, mini-swe-agent, Qwen Code et OpenClaw. Un harnais est le logiciel qui gère les instructions, les outils et la boucle d’exécution d’un modèle d’IA. Ici, ce logiciel environnant devient la variable examinée.

La tension centrale oppose la réputation d’un produit au comportement d’une configuration précise testée. Ces résultats n’établissent pas que Claude Code ou Codex obtient universellement de meilleurs résultats avec son modèle par défaut. Ils examinent ce qui se produit lorsque différents harnais utilisent des modèles ouverts sélectionnés dans des conditions contrôlées, une question plus restreinte aux conséquences pratiques pour les développeurs.

Ce que le classement Niklaus Harness compare réellement

L’expérience isole le logiciel d’agent environnant au lieu de traiter chaque produit de programmation comme un ensemble indissociable.

Dans sa description de lancement, Niklaus indique que la comparaison maintient fixes le modèle, le fournisseur et l’effort de raisonnement, tout en changeant le harnais. Chaque tâche reçoit trois tentatives. L’évaluation initiale couvre GLM-5.3-Flash, DeepSeek-V4.1-Flash et Flint, avec Terminal-Bench 2.1 et DeepSWE.

Cette conception est importante, car les comparaisons de produits ordinaires modifient souvent plusieurs variables simultanément. Un développeur qui change d’assistant de programmation peut modifier à la fois le modèle, les instructions, les outils disponibles, les autorisations et le comportement d’exécution. Il devient alors difficile d’attribuer une différence de performance.

La description de lancement indique que mini-swe-agent atteint un taux moyen de résolution de 51,4 % sur les trois modèles, contre 27,3 % pour OpenClaw. Niklaus précise également que quatre autres harnais sont statistiquement à égalité avec le meilleur résultat. Ces chiffres décrivent le lancement initial, et non un classement permanent.

Ses résultats spécifiques à chaque modèle compliquent cette moyenne globale. Selon Niklaus, mini-swe-agent mène sur GLM-5.3-Flash, Hermes Agent sur DeepSeek-V4.1-Flash et Kimi Code sur Flint. L’ordre dépend donc du modèle qu’un développeur envisage d’utiliser.

L’implication immédiate est limitée, mais importante. Un harnais qui fonctionne bien avec un modèle n’en extrait pas automatiquement les mêmes performances relatives avec un autre. Un score global peut aider à identifier des candidats, tout en masquant l’association qui compte pour un déploiement réel.

Terminal-Bench évalue des agents réalisant des tâches dans des environnements de terminal, où le logiciel exécute des commandes et interagit avec des fichiers. DeepSWE fournit une évaluation distincte de l’ingénierie logicielle. L’utilisation des deux élargit la comparaison, même si la combinaison des résultats ne rend pas les ensembles de tâches représentatifs de tous les flux de développement.

L’expérience doit également associer une date à ses conclusions. Lors de la vérification effectuée pour cet article, l’application en ligne affichait la version v0.1.2. Sa description actuelle évoque la vérification de fournisseurs équivalents, au lieu de simplement répéter la formulation du lancement initial sur les fournisseurs fixes.

Cette distinction mérite attention, car un benchmark peut évoluer après sa première annonce. De nouvelles versions de harnais, des essais supplémentaires ou des contrôles révisés peuvent changer le sens d’une capture d’écran. Les chiffres de lancement restent des éléments probants concernant la configuration de lancement, même lorsque le tableau actuel présente un ordre différent.

Pour les lecteurs découvrant la discussion Reddit d’origine, la correction essentielle concerne donc le périmètre. Il s’agit d’une comparaison de combinaisons sélectionnées de harnais et de modèles. Ce n’est pas un test exhaustif de chaque fonctionnalité, expérience d’abonnement ou configuration par défaut associée aux noms de produits répertoriés.

Les fournisseurs d’agents de programmation subissent une pression pour expliquer l’ensemble de la configuration

Les résultats mettent sous pression les affirmations qui attribuent entièrement les performances d’un agent à son modèle sous-jacent.

Pour les développeurs de harnais, la comparaison rend les choix d’implémentation plus visibles. Les instructions, les interfaces d’outils, le comportement de nouvelle tentative et les décisions d’arrêt façonnent tous le travail effectué par un modèle. Un modèle performant peut encore rencontrer des frictions liées au logiciel chargé de le diriger.

Pour les fournisseurs de modèles, la même expérience introduit un problème d’attribution. Un résultat décevant au sein d’un agent particulier n’identifie pas le modèle comme unique cause. Inversement, un bon résultat n’établit pas que chaque application utilisant ces poids le reproduira.

Pour les acheteurs en entreprise, cela modifie ce qu’une évaluation utile doit décrire. Nommer un modèle et un assistant ne suffit pas lorsque les choix de configuration influencent les résultats. Les acheteurs ont besoin d’informations suffisantes pour comprendre la combinaison testée et reproduire le comportement pertinent pour leur travail.

Une tâche de maintenance hypothétique rend la distinction concrète. Un agent peut devoir examiner un dépôt, identifier un test défaillant, modifier une fonction et vérifier le changement. Chaque étape dépend de la manière dont le harnais expose les informations et gère la séquence d’actions.

Si l’agent s’arrête après une modification sans exécuter le test pertinent, un correctif plausible reste non vérifié. S’il continue à lancer des commandes improductives, l’achèvement devient plus lent et plus coûteux en ressources. Ce sont des différences opérationnelles, même lorsque le modèle sous-jacent reste inchangé.

Cela n’établit pas quelle implémentation a causé un résultat particulier du classement. Il faut pour cela examiner les enregistrements d’exécution et tester une intervention. Cela explique pourquoi la comparaison contrôlée pose une question utile à laquelle un classement de modèles seul ne peut répondre.

Les conclusions du lancement fixent également une limite au débat familier Claude Code vs Codex. Ces noms de produits désignent souvent des expériences complètes construites autour de familles de modèles particulières. Tester leurs harnais avec des modèles ouverts sélectionnés pose une question différente de la comparaison de ces expériences complètes.

Une position basse dans cette expérience n’établirait pas que le service par défaut d’un produit fonctionne mal. Une position élevée n’établirait pas une supériorité en revue de code, en collaboration interactive ou dans des flux de travail propres à une organisation. Ces affirmations nécessitent des évaluations qui mesurent directement ces activités.

Le résultat du benchmark Kimi Code présente la même limite. Son avance rapportée avec Flint justifie d’étudier cette association dans les conditions testées. Elle n’établit pas une avance générale sur des modèles ou des dépôts sans rapport.

Pour les fournisseurs, la réponse constructive consiste à publier les configurations et à expliquer les changements qui influencent les résultats. Les acheteurs peuvent alors distinguer une mise à niveau de modèle d’une amélioration du harnais. Cela rend les affirmations de performance plus faciles à évaluer et les échecs plus faciles à examiner.

La pression est particulièrement pertinente pour les équipes qui exploitent des modèles ouverts via des logiciels d’agents interchangeables. Leur décision d’achat inclut la couche d’exécution. Elles ont besoin d’éléments probants sur la contribution de cette couche, plutôt que de s’appuyer entièrement sur un nom de produit connu.

Une précision similaire peut masquer des comportements opérationnels différents

Un résultat de précision proche laisse place à des différences significatives d’utilisation des ressources, de latence et de régularité.

Le tableau actuel distingue plusieurs mesures au lieu de présenter la précision comme une réponse complète. Sa méthode d’évaluation décrit une mesure externe de l’utilisation du modèle et distingue le temps de traitement du modèle du temps consacré à l’exécution de l’agent. Ces distinctions aident à expliquer pourquoi des taux de résolution similaires peuvent produire des expériences opérationnelles différentes.

Le tableau représente également la précision par rapport au coût et identifie une frontière de Pareto, l’ensemble des options qu’aucun concurrent ne surpasse sur les deux mesures affichées. Cela permet aux lecteurs d’examiner des avantages concurrents sans supposer que la plus grande précision est nécessairement toujours préférable.

Cette approche importe lorsqu’une organisation dispose d’une charge de travail fixe et de ressources limitées. Un léger avantage de précision peut avoir de la valeur pour une tâche difficile nécessitant une supervision minimale. Le même avantage peut être moins attrayant s’il exige un temps d’exécution sensiblement plus important pour des travaux de maintenance courants.

Un résultat d’efficacité demande également une interprétation. Des dépenses moindres ne signifient pas nécessairement qu’un agent raisonne plus efficacement. Elles peuvent refléter moins de tentatives, un arrêt plus précoce, des sorties plus courtes ou un schéma différent d’utilisation des outils. L’enregistrement d’exécution aide à distinguer une retenue productive d’un échec prématuré.

De même, une exécution plus longue n’établit pas le gaspillage. Un agent peut consacrer un effort supplémentaire à vérifier un correctif ou à se remettre d’une approche échouée. La question pertinente est de savoir si ce travail supplémentaire améliore un résultat que l’équipe valorise réellement.

C’est pourquoi le signalement de l’utilisation des ressources par tentative et par résultat réussi répond à des questions différentes. Une tentative échouée bon marché reste un échec. Une tentative réussie plus exigeante peut néanmoins être le meilleur choix lorsque la reprise humaine dominerait autrement le flux de travail.

Il s’agit de considérations d’évaluation, plutôt que d’explications établies pour chaque harnais du tableau. Un graphique peut révéler un schéma qui mérite d’être étudié. Il ne peut pas, à lui seul, identifier le comportement d’instruction ou d’outil responsable de ce schéma.

Le mécanisme est simple en principe. Un agent reçoit des informations, choisit une action, observe le résultat et décide de la suite. Le harnais contrôle des éléments importants de cette boucle, notamment les outils disponibles et la manière dont leurs réponses parviennent au modèle.

Considérons un dépôt hypothétique dont la compilation échoue en raison d’un problème d’environnement. Un agent qui modifie à répétition le code de l’application peut consommer des ressources sans traiter la cause. Une autre configuration pourrait reconnaître le problème d’environnement et réorienter son enquête.

La différence concernerait l’exécution de la tâche plutôt que la connaissance brute du modèle. Établir cette explication exigerait de faire correspondre le comportement observé au résultat. Sans cette inspection, affirmer qu’un harnais particulier est « plus intelligent » dépasse les éléments disponibles.

Le classement Niklaus Harness permet donc une comparaison plus précise que ne le suggère l’étiquette d’un vainqueur unique. Les développeurs peuvent demander quelles combinaisons atteignent une précision acceptable tout en utilisant les ressources d’une manière que leur charge de travail peut supporter. La réponse peut différer entre le développement interactif et l’exploitation sans supervision.

Il modifie également la manière de lire un titre sur un benchmark Kimi Code. Une avance spécifique à un modèle est un signal utile pour une évaluation approfondie. Elle reste incomplète sans informations sur les tentatives échouées, la durée d’exécution et le comportement ayant produit le score.

Pour la même raison, les comparaisons Claude Code vs Codex doivent préserver le contexte testé. Les noms fournissent des repères, mais la configuration détermine ce que le résultat décrit réellement.

Une réussite reproductible est différente d’une réussite occasionnelle

Un agent qui résout une tâche de façon intermittente présente une proposition de déploiement différente de celle d’un agent qui la résout de manière cohérente.

Niklaus a ensuite mis en avant la fiabilité au fil des tentatives répétées. Selon son analyse de la fiabilité, mini-swe-agent a résolu en moyenne 51,4 % des tâches par tentative. Il en a résolu 68,6 % au moins une fois sur trois tentatives, mais 33,0 % à chaque tentative.

Ces mesures décrivent des questions opérationnelles différentes. La moyenne reflète les performances sur l’ensemble des tentatives. La réussite au moins une fois indique si des opportunités répétées finissent par produire une solution. La réussite à chaque fois mesure la cohérence au sein des tentatives observées.

La distinction devient importante lorsqu’une personne observe l’agent au travail. Un développeur peut examiner une tentative échouée, modifier une instruction ou décider qu’une nouvelle exécution vaut la peine. La supervision humaine peut rendre utile une réussite intermittente, même si le temps consacré à cette supervision reste une partie du flux de travail.

Un processus sans surveillance fait face à une contrainte différente. Il ne peut pas supposer qu’une autre tentative réussie existe, sauf si le système environnant exécute effectivement des alternatives et en reconnaît la qualité. Les tentatives répétées exigent une méthode de sélection, un budget d’exécution et un moyen de gérer les échecs non résolus.

Cela fait d’un score de réussite occasionnelle un mauvais substitut à une mesure de cohérence. Il peut montrer qu’une configuration accède à une solution dans certaines conditions. Il n’établit pas que cette configuration fournira cette solution de manière fiable à la demande.

Niklaus indique que cinq harnais ont résolu entre 32,0 % et 33,3 % des tâches à chaque tentative dans la comparaison citée. Il décrit ces résultats comme trop proches pour départager les concurrents. Cela justifie de résister aux affirmations précises sur un vainqueur au sein du groupe de tête.

Les chiffres de fiabilité doivent également être assortis de limites. Trois tentatives fournissent des éléments sur la répétabilité dans le cadre de cette expérience. Elles n’établissent pas un taux d’échec en production à travers des dépôts, dépendances, autorisations et instructions utilisateur changeants.

De même, un échec sur un benchmark ne se traduit pas automatiquement par une action nuisible en production. L’évaluateur mesure si la tâche satisfait à ses critères de réussite. Les conséquences opérationnelles dépendent de ce à quoi l’agent peut accéder, ainsi que des mécanismes d’approbation ou de vérification qui encadrent son travail.

Pour les responsables de l’ingénierie, l’implication consiste à séparer la capacité de la livraison fiable. Une configuration peut être suffisamment capable pour produire parfois un correctif juste tout en restant inadaptée à un flux de travail sans surveillance. Cet écart appelle une vérification supplémentaire, plutôt qu’un label marketing plus affirmé.

Une mise à jour hypothétique de dépendance illustre cette différence. Un agent pourrait mettre à jour le package avec succès et réussir les tests lors d’une exécution, puis manquer une modification de configuration associée lors d’une autre. La réussite occasionnelle démontre moins la préparation à un fonctionnement sans surveillance que ne pourrait le laisser penser le pourcentage mis en avant.

Une équipe évaluant ce flux de travail se soucierait d’une réalisation reproductible et d’une gestion claire des échecs. Elle se soucierait aussi de savoir si la modification obtenue est compréhensible pour un relecteur. Ces dimensions restent distinctes du fait que le vérificateur du benchmark accepte l’état final.

La perspective du classement fondée sur les tentatives répétées rend cette distinction visible dans la comparaison publique. Elle encourage les lecteurs à se demander ce qui se passe lorsque l’agent doit travailler à nouveau, plutôt que de traiter une trajectoire réussie comme une description complète du produit.

Les versions des benchmarks et les enregistrements publics limitent les affirmations sur le vainqueur

Les résultats publiés constituent des éléments vérifiables, mais ils restent circonscrits par les versions des benchmarks, les configurations et l’exhaustivité de la vérification.

Terminal-Bench fournit lui-même un exemple clair de l’importance des étiquettes de version. Sa révision 2.1 a corrigé des problèmes dans 28 des 89 tâches de l’édition précédente. Les mainteneurs ont signalé des changements dans les scores d’agents-modèles représentatifs après ces corrections.

Cet historique fait de la version d’un benchmark une partie intégrante de l’affirmation. Un score de Terminal-Bench 2.0 ne peut pas simplement être considéré comme interchangeable avec un score de 2.1. Les tâches et les conditions d’évaluation ont changé, même lorsque la métrique affichée conserve le même nom.

Le même principe s’applique au harnais. Un résultat appartient à la version et aux paramètres du logiciel testés. Si une mise à jour modifie les instructions, l’exécution des outils ou le comportement d’arrêt, le score antérieur décrit l’implémentation antérieure.

Cela crée un défi pour les discussions publiques qui évoluent rapidement. Un graphique peut continuer à circuler après une modification du classement, tandis que les commentaires le traitent encore comme actuel. Les lecteurs ont besoin de la configuration d’origine et de la date de mesure pour déterminer ce que l’image établit encore.

Les enregistrements publics d’exécution du projet offrent une voie pour vérifier ces détails. La disponibilité des enregistrements est un avantage en matière de transparence. Leur publication ne signifie pas que chaque résultat a déjà fait l’objet d’une reproduction indépendante ou d’une revue manuelle complète.

Une reproduction indépendante nécessiterait d’exécuter les configurations spécifiées et de vérifier si les tendances pertinentes persistent. La lecture des enregistrements peut étayer un audit des calculs rapportés ou de comportements individuels. Ces activités fournissent des types de preuves différents.

La question causale reste particulièrement exigeante. Une différence de score peut identifier une association entre une configuration et un résultat dans des conditions contrôlées. Expliquer cette différence exige d’examiner les échecs et de tester si un changement proposé les modifie.

Par exemple, un problème de délai d’expiration suspecté devrait être testé en modifiant le délai tout en préservant les autres conditions pertinentes. Un problème suspecté de perte d’information nécessite d’inspecter quelles informations ont disparu et si leur conservation améliore les résultats. Aucune de ces explications ne découle automatiquement d’un classement faible.

La familiarité avec les benchmarks introduit une autre préoccupation qui mérite d’être étudiée sans présumer d’une faute. Un système optimisé sur des tâches publiques peut s’améliorer sur cette distribution de tâches sans s’améliorer autant ailleurs. Des éléments provenant de tâches inconnues aideraient à établir dans quelle mesure le gain se transfère.

La couverture des tâches présente une limite distincte. La maintenance de dépôts comprend des conventions organisationnelles, des demandes ambiguës et des attentes de revue humaine qu’un benchmark fixe ne peut pas pleinement capturer. Un benchmark peut néanmoins rester utile tout en laissant ces questions de déploiement sans réponse.

La réponse pratique consiste à maintenir des preuves proportionnées à la décision. Un résultat public peut justifier une présélection ou un essai ciblé. Remplacer le flux de développement d’une équipe exige des éléments supplémentaires issus d’un travail ressemblant aux responsabilités réelles de cette équipe.

Conserver ensemble les configurations, les exemples d’échec et les décisions de revue facilite le réexamen de ces comparaisons. Une base de connaissances consultable peut aider à préserver cet historique d’évaluation avec les documents techniques utilisés pendant les tests.

L’écart de vérification n’efface pas la valeur de l’expérience. Il définit ce que les résultats étayent actuellement et quels travaux supplémentaires les renforceraient. C’est une lecture plus utile que d’accepter chaque rang littéralement ou de rejeter entièrement la comparaison.

Les prochains tests devraient suivre les mises à jour, la reproduction et le travail sans surveillance

Les éléments de suivi les plus solides relieront les changements de version à des améliorations reproductibles sur des travaux allant au-delà de la comparaison initiale.

Le premier signal à surveiller est la performance actualisée du harnais avec un historique de versions clair. Lorsqu’un développeur modifie le logiciel d’exécution, une nouvelle exécution comparable peut montrer si l’exactitude, l’efficacité ou la cohérence évolue. La conservation de la configuration antérieure rend cette comparaison pertinente.

Une amélioration sur des mesures répétées renforcerait l’idée que l’ingénierie du harnais affecte matériellement les résultats. Un résultat qui disparaît lors de nouvelles exécutions comparables réduirait la confiance dans le gain revendiqué. Dans les deux cas, cela fournit davantage d’informations qu’un badge de vainqueur mis à jour.

Cela offre aussi aux fournisseurs une manière constructive de répondre. Ils peuvent identifier un schéma d’échec, expliquer la modification pertinente de l’implémentation et publier des éléments sur le résultat. Les lecteurs peuvent alors évaluer une affirmation d’ingénierie concrète plutôt que d’inférer la qualité à partir de la réputation d’un produit.

Le deuxième signal est une reproduction indépendante avec des contrôles correspondants. Un évaluateur distinct devrait documenter le modèle, les conditions du fournisseur, les paramètres de raisonnement, la version des tâches et la version du harnais. Les différences doivent rester visibles au lieu d’être fondues dans un score apparemment identique.

Si les résultats indépendants préservent l’ordre général ou les tendances propres aux modèles, la confiance dans la comparaison augmente. Si les résultats divergent, cela indique des conditions qui nécessitent un examen plus approfondi. Le comportement du fournisseur, les paramètres d’exécution et les détails de mesure deviennent des questions de recherche plutôt que des explications commodes.

La reproduction n’exige pas que chaque chiffre corresponde exactement. La question pertinente est de savoir si la conclusion résiste à des mesures répétées raisonnables. Des résultats proches devraient rester proches, sauf si des preuves supplémentaires justifient de les distinguer.

Le troisième signal est la performance sur un travail inconnu avec des critères explicites de réussite sans surveillance. Cela signifie vérifier si l’agent accomplit la tâche demandée, vérifie le résultat et gère l’échec de manière appropriée. L’intervention humaine doit être enregistrée, car elle modifie le sens de « réalisation autonome ».

Des améliorations cohérentes sur ce travail renforceraient l’importance pratique des conclusions du classement. Des gains limités à des tâches de benchmark familières en réduiraient la pertinence. La distinction compte davantage pour le déploiement qu’un autre petit mouvement dans une moyenne globale.

Pour les équipes qui choisissent un logiciel aujourd’hui, les éléments soutiennent une comparaison au niveau de l’association réelle. Kimi Code, Hermes Agent, Pi, Claude Code, Codex et mini-swe-agent méritent d’être évalués dans les configurations qu’une équipe prévoit d’utiliser. Leurs seuls noms ne peuvent pas trancher le résultat.

Le classement des harnais de Niklaus offre un point de départ public à cette évaluation, avec des résultats de lancement, des tentatives répétées et des enregistrements accessibles. Sa contribution durable dépendra de la capacité de ces mesures à aider à expliquer et améliorer le comportement des agents.

Avant de modifier votre flux de travail de programmation, comparez une association présélectionnée à la configuration à laquelle vous faites déjà confiance, en utilisant un travail de maintenance représentatif. Consignez la configuration exacte, les preuves de réalisation, l’effort du relecteur et les échecs nécessitant une intervention. Incluez des tâches pour lesquelles un correctif plausible ne suffit pas sans une étape de vérification réussie. Réexaminez la comparaison après une mise à jour significative du harnais, en préservant les résultats antérieurs afin que les changements restent compréhensibles. Traitez le classement public comme un élément de preuve pour cette décision, tout en laissant votre propre flux de travail avoir le dernier mot. La question qui mérite une réponse est concrète : quelle combinaison testée fournit un travail que votre équipe peut vérifier, reproduire et accepter avec la supervision que vous pouvez réellement assurer ?