A-CODE-CLI Bench: benchmark des CLI agentiques

Les outils CLI agentiques sont des outils de codage IA qui peuvent créer et supprimer des fichiers, exécuter des commandes, planifier et réaliser le codage de l'ensemble du projet. Nous avons évalué les principaux outils sur 10 scénarios réels de développement web, en effectuant environ 600 contrôles de validation atomiques par agent et plus de 5 000 exécutions de tests automatisés au total, y compris la logique backend, les fonctionnalités frontend et la vérification de cohérence multi-exécutions.

Résultats du benchmark des CLI agentiques

Aperçu des performances des outils CLI agentiques

La justesse du backend détermine le classement ; le score combiné pondère le backend à 0.7 et le frontend à 0.3.

• Les neuf agents qui s'exécutent proprement utilisent le même Sonnet 4.6, mais le backend varie de d'Opencode 77.3 % à de Goose 55.4 %. Cet écart de 22 points provient entièrement de l'orchestration.
• Un bon backend ne garantit pas un bon classement final : Cline (4e au backend, 69.5 %) et Forge (5e, 67.2 %) se classent près du sommet pour le backend, mais sont très en retard sur le frontend ; le 52.5 % de Cline est le plus faible du panel, si bien que les deux reculent au classement combiné.
• Codex se classe 10e au backend (52.1 %) malgré un frontend parfait de 100 %. Il passe ici par un proxy pour atteindre le modèle commun, ce qui peut nuire à ses capacités ; il s'agit donc probablement d'un plancher plutôt que du véritable backend de l'agent.¹ Gemini, également exécuté via un proxy, est limité de la même manière.
• Le classement de build ne prédit pas le comportement : l'agent qui arrive en tête ici ne retient rien après la compaction, tandis qu'un agent du milieu du classement retient tout.

Vitesse, utilisation de tokens et coût par rapport au score

Nous avons évalué l'efficacité d'exécution à l'aide du temps d'exécution moyen (en secondes), de l'utilisation effective de tokens (entrée + sortie) et du coût par tâche (en USD), chacun étant comparé au score de précision combiné :

La rapidité, le faible coût ou la faible consommation de tokens d'un agent ne prédisent pas son score.

• Opencode gagne sur les trois à la fois : meilleur score combiné (81.6 %), coût le plus bas de tous les agents capables ($1,03 par tâche), parmi les plus faibles consommations de tokens et les exécutions les plus rapides. Il inverse le compromis habituel entre précision et coût.
• Le coût s'étend sur environ 40x, de Forge à $0,18 jusqu'à Junie à $7,58, sans lien avec le classement. Forge est le moins cher parce qu'il en fait le moins : son backend échoue à la création de tickets. Les $7,58 de Junie permettent d'obtenir un 74.7 % de milieu de tableau, ce qui est une borne supérieure gonflée.
• Goose paie le plus pour le moins : deuxième le plus cher à $3,23, mais le pire score propre du panel (62.5 %). Les trois premiers au score restent bon marché (Opencode $1,03, Claude Code $1,83, Grok $2,03).
• Ni l'agent le plus rapide ni le plus lent ne gagne : Kiro (439s) et Gemini (1 158s, surcoût du proxy) se classent tous deux en milieu de tableau. Les dépenses supplémentaires financent des relances et des revalidations, pas une profondeur de résolution de problèmes.
• Les chiffres de tokens reposent surtout sur la mise en cache. Codex, Claude Code, Cline, Opencode, Gemini et Grok mettent en cache 86–98 % de leur entrée, de sorte que les 4.18M tokens bruts de Claude Code se réduisent à un total effectif de 115k. Junie, Goose, Kiro, Forge et Aider ne mettent pas en cache, ils paient donc pour chaque token renvoyé ; c'est pourquoi les 2.36M de Junie sont les plus élevés du panel.
• Trois réserves sur les chiffres : pour les cinq agents sans cache, l'entrée effective correspond à tout ce qu'ils ont envoyé, il faut donc la considérer comme un plafond ; les $1,72 de Kiro sont un plancher (facturé en crédits, plus proche de $2,23) ; le 64.4 % de Cline inclut quatre tâches où il a atteint sa limite d'erreurs avant de livrer un frontend, chacune notée 0.

Vous pouvez consulter notre méthodologie ci-dessous.

Fonctionnement des outils CLI agentiques

Les outils CLI agentiques sont des agents autonomes qui opèrent dans le terminal. Si la plupart des utilisateurs les déploient pour des tâches de codage, ils peuvent exécuter n'importe quel flux de travail réalisable via des commandes shell.

Ces agents fonctionnent généralement en boucle selon trois phases :

1. Recueillir le contexte
2. Passer à l'action
3. Vérifier les résultats

Après vérification, l'agent recueille le contexte mis à jour et répète la boucle jusqu'à terminer la tâche ou atteindre une condition d'arrêt.

La boucle est influencée par deux sources :

• L'utilisateur humain, qui fournit la tâche initiale et peut interrompre l'exécution
• Le modèle, qui assure la planification, le raisonnement et la sélection des actions

Le framework d'agents fournit une structure autour du modèle. Il définit comment le modèle doit planifier, quand il doit exécuter des commandes, comment il doit valider les résultats et quels outils sont disponibles. Ces outils peuvent inclure l'exécution de shell, l'accès au système de fichiers, le contrôle du navigateur, l'utilisation de l'ordinateur, les intégrations MCP ou des « compétences » réutilisables.

Les différentes architectures d'agents imposent des stratégies de planification, des politiques de relance et des logiques de vérification différentes. Certains agents privilégient la précision et un raisonnement plus approfondi au prix d'une consommation de tokens et d'une latence plus élevées. D'autres privilégient la vitesse et un coût moindre, avec une robustesse comportementale réduite.

Intelligence du modèle vs architecture de l'agent

Les différences de performance entre les outils CLI agentiques ne proviennent pas d'une source unique. Elles émergent de deux couches : le modèle de fondation et le framework d'orchestration qui l'enveloppe.

Ce benchmark teste les agents sur le même modèle de fondation : Claude Sonnet 4.6. Toute différence de score est donc une différence d'orchestration : la manière dont le CLI recueille le contexte, le moment où il exécute les commandes, la façon dont il valide la sortie, et sa propension à relancer après un échec.

Opencode et Claude Code utilisent tous deux directement Sonnet 4.6. Opencode obtient 77.3 % au backend ; Claude Code obtient 74.9 %. Deux agents, même modèle, 2.4 points de pourcentage d'écart en justesse backend. Kiro et Opencode utilisent tous deux Sonnet 4.6. Kiro obtient 64.2 % au backend ; Opencode obtient 77.3 %. L'écart de 13 points est la contribution du CLI.

Les deux benchmarks d'observation ci-dessous vont plus loin. Ils exécutent les mêmes tests à modèle commun sur la recherche web et la compaction de contexte, où les écarts ne sont pas de 13 points mais font la différence entre trouver la bonne réponse et en inventer une mauvaise.

Ancrage de la recherche web

Nous avons demandé à chaque agent d'auditer la documentation d'un framework : quelle version a introduit une fonctionnalité, quel est son statut actuel et ce qui a changé récemment. Chaque réponse devait citer une source officielle. Nous avons exécuté la sonde deux fois, une fois sur Unity et une fois sur Next.js/React. Les faits ont été choisis de manière à ce que la bonne réponse n'existe que sur une page actuelle et publiée. Répondre à partir des données d'entraînement produit une réponse confiante mais erronée. Nous avons vérifié une seule chose : l'agent a-t-il réellement récupéré la page qu'il citait ?

Quatre agents disposent d'une recherche web intégrée. Trois d'entre eux (Codex, Gemini, Grok) ont fonctionné sur leurs modèles natifs non-Sonnet ; les huit autres, y compris Claude Code, ont fonctionné sur Sonnet 4.6.

Quatre schémas se sont dégagés.

• Recherche en direct réelle : Codex, Claude Code, Gemini et Grok récupèrent des pages à jour et détectent les changements récents. Codex a été le seul agent à atteindre le forum des développeurs, là où se trouvent les faits les plus difficiles.
• Recherche, mais atterrit sur d'anciennes pages : Cline a récupéré deux douzaines de pages de documentation réelles et a tout de même signalé une version qui avait été remplacée. Les récupérations étaient réelles ; les pages étaient périmées.
• Pas de recherche, réponses issues de l'entraînement : Aider ne navigue pas et le dit. C'est la réponse honnête.
• Sources fabriquées : Forge n'a rien récupéré qui fonctionnait, mais a cité 31 sources sur la sonde Next.js. Les pages citées n'existent pas. Sa conclusion : « chaque cellule provient d'une page réellement récupérée au cours de cette session. »

Sur la sonde Next.js, tous les autres agents capables de naviguer ont fondé presque toutes leurs citations sur des pages qu'ils avaient réellement récupérées. Forge n'en a fondé aucune. Le graphique compare, pour chaque agent, les citations fondées et les citations fabriquées : les agents honnêtes apparaissent comme des barres vertes pleines, et Forge comme une barre rouge unique. Le graphique couvre les huit agents disposant d'un journal de récupération par URL vérifiable. Grok (recherche côté serveur), Gemini (exécution tronquée) et Aider (aucune citation) figurent dans le tableau ci-dessus mais sont exclus ici.

Cline et Claude Code ont tous deux fonctionné sur Sonnet 4.6 dans ce test. Claude Code a trouvé et ouvert la page contenant la bonne réponse. Cline ne l'a pas fait. Même modèle, résultat différent.

Nous avons noté chaque réponse en fonction de son exactitude factuelle, mais ces scores dépendent d'un corrigé actuellement en cours de révision. Nous ne publions pas les tableaux de précision tant que le corrigé n'est pas finalisé.

Compaction du contexte

Lorsqu'une session s'allonge, l'agent compacte son contexte : il remplace l'historique détaillé par un court résumé et écarte les originaux. Nous avons testé si le résumé conserve ce qui compte.

Nous avons donné à chaque agent environ 112 000 tokens de documents contenant 13 faits inventés : un code PIN d'astreinte, une région cloud, un tag de build et dix autres. Inventés signifie que les valeurs sont des chaînes uniques absentes des données d'entraînement. L'agent a lu les documents et a compacté. Nous avons ensuite supprimé les fichiers source et demandé les 13 faits. Une fois les fichiers supprimés, la seule source possible est le résumé de compaction.

Quatre agents ont retenu tous les faits. Trois n'en ont retenu aucun. Les trois qui ont obtenu 0 de mémoire avaient répondu 13 sur 13 tant qu'ils pouvaient encore relire les fichiers. Ils relisaient à chaque requête. Une fois les fichiers disparus, ils ont écrit « inconnu » plutôt que de deviner.

Goose, Forge, Opencode et Kiro fonctionnent tous sur Sonnet 4.6. Kiro a retenu les 13. Les trois autres n'en ont retenu aucun. Même modèle, résultat opposé.

Opencode se classe premier au benchmark de build et ne retient rien à la compaction. Kiro se classe septième au benchmark de build et retient tout à la compaction. La performance de build et la qualité de compaction sont des propriétés indépendantes.

Quatre agents sont sortis du périmètre de ce test, chacun pour une raison précise. Cline n'a pas pu être poussé jusqu'à son seuil de compaction. Nous avons constitué un ensemble de documents de 863 000 tokens et lui avons fait lire chaque fichier, mais Cline tronque chaque sortie d'outil à environ 2 000 caractères, si bien que les documents se sont réduits à de courts aperçus. Son contexte a plafonné à 214 000 tokens, soit 21 % de sa fenêtre d'un million de tokens, et la compaction ne s'est jamais déclenchée. Nous indiquons que Cline n'est pas mesurable dans ce protocole plutôt que d'estimer un chiffre. Grok dispose d'une commande de compaction, mais il a lu nos documents par fragments au lieu de les charger intégralement, de sorte qu'il n'y a jamais eu de contexte complet à compacter. Le summariseur d'Aider compresse les tours de chat, pas le contenu des fichiers ajoutés à la session, qui est l'endroit où se trouvaient les faits. Junie n'a pas de fonctionnalité de compaction.

Comportements des agents sur la tâche 6

Nous avons évalué les agents sur 10 tâches. Voici une analyse détaillée de la tâche 6 pour montrer comment différentes architectures de CLI se comportent sous les mêmes contraintes lorsque tous fonctionnent sur le même modèle.

Tâche 6 : Système de tickets de helpdesk (Web)

La tâche 6 exigeait la construction d'un système de tickets de helpdesk full-stack avec :

• Deux rôles utilisateur (client et agent)
• Authentification basée sur JWT
• Transitions strictes du flux de statuts
• Isolation des données (404 au lieu de 403 pour l'accès inter-utilisateurs)
• Backend FastAPI
• Frontend React/Vue/Svelte + Vite
• Commandes d'exécution déterministes

Le test de fumée a validé :

• Contrôle de santé
• Authentification à deux rôles
• Opérations CRUD sur les tickets
• Assignation et réponses
• Transitions de statut
• Application des rôles
• Isolation des données
• Connexion UI et comportement après connexion

Cette tâche met à l'épreuve la gestion d'état, la justesse de l'authentification, la discipline du contrat REST et l'intégration frontend-backend. Consultez GitHub pour voir les détails de la tâche.

Sur un même modèle, le panel s'est divisé en trois groupes.

• 60 % au backend, sept agents (codex, claude-code, cline, grok, goose, junie, opencode) : six étapes échouées identiques sur les trois relances. L'authentification, le CRUD des tickets, les réponses et l'isolation des données ont réussi ; les deux échecs concernaient /tickets/{id}/assign et /tickets/{id}/status, où ils ont construit un PATCH /tickets/{id} unifié au lieu des routes distinctes de la spécification. Logique métier correcte, contrat REST erroné. Lors de l'exécution native précédente sur Gemini 3 Pro, Opencode a construit les endpoints distincts et obtenu 93.3 % ; sur Sonnet 4.6, il a choisi la conception unifiée comme les autres.
• 13.3 %, trois agents (aider, forge, gemini-cli) : l'authentification a fonctionné, mais la création de tickets elle-même a échoué, de sorte que toutes les étapes dépendantes ont cascadé.
• 24.4 %, Kiro : de l'instabilité, pas un mode d'échec unique. Il a réussi neuf étapes à la première exécution, deux à la deuxième, et à la troisième le backend n'a jamais démarré (échec du contrôle de santé). Les dix autres agents ont répété les mêmes résultats à chaque relance.
• UI dans le groupe à 60 % : claude-code et cline ont échoué à la connexion sur un bug CORS identique, le frontend a appelé le backend sur localhost:8000 depuis une origine 127.0.0.1 et le navigateur l'a bloqué, si bien que tous deux ont obtenu 75 % ; les cinq autres ont affiché et permis la connexion sans problème à 100 %.
• Le principal enseignement est la convergence : sept CLI différents sur le même modèle ont commis la même erreur de contrat REST, donc ici le modèle domine et l'orchestration a peu d'importance, l'inverse des benchmarks d'observation ci-dessous.

Codex

Installation

Installez-le globalement avec :

• npm install -g @openai/codex

Vous pouvez également l'installer globalement avec Homebrew (macOS/Linux)

• brew install –cask codex

Authentification

Après avoir configuré Codex, vous pouvez continuer avec votre compte ChatGPT ou avec votre clé OpenAI API. Aucune option de fournisseur disponible.

Rapport de tâche

Codex a construit un système fonctionnel en 454 secondes et s'est classé dans le groupe à 60 %. La logique métier était correcte ; il a manqué le contrat REST pour l'assignation et le statut, comme le reste du panel.

Comportement du backend

L'authentification, le CRUD des tickets, les réponses et l'isolation des données ont réussi. Les six échecs concernaient les étapes d'assignation et de transition de statut, qui visaient `/tickets/{id}/assign` et `/tickets/{id}/status`. Codex a fait passer les deux par un endpoint de mise à jour unifié, de sorte que ces appels ont renvoyé 404. Stable sur les trois relances.

Comportement de l'UI

Le frontend a réussi les huit étapes de validation. L'état de connexion et d'après-connexion s'est comporté correctement. 100 % UI.

Junie

Installation

Junie est disponible via JetBrains Toolbox ou en CLI autonome :

• curl -fsSL https://junie.jetbrains.com/install | bash

Authentification

Continuez avec votre compte JetBrains ou générez une JUNIE_API_KEY sur junie.jetbrains.com/cli, ou exportez votre propre clé API depuis Anthropic, OpenAI, Google ou d'autres fournisseurs pris en charge. Plusieurs options de fournisseur disponibles.

Rapport de tâche

Junie a produit un système full-stack complet en 444 secondes et obtenu 60 % au backend, dans le groupe principal. Son entrée effective sur cette tâche est la plus élevée du panel à 1.52M, une borne supérieure sans cache affectée par un bug connu de comptabilisation du cache (voir la note du tableau des résultats).

Comportement du backend

Neuf étapes sur seize ont réussi : authentification, CRUD des tickets, réponses et isolation des données. Les six échecs concernaient les étapes d'assignation et de transition de statut. Junie a géré le statut et l'assignation via un endpoint de mise à jour unifié, si bien que les routes `/tickets/{id}/assign` et `/tickets/{id}/status` de la spécification ont renvoyé 404. La logique de transition elle-même était correcte. Stable sur les trois relances.

Comportement de l'UI

Le frontend a réussi les huit étapes de validation. 100 % UI.

Kiro CLI

Installation

Pour macOS/Linux/WSL :

• curl -fsSL https://cli.kiro.dev/install | bash

Alternative pour Linux avec AppImage (option portable) :

• Download: https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.appimage

Ensuite, exécutez :

• chmod +x kiro-cli.appimage && ./kiro-cli.appimage

Authentification

Vous pouvez continuer avec votre offre Kiro-Code. Aucune option de fournisseur disponible.

Rapport de tâche

Kiro est le seul agent dont le score reflète une instabilité plutôt qu'un choix de conception unique. Son 24.4 % au backend est une moyenne sur trois relances qui ont produit trois résultats différents. Le build lui-même était solide quand il fonctionnait ; le problème est qu'il ne s'est pas exécuté deux fois de la même manière.

Comportement du backend

À la première exécution, Kiro a réussi neuf étapes sur seize, le même profil que le groupe à 60 %, en échouant uniquement sur les routes d'assignation et de statut. À la deuxième exécution, il en a réussi deux. À la troisième, le backend n'est jamais apparu et même le contrôle de santé a échoué. En moyenne, cela donne 24.4 %. C'est l'instabilité, et non la conception des endpoints, qui distingue Kiro du groupe ici.

Comportement de l'UI

Lorsque le backend était opérationnel, le frontend a réussi les huit étapes de validation. 100 % UI. C'est un changement par rapport à l'exécution précédente, où le formulaire de connexion ne s'affichait pas à cause d'une erreur 422 au montage.

Claude Code

Installation

Pour macOS/Linux/WSL, selon votre gestionnaire de paquets préféré, vous pouvez installer Claude Code avec l'une des commandes suivantes :

• curl -fsSL https://claude.ai/install.sh | bash
• npm install -g @anthropic-ai/claude-code

Authentification

Après avoir configuré Claude Code, vous pouvez continuer avec votre compte Claude. Aucune option de fournisseur disponible.

Rapport de tâche

Claude Code a obtenu 60 % au backend en 379 secondes, dans le groupe principal. C'est une amélioration marquée par rapport à l'exécution précédente, où un bug de validation JWT renvoyait 401 sur toutes les routes authentifiées et échouait à 13 étapes sur 16. Dans cette exécution, le backend a fonctionné ; la perte venait de l'UI.

Comportement du backend

L'authentification, le CRUD des tickets, les réponses et l'isolation des données ont réussi. Les six échecs concernaient les étapes d'assignation et de transition de statut, routées via un endpoint de mise à jour unifié au lieu des chemins distincts de la spécification. Stable sur les trois relances.

Comportement de l'UI

L'étape de connexion a échoué. Le frontend a appelé le backend sur localhost:8000 alors que la page était servie depuis une origine 127.0.0.1, et le navigateur a bloqué la demande de connexion en vertu de la politique CORS. Cinq étapes ont réussi, une a échoué, deux ont été bloquées. 75 % UI. Cline a échoué de la même manière.

Aider

Installation

Si python 3.8-3.13 est déjà installé, installez d'abord aider :

• python -m pip install aider-install
• aider-install

Authentification

Connectez-vous à votre compte OpenRouter et autorisez-le, ou exportez votre clé API dans votre environnement avec :

• export OPENROUTER_API_KEY=”sk-or-v1-…”

Rapport de tâche

Aider a été l'agent le plus rapide avec 236 secondes et le plus léger, avec 1.3k tokens d'entrée et 18k tokens de sortie. Il a aussi obtenu 13.3 % au backend. L'authentification a fonctionné, mais la création de tickets a échoué, et chaque étape nécessitant un ticket existant a échoué avec elle.

Comportement du backend

Deux étapes ont réussi. Le build s'est cassé à la création de tickets, de sorte que les listes de tickets client et agent, les réponses, l'assignation, les transitions de statut et les contrôles de rôle ont tous cascadé vers l'échec. Stable sur les trois relances. Il s'agit d'une classe d'échec différente de celle du groupe à 60 %, qui créait les tickets correctement et ne manquait que les routes d'assignation et de statut.

Comportement de l'UI

L'étape de connexion a échoué en raison du même problème d'origine CORS vu avec claude-code et cline. Cinq étapes ont réussi, une a échoué, deux ont été bloquées. 75 % UI.

OpenCode

Installation

Pour macOS/Linux/WSL :

• curl -fsSL https://opencode.ai/install | bash

Installez-le globalement avec :

• npm i -g opencode-ai

Pour macOS/Linux, selon votre gestionnaire de paquets préféré :

• bun add -g opencode-ai
• brew install anomalyco/tap/opencode
• paru -S opencode

Authentification

Il existe de nombreuses options de fournisseur ; sélectionnez le fournisseur souhaité et authentifiez-vous avec /connect

Rapport de tâche

Opencode est en tête du benchmark global, mais sur la tâche 6 il a obtenu 60 % au backend, dans le groupe principal, en 542 secondes. C'est la preuve la plus claire du rôle du modèle dans cet article. Lors de l'exécution native précédente sur Gemini 3 Pro Preview, Opencode a construit les endpoints distincts de la spécification et obtenu 93.3 % ici. Le même CLI sur Sonnet 4.6 a choisi l'endpoint unifié et est tombé à 60 %. L'outil n'a pas changé ; le modèle, si.

Comportement du backend

L'authentification, le CRUD des tickets, les réponses et l'isolation des données ont réussi. Les six échecs concernaient les étapes d'assignation et de transition de statut, routées via un endpoint de mise à jour unifié. Stable sur les trois relances.

Comportement de l'UI

Le frontend a réussi les huit étapes de validation. 100 % UI.

Grok Build

Installation

Pour macOS/Linux :

• curl -fsSL https://x.ai/cli/install.sh | bash

Authentification

Connectez-vous avec votre compte xAI au premier lancement, ou définissez une clé API pour une utilisation sans interface :

• export XAI_API_KEY=”xai-…”

Rapport de tâche

Grok a terminé deuxième au classement général du benchmark de build avec 75.4 % au backend. Sur la tâche 6, il a obtenu 60 % au backend en 433 secondes, dans le groupe principal. Dans cette exécution, Grok a atteint Sonnet 4.6 via OpenRouter.

Comportement du backend

Neuf étapes sur seize ont réussi : authentification, CRUD des tickets, réponses et isolation des données. Les six échecs concernaient les étapes d'assignation et de transition de statut, qui visaient /tickets/{id}/assign et /tickets/{id}/status. Grok a fait passer les deux par un endpoint de mise à jour unifié, si bien que ces appels et les contrôles de rôle qui en dépendent ont renvoyé 404. Stable sur les trois relances.

Comportement de l'UI

Le frontend a réussi les huit étapes de validation. L'état de connexion et d'après-connexion s'est comporté correctement. 100 % UI.

Forge

Installation

Pour macOS/Linux/WSL :

• curl -fsSL https://forgecode.dev/cli | sh

Authentification

Configurez vos identifiants de fournisseur de manière interactive avec :

• forge provider login

Et choisissez votre fournisseur.

Rapport de tâche

Forge a obtenu 13.3 % au backend en 844 secondes. Son nombre de tokens de sortie est le plus bas du panel avec 1.6k, ce qui indique une implémentation superficielle. Comme lors de l'exécution précédente, le build s'est cassé à la création de tickets et a cascadé.

Comportement du backend

Deux étapes ont réussi. La création de tickets a échoué, de sorte que les listes de tickets, les réponses, l'assignation, les transitions de statut et les contrôles de rôle ont tous échoué avec elle. Stable sur les trois relances, avec le même profil à 13.3 % qu'aider et gemini-cli.

Comportement de l'UI

L'étape de connexion a échoué en raison du même problème d'origine CORS vu avec claude-code, cline et aider. Cinq étapes ont réussi, une a échoué, deux ont été bloquées. 75 % UI.

Gemini CLI

Installation

Exécution instantanée :

• npx @google/gemini-cli

Ou installez-le globalement :

• npm install -g @google/gemini-cli
• brew install gemini-cli

Authentification

Option 1 (OAuth Google) : export GOOGLE_CLOUD_PROJECT=”YOUR_PROJECT_ID” puis démarrez gemini.
Option 2 (clé API) : export GEMINI_API_KEY=”YOUR_API_KEY” puis démarrez gemini.
Option 3 (Vertex IA) : export GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true.

Rapport de tâche

Gemini CLI a obtenu 13.3 % au backend en 926 secondes, l'un des deux agents les plus lents du panel. L'authentification a fonctionné, mais la création de tickets a échoué et a cascadé. Son frontend, qui avait entièrement échoué lors de l'exécution précédente à cause d'une incompatibilité entre Node 18 et Vite 7, a réussi chaque étape cette fois.

Comportement du backend

Deux étapes ont réussi. La création de tickets a échoué, donc toutes les étapes dépendantes ont échoué. Stable sur les trois relances, avec le même profil à 13.3 % qu'aider et forge.

Comportement de l'UI

Le frontend a réussi les huit étapes de validation. 100 % UI, contre 0 % lors de l'exécution précédente. Un 401 est apparu dans la console sur un appel authentifié, mais cela n'a pas bloqué le flux affiché.

Cline

Installation

Installez-le globalement avec :

• npm install -g cline

Authentification

En tapant `cline auth`, vous pouvez sélectionner votre compte Cline ou continuer avec le fournisseur de votre choix.

Rapport de tâche

Cline a obtenu 60 % au backend en 648 secondes, dans le groupe principal. C'est un grand changement par rapport à l'exécution précédente, où sa limite de huit erreurs a interrompu le build prématurément et laissé un frontend vide. Ici, il a terminé la stack complète.

Comportement du backend

L'authentification, le CRUD des tickets, les réponses et l'isolation des données ont réussi. Les six échecs concernaient les étapes d'assignation et de transition de statut, routées via un endpoint de mise à jour unifié. Stable sur les trois relances.

Comportement de l'UI

L'étape de connexion a échoué en raison du même problème d'origine CORS vu avec claude-code, sur une page 127.0.0.1 appelant un backend localhost. Cinq étapes ont réussi, une a échoué, deux ont été bloquées. 75 % UI.

Goose

Installation

Pour macOS/Linux/WSL :

• curl -fsSL https://github.com/block/goose/releases/download/stable/download_cli.sh | bash

Rapport de tâche

Goose a obtenu 60 % au backend en 553 secondes, dans le groupe principal, mais a consommé 1.06M tokens d'entrée pour y parvenir. Il a terminé la stack complète cette fois, un changement par rapport à l'exécution précédente où le répertoire frontend était resté vide.

Comportement du backend

L'authentification, le CRUD des tickets, les réponses et l'isolation des données ont réussi. Les six échecs concernaient les étapes d'assignation et de transition de statut, routées via un endpoint de mise à jour unifié. Stable sur les trois relances.

Comportement de l'UI

Le frontend a réussi les huit étapes de validation. 100 % UI, contre 0 % lors de l'exécution précédente.

Ne manquez pas nos benchmarks et analyses basées sur les données. Le bouton ouvre Google ; sélectionner AIMultiple confirme que vous souhaitez voir AIMultiple plus souvent dans les résultats de recherche Google.

Ajouter comme source préférée

Outils de codage IA

Les outils de codage IA peuvent être regroupés en trois catégories :

• CLI agentiques : outils pour les flux de développement basés sur le terminal, qui génèrent, modifient et refactorisent du code via des prompts et des interactions en ligne de commande.
  • Exemples : Aider, Junie, Opencode, Claude Code, Codex
• Éditeurs de code IA : Aussi appelés IDE agentiques, ces outils offrent une interface graphique similaire à VS Code (la plupart étant construits sur VS Code).
  • Exemples : Antigravity, Cursor, Kiro Code, Windsurf
• Builders de prompt vers application : Plateformes low-code/no-code pour créer des applications à l'aide de prompts en langage naturel et de flux visuels.
  • Exemples : Bolt, Lovable, v0.dev, Firebase Studio, Dazl

Outils de revue de code IA

À mesure que le code généré par IA se généralise, les outils de revue de code deviennent essentiels pour détecter les bugs et les vulnérabilités. Nous avons évalué les meilleurs outils sur 309 PR dans notre benchmark RevEval.

Que peuvent faire les outils CLI agentiques ?

Parmi des outils comme Codex, Junie, Kiro et Claude Code, les capacités courantes incluent :

• Travail de code de bout en bout : créer et modifier des fichiers, corriger des bugs, refactoriser du code et exécuter des tests ou des linters directement depuis le terminal.
• Flux de travail agentiques : effectuer des tâches en plusieurs étapes telles que l'enchaînement de tâches, le dépannage, la recherche et le débogage itératif.
• Gestion de Git et de projet : consulter l'historique, résoudre les fusions, gérer les branches et créer des commits ou des pull requests.
• Exécution de Command et automatisation : exécuter des commandes shell, automatiser des analyses et traduire le langage naturel en opérations CLI complexes.
• Gestion du contexte en profondeur : opérer sur des dépôts complets en tenant compte des dépendances et de la structure du projet.
• Flexibilité des modèles : prendre en charge plusieurs modèles cloud et, dans certains cas, locaux ; certains outils permettent d'utiliser votre propre clé API ou de choisir entre différentes offres.
• Accès sandboxé ou contrôlé : proposer des modes allant de la lecture seule à l'automatisation complète, souvent avec des environnements isolés pour la sécurité.

Méthodologie

A-CODE-CLI Benchmark

Nous avons évalué les agents dans une configuration d'exécution one-shot pour mesurer leur capacité autonome sans intervention humaine. Les agents ont ensuite été évalués à l'aide de tests de fumée backend et frontend pour mesurer la préparation de l'infrastructure et la justesse comportementale.

Configuration du modèle. Les 11 agents ont fonctionné sur Claude Sonnet 4.6 (non-raisonnant). Deux agents ont nécessité un proxy pour atteindre ce modèle :

• Codex (OpenAI CLI) ne peut pas cibler nativement les modèles Anthropic. Il a été routé via une passerelle LiteLLM vers OpenRouter/Anthropic, avec un shim de cache restaurant la mise en cache des prompts. Le proxy supprime les tokens de raisonnement (coût en capacités) et ajoute de la latence.
• Gemini CLI ne peut pas appeler nativement les modèles Anthropic. Il a été routé via un shim SSE et une passerelle LiteLLM. Ses appels aux modèles auxiliaires (détection de boucle, réparation d'outils malformés, compression de contexte) échouent ou renvoient un contenu invalide via le proxy, si bien qu'il a fonctionné sans ses propres filets de sécurité.

Forge a nécessité un proxy distinct pour supprimer les blocs de raisonnement étendu des réponses, que Forge active de force et qui provoquent des erreurs 400 lorsqu'ils sont renvoyés. Tous les autres agents ont utilisé directement Sonnet 4.6 via leur configuration de fournisseur natif ou OpenRouter.

Le proxy ne peut que handicaper codex et gemini-cli, jamais les gonfler. Leurs scores sont prudents.

Junie exécute en parallèle un assistant GPT-4.1-mini non désactivable à côté du modèle principal Sonnet 4.6. C'est le seul agent avec un second modèle actif pendant le build. Ses scores portent un astérisque multi-modèle.

Claude Code a fonctionné via un abonnement utilisateur (OAuth). Kiro a fonctionné avec des crédits hébergés par Kiro (adossés à Bedrock, multiplicateur 1.3x).

Aucun agent n'a eu de paramètres de température, de relance ou de raisonnement ajustés. Chacun a fonctionné avec sa configuration par défaut.

Notation. Backend : smoke test fonctionnel (adaptive_avg_step_pass_rate). Frontend : smoke test UI via Playwright. Combiné : 0.7 × backend + 0.3 × frontend (pour les agents disposant de données UI complètes). Le score backend est l'axe principal de classement. La performance frontend sature dans l'ensemble du panel.

Aider t-3 et t-4. Les deux tâches ont produit des backends qui plantaient au démarrage. Confirmé sur deux builds frais (mêmes erreurs : TypeError sur class Card en t-3, AmbiguousForeignKeysError sur User.auctions en t-4). Notés 0 avec un drapeau backend_never_ready, non exclus.

Pour la méthodologie d'évaluation, consultez : méthodologie du benchmark de codage IA

Versions des CLI (exécution du benchmark de juin 2026)

Versions relevées sur les machines VPS du benchmark. L'exécution de build a eu lieu du 5 au 8 juin 2026.

• Claude Code : 2.1.165
• Cline : 3.0.27
• Codex : 0.140.0
• Aider : 0.86.2
• Gemini CLI : 0.26.0
• Forge : 2.13.11
• Goose : 1.37.0
• Grok : 0.2.54
• Junie : 26.06.01 (build 1831.35)
• Kiro CLI : 2.6.1
• Opencode : 1.17.7

Méthodologie de l'ancrage de la recherche web

Deux sondes : un audit de migration Unity (sonde 2) et un audit de version Next.js/React (sonde 3). Chacune demandait à l'agent de rapporter la version, le statut et le calendrier pour des fonctionnalités de framework spécifiées et de citer une URL officielle par affirmation.

La notation a utilisé deux méthodes parallèles. Filtrage par réalité de terrain : une affirmation n'est comptée que si l'URL citée apparaît dans le journal de récupération réel de l'agent ET que la page récupérée contient le fait, mesuré par rapport à un corrigé vérifié. Classification comportementale : un juge LLM a lu la transcription complète de chaque agent et l'a assignée à l'une des quatre catégories comportementales. La classification comportementale est le résultat principal ; les tableaux de précision notés seront publiés après que le corrigé aura terminé son examen d'ancrage humain.

Les agents dotés d'une recherche intégrée (Codex, Gemini, Grok) ont fonctionné sur leurs modèles natifs car la tâche exige leur capacité de recherche intégrée. Les huit autres ont fonctionné sur Claude Sonnet 4.6. N=1.

Méthodologie de la compaction de contexte

Les agents ont reçu environ 112 000 tokens de documents de remplissage contenant 13 faits d'infrastructure inventés. Après que l'agent a lu les documents et compacté son contexte, nous avons supprimé les fichiers source avant de poser la moindre question. Notation : correspondance exacte avec les 13 valeurs inventées, automatisée par un script de notation avec une regex par fait. N=3.

Les agents qui ont obtenu 13/13 avec les fichiers présents et 0/13 avec les fichiers supprimés sont classés comme re-lecteurs. Les agents qui ont obtenu 13/13 avec les fichiers supprimés sont classés comme vrais conservateurs. La suppression des fichiers exclut la relecture ; les faits inventés excluent le rappel depuis les données d'entraînement.

Tous les agents, à l'exception de Codex (GPT-5.5) et de Gemini (Gemini 2.5 Pro), ont fonctionné sur Sonnet 4.6. Le modèle utilisé par chaque agent figure dans le tableau des résultats.

Pour aller plus loin

Pour ceux qui explorent l'écosystème plus large des outils de développement agentiques, voici nos derniers benchmarks :

• Benchmark MCP : une comparaison des meilleurs serveurs MCP pour l'accès web.
• Navigateurs distants : comment l'infrastructure de navigation émergente permet aux agents IA d'interagir avec le web en toute sécurité.

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{kalelioglu2026,
  author = {Kalelioğlu, Berk and Dilmegani, Cem},
  title  = {{A-CODE-CLI Bench: benchmark des CLI agentiques}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/agentic-cli}},
  note   = {AIMultiple. Consulté le 29 Juin 2026}
}

Journal des modifications

21 mises à jour

Toutes21Général18Méthodologie3

1. 202618 Juin

   Ajouté, une phrase à l'introduction, précisant que tous les agents fonctionnaient sur le même modèle.

2. 18 Juin

   La section Méthodologie a été mise à jour, offrant une explication plus détaillée de la configuration du modèle, de la notation et des versions CLI utilisées, donnant aux lecteurs une compréhension plus claire de la configuration expérimentale.

3. 18 Mar

   La méthodologie de référence dans l'introduction a été étendue, offrant une compréhension plus claire de la rigueur des tests.

4. 27 Fév

   La méthodologie détaillée a été supprimée, réduisant la longueur de l'article.

5. 21 Fév

   La mise en forme des titres a été mise à jour pour une meilleure lisibilité et cohérence.

6. 20 Fév

   La portée de l'évaluation comparative dans l'introduction a été réduite, offrant aux lecteurs une compréhension plus précise de l'étendue de l'évaluation.

7. 20 Fév

   La section Méthodologie a été étendue, fournissant un compte rendu détaillé de la configuration d'évaluation, des configurations de modèle et des mécanismes de notation pour les agents.

8. 23 Jan

   La section d'introduction, la section 'Pool de projets et configurations de modèles', la section 'Listes de contrôle fonctionnelles (audit côté navigateur)', la section 'Exemple de tâche de benchmark : tableau de bord de plateforme d'éducation en ligne', la section 'Portée du projet et pile technologique', la section 'Résultats détaillés du benchmark : performances de Kiro vs Gemini CLI Kiro (95 % de succès)', la section 'Comme vu ci-dessus, Kiro a livré une interface utilisateur de qualité prof

9. 6 Jan

   La section 'Que sont les agents de codage basés sur la CLI ?' a été étendue, offrant une explication plus détaillée de leurs capacités et avantages pour les lecteurs.

10. 2 Jan

    La section Introduction a été mise à jour, offrant un aperçu plus clair de la portée et de la méthodologie du benchmark.

11. 2 Jan

    Une phrase a été ajoutée à la section Méthodologie, clarifiant la manière dont les outils CLI ont été sollicités pour une évaluation comparative plus juste.

12. 202528 Déc

    La section Méthodologie a été étendue, fournissant une étude de cas détaillée du projet 'EduSphere', offrant aux lecteurs une compréhension plus approfondie de l'application et des résultats du benchmark.

13. 27 Déc

    Ajouté, Résultats à l'article, offrant aux lecteurs une analyse des performances des outils et de la méthodologie utilisée.

14. 4 Déc

    Mise à jour de l'introduction, section « Explorez les principaux outils CLI agentiques pour rationaliser et améliorer votre flux de travail d'édition de code », afin de clarifier la définition et la portée des outils CLI agentiques.

15. 28 Nov

    Détails supprimés de la section « Gestion de la sortie et du contexte », simplifiant la description des performances et de la gestion du contexte de Claude Code.

16. 26 Nov

    Claude Code et Cline CLI ont été déplacés, dans les descriptions de produits, pour améliorer le flux logique des informations.

17. 25 Nov

    Ajout de Gemini CLI, OpenHands, Cline CLI et Codex CLI à la section 'Agents de codage basés sur CLI', offrant aux lecteurs des informations sur quatre nouveaux outils.

18. 24 Nov

    Supprimé la section « Meilleurs cas d'utilisation », réduisant les informations sur les applications idéales de Claude Code.

19. 21 Nov

    La présentation a été mise à jour pour mieux refléter l'orientation de l'article sur les principaux outils CLI agentiques.

20. 13 Nov

    Mise à jour de l'Introduction, offrant aux lecteurs des exemples actuels de grands modèles linguistiques.

21. 30 Juil

    Mise à jour de la description des « agents de codage basés sur CLI » dans la section « outils de codage IA », offrant une compréhension plus claire de leur fonction.

Liens de référence

1.

Integration with Codex CLI | OpenRouter | OpenRouter | Documentation

OpenRouter | Documentation

Berk Kalelioğlu

Chercheur en IA

Suivre

Berk est chercheur en IA au sein de l’équipe benchmark d’AIMultiple, se concentrant sur l’IA agentique, l’apprentissage automatique et les grands et petits modèles de langage (LLM et SLM).

Voir le profil complet

Examiné techniquement par

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017.

Le travail de Cem chez AIMultiple a été cité par des publications mondiales de premier plan, notamment Business Insider, Forbes, Morning Brew et Washington Post, par des entreprises mondiales comme Deloitte et HPE, par des ONG comme World Economic Forum et par des organisations supranationales comme European Commission. [1], [2], [3], [4], [5]

Tout au long de sa carrière, Cem a été consultant en technologies, acheteur de technologies et entrepreneur technologique. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la digitalisation.

Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité du PDG. Il a également dirigé la croissance commerciale de l'entreprise de technologie profonde Hypatos, qui a atteint un revenu récurrent annuel à 7 chiffres et une valorisation à 9 chiffres, passant de 0 à ce résultat en deux ans. Le travail de Cem chez Hypatos a été couvert par des publications technologiques de premier plan comme TechCrunch et Business Insider.

Cem intervient régulièrement lors de conférences technologiques internationales. Il est diplômé de Bogazici University en tant qu'ingénieur informatique et titulaire d'un MBA de la Columbia Business School.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire