A-CODE-CLI Bench: Benchmark des CLI Agentiques

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

Résultats du benchmark des CLI agentiques

Aperçu des performances des outils CLI Agentiques

La précision du backend détermine le classement ; le score combiné la pondère à 0,7 contre 0,3 pour le frontend.

• Les neuf agents s'exécutant correctement utilisent tous le même Sonnet 4.6, pourtant le backend varie de Opencode avec 77,3% à Goose avec 55,4%. Cet écart de 22 points provient entièrement de l'orchestration.
• Un bon backend ne garantit pas une bonne performance globale : Cline (4e en backend, 69,5%) et Forge (5e, 67,2%) se classent bien en backend mais accusent un net retard en frontend, le 52,5% de Cline est le plus faible du panel, ce qui fait chuter les deux au classement combiné.
• Codex se classe 10e en backend (52,1%) malgré un frontend parfait à 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 potentiel backend de l'agent.¹ Gemini, également exécuté via un proxy, est limité de la même manière.
• Le rang de la build ne prédit pas le comportement : l'agent en tête ici ne conserve rien après compaction, tandis qu'un agent du milieu de tableau conserve tout.

Vitesse, utilisation de tokens et coût vs score

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

La rapidité, le faible coût ou la légèreté en tokens d'un agent ne prédisent pas son score.

• Opencode gagne sur les trois tableaux à la fois : meilleur score combiné (81,6%), le coût le plus bas parmi les agents performants (1,03 $ par tâche), parmi les plus économes en tokens et les plus rapides. Il inverse le compromis habituel précision-coût.
• Le coût varie d'un facteur d'environ 40x, de Forge à 0,18 $ jusqu'à Junie à 7,58 $, sans lien avec le rang. Forge est le moins cher car il fait le moins : son backend échoue à la création de tickets. Les 7,58 $ de Junie n'achètent qu'un score de milieu de tableau de 74,7% et constituent une borne supérieure gonflée.
• Goose paie le plus pour le moins : deuxième plus cher à 3,23 $, mais avec le score net le plus bas du panel (62,5%). Les trois premiers en 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 achètent des tentatives répétées et de la re-validation, pas une profondeur de résolution de problèmes.
• Les chiffres de tokens sont surtout liés à la mise en cache. Codex, Claude Code, Cline, Opencode, Gemini et Grok mettent en cache 86 à 98% de leurs entrées, si bien que les Claude Code's 4,18M tokens bruts se réduisent à un effectif de 115k. Junie, Goose, Kiro, Forge et Aider ne mettent pas en cache, ils paient donc chaque token qu'ils renvoient ; 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 ne mettant pas en cache, l'entrée effective correspond à tout ce qu'ils ont envoyé, donc à lire 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 produire un frontend, chacune notée 0.

Vous pouvez consulter notre méthodologie ci-dessous.

Comment fonctionnent les outils CLI agentiques

Les outils CLI agentiques sont des agents autonomes qui opèrent dans le terminal. Bien que 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 trois phases en boucle :

1. Collecte du contexte
2. Action
3. Vérification des résultats

Après vérification, l'agent collecte un contexte mis à jour et répète la boucle jusqu'à l'achèvement de la tâche ou l'atteinte d'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 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.

Différentes architectures d'agents imposent différentes stratégies de planification, politiques de nouvelle tentative et logiques de vérification. Certains agents privilégient la précision et un raisonnement plus profond au prix d'une utilisation de tokens et d'une latence plus élevées. D'autres privilégient la vitesse et un coût plus faible avec une robustesse comportementale réduite.

Intelligence du modèle vs architecture de l'agent

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

Ce benchmark teste les deux agents sur le même modèle fondamental : Claude Sonnet 4.6. Toute différence de score est donc une différence d'orchestration : comment le CLI collecte le contexte, quand il exécute les commandes, comment il valide la sortie et s'il réessaie après un échec.

Opencode et Claude Code utilisent tous deux Sonnet 4.6 directement. Opencode obtient 77,3% en backend ; Claude Code obtient 74,9%. Deux agents, même modèle, différence de 2,4 points de pourcentage en précision backend. Kiro et Opencode utilisent tous deux Sonnet 4.6. Kiro obtient 64,2% en backend ; Opencode obtient 77,3%. L'écart de 13 points est dû au CLI.

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

Ancrage dans 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 pour 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 chose : l'agent a-t-il réellement récupéré la page qu'il cite ?

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 réelle en direct Codex, Claude Code, Gemini et Grok récupèrent les pages actuelles et saisissent les changements récents. Codex a été le seul agent à atteindre le forum des développeurs, 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 quand 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épond à partir 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 fonctionne, mais a cité 31 sources sur la sonde Next.js. Les pages citées n'existent pas. Sa déclaration finale : « chaque cellule provient d'une page effectivement récupérée lors de cette session. »

Sur la sonde Next.js, tous les autres agents navigateurs ont ancré la quasi-totalité de leurs citations dans des pages qu'ils avaient effectivement récupérées. Forge n'en a ancré aucune. Le graphique superpose les citations ancrées de chaque agent à ses citations fabriquées, de sorte que les agents honnêtes apparaissent en barres pleines vertes et Forge en une seule barre rouge. 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 (pas de citations) figurent dans le tableau ci-dessus mais sont exclus ici.

Cline et Claude Code ont tous deux tourné 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 termes d'exactitude factuelle, mais ces scores dépendent d'une clé de réponses actuellement en cours de révision. Nous différons les tableaux de précision jusqu'à ce que la clé soit finalisée.

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 supprime les originaux. Nous avons testé si le résumé conserve ce qui est important.

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 sans présence dans les données d'entraînement. L'agent a lu les documents et compacté. Nous avons ensuite supprimé les fichiers source et demandé les 13 faits. Les fichiers étant 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 seulement avaient répondu 13 sur 13 lorsqu'ils pouvaient encore relire les fichiers. Ils relisaient à chaque requête. Lorsque les fichiers ont disparu, ils ont écrit « inconnu » plutôt que de deviner.

Goose, Forge, Opencode et Kiro tournent 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 en compaction. Kiro se classe septième au benchmark de build et retient tout en compaction. Performances solides en build et compaction forte sont des propriétés indépendantes.

Quatre agents sont sortis du cadre de ce test, chacun pour une raison concrète. Cline n'a pas pu être amené à son seuil de compaction. Nous avons construit 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, de sorte 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 rapportons que Cline n'est pas mesurable selon ce protocole plutôt que d'estimer un chiffre. Grok dispose d'une commande de compaction, mais il a lu nos documents par fragments plutôt que de les charger en entier, de sorte qu'il n'y a jamais eu de contexte complet à compacter. Le résumeur d'Aider compresse les tours de conversation, pas le contenu des fichiers ajoutés à la session, là où se trouvaient les faits. Junie n'a pas de fonction de compaction.

Découvrez davantage de nos benchmarks et analyses basées sur les données dans la recherche Google.

Ajouter comme source préférée

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 CLI se comportent sous les mêmes contraintes lorsque tous tournent sur le même modèle.

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

La tâche 6 consistait à construire un système de tickets de helpdesk full-stack avec :

• Deux rôles utilisateur (client et agent)
• Authentification JWT
• Transitions strictes de statut via un workflow
• 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é :

• Health check
• Authentification double rôle
• 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 post-connexion

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

Sur un seul modèle, le panel s'est scindé en trois groupes.

• 60% en backend, sept agents (codex, claude-code, cline, grok, goose, junie, opencode) : six étapes échouées identiques sur les trois réexécutions. Authentification, CRUD des tickets, réponses et isolation des données ont réussi ; les deux échecs portaient sur _11329_0_ et _11329_1_, où ils ont construit un _11329_2_ unifié au lieu des routes séparées du cahier des charges. Logique métier correcte, contrat REST erroné. Lors de l'exécution native précédente sur Gemini 3 Pro, Opencode avait construit les endpoints séparés 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 ticket elle-même a échoué, entraînant par effet domino toutes les étapes dépendantes.
• 24,4%, Kiro : instabilité, pas un mode de défaillance unique. Il a réussi neuf étapes au premier run, deux au deuxième, et au troisième le backend n'a jamais démarré (échec du health check). Les dix autres agents ont répété de manière identique à chaque réexécution.
• UI au sein du cluster à 60% : claude-code et cline ont échoué à la connexion sur un bug CORS identique, le frontend appelait le backend sur _11329_3_ depuis une origine _11329_4_ et le navigateur l'a bloqué, donc tous deux ont obtenu 75% ; les cinq autres ont rendu et ouvert une session proprement à 100%.
• La leçon à retenir est la convergence : sept CLI différents sur le même modèle ont commis la même erreur de contrat REST ; ici, le modèle domine et l'orchestration importe peu, à l'inverse des benchmarks d'observation ci-dessous.

Codex

Installation

Installez globalement avec :

• npm install -g @openai/codex

Alternativement, installez 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 a atterri dans le cluster des 60%. La logique métier était correcte ; il a manqué le contrat REST sur l'assignation et le statut, comme le reste du panel.

Comportement Backend

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

Comportement UI

Le frontend a réussi les huit étapes de validation. La connexion et l'état post-connexion se sont comportés correctement. 100% UI.

Junie

Installation

Junie est disponible via JetBrains Toolbox ou en tant que 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 supportés. Plusieurs options de fournisseur disponibles.

Rapport de tâche

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

Comportement Backend

Neuf étapes sur seize ont réussi : authentification, CRUD des tickets, réponses et isolation des données. Les six échecs portaient sur 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é, de sorte que les routes `/tickets/{id}/assign` et `/tickets/{id}/status` du cahier des charges ont renvoyé 404. La logique de transition elle-même était correcte. Stable sur les trois réexécutions.

Comportement 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 Linux AppImage (option portable) :

• Télécharger : https://desktop-release.q.us-east-1.amazonaws.com/latest/kiro-cli.appimage

Puis exécutez :

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

Authentification

Vous pouvez continuer avec votre plan 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% en backend est une moyenne sur trois réexécutions qui ont produit trois résultats différents. La build elle-même était solide quand elle s'exécutait ; le problème était qu'elle ne s'est pas exécutée de la même manière deux fois.

Comportement Backend

Lors du premier run, Kiro a réussi neuf étapes sur seize, le même profil que le cluster à 60%, échouant uniquement sur les routes d'assignation et de statut. Au deuxième run, il en a réussi deux. Au troisième, le backend n'est jamais apparu et même le health check a échoué. En moyenne, cela donne 24,4%. C'est l'instabilité, et non la conception de l'endpoint, qui distingue Kiro du cluster ici.

Comportement 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 au run précédent, où le formulaire de connexion ne parvenait pas à s'afficher sur une 422 au montage.

Claude Code

Installation

Pour macOS/Linux/WSL, selon votre gestionnaire de paquets préféré, vous pouvez installer Claude Code avec soit :

• 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% en backend en 379 secondes, dans le cluster principal. C'est une nette amélioration par rapport au run précédent, où un bogue de validation JWT renvoyait 401 sur chaque route authentifiée et faisait échouer 13 étapes sur 16. Dans ce run, le backend a fonctionné ; la perte était sur l'UI.

Comportement Backend

L'authentification, le CRUD des tickets, les réponses et l'isolation des données ont réussi. Les six échecs portaient sur les étapes d'assignation et de transition de statut, routées via un endpoint de mise à jour unifié au lieu des chemins séparés du cahier des charges. Stable sur les trois réexécutions.

Comportement UI

L'étape de connexion a échoué. Le frontend appelait le backend sur _11329_5_ tandis que la page était servie depuis une origine _11329_6_, et le navigateur a bloqué la requête 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 vous avez déjà python 3.8-3.13 installé, commencez par installer aider :

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

Authentification

Connectez-vous à votre compte OpenRouter et autorisez, 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 à 236 secondes et le plus léger, avec 1,3k tokens d'entrée et 18k de sortie. Il a également obtenu 13,3% en backend. L'authentification a fonctionné, mais la création de ticket a échoué, et chaque étape nécessitant un ticket existant a échoué avec.

Comportement Backend

Deux étapes ont réussi. La build a cassé à la création du ticket, de sorte que les listes de tickets client et agent, les réponses, l'assignation, les transitions de statut et les vérifications de rôle ont toutes échoué en cascade. Stable sur les trois réexécutions. Il s'agit d'une classe de défaillance différente du cluster à 60%, qui créait correctement les tickets et ne manquait que les routes d'assignation et de statut.

Comportement UI

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

OpenCode

Installation

Pour macOS/Linux/WSL :

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

Installez 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 y a de nombreuses options de fournisseur, sélectionnez celui que vous souhaitez et authentifiez-vous avec /connect

Rapport de tâche

Opencode domine le benchmark global, mais sur la Tâche 6 il a obtenu 60% en backend, dans le cluster principal, en 542 secondes. C'est la preuve la plus claire de l'influence du modèle dans cet article. Lors du précédent run sur modèle natif avec Gemini 3 Pro Preview, Opencode avait construit les endpoints séparés du cahier des charges 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 a changé.

Comportement Backend

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

Comportement 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 affichage :

• export XAI_API_KEY=”xai-…”

Rapport de tâche

Grok a terminé deuxième au benchmark global de build avec 75,4% en backend. Sur la Tâche 6 il a obtenu 60% en backend en 433 secondes, dans le cluster principal. Dans ce run, Grok a atteint Sonnet 4.6 via OpenRouter.

Comportement Backend

Neuf étapes sur seize ont réussi : authentification, CRUD des tickets, réponses et isolation des données. Les six échecs portaient sur les étapes d'assignation et de transition de statut, qui ciblaient _11329_7_ et _11329_8_. Grok a routé les deux via un endpoint de mise à jour unifié, de sorte que ces appels et les vérifications de rôle qui en dépendent ont renvoyé 404. Stable sur les trois réexécutions.

Comportement UI

Le frontend a réussi les huit étapes de validation. La connexion et l'état post-connexion se sont comportés 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 par :

• forge provider login

Et choisissez votre fournisseur.

Rapport de tâche

Forge a obtenu 13,3% en backend en 844 secondes. Son nombre de tokens de sortie est le plus bas du panel à 1,6k, ce qui indique une implémentation superficielle. Comme lors du run précédent, la build a cassé à la création de ticket et a entraîné une cascade.

Comportement Backend

Deux étapes ont réussi. La création de ticket a échoué, donc les listes de tickets, les réponses, l'assignation, les transitions de statut et les vérifications de rôle ont toutes échoué avec. Stable sur les trois réexécutions, le même profil à 13,3% qu'aider et gemini-cli.

Comportement UI

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

Gemini CLI

Installation

Exécutez instantanément :

• npx @google/gemini-cli

Ou installez globalement :

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

Authentification

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

Rapport de tâche

Gemini CLI a obtenu 13,3% en backend en 926 secondes, l'un des deux agents les plus lents du panel. L'authentification a fonctionné, mais la création de ticket a échoué et a entraîné une cascade. Son frontend, qui avait complètement échoué lors du run précédent à cause d'une incompatibilité Node 18 contre Vite 7, a réussi chaque étape cette fois.

Comportement Backend

Deux étapes ont réussi. La création de ticket a échoué, donc toutes les étapes dépendantes ont échoué. Stable sur les trois réexécutions, le même profil à 13,3% qu'aider et forge.

Comportement UI

Le frontend a réussi les huit étapes de validation. 100% UI, contre 0% lors du run précédent. Une 401 est apparue dans la console sur un appel authentifié, mais elle n'a pas bloqué le flux affiché.

Cline

Installation

Installez globalement avec :

• npm install -g cline

Authentification

En écrivant `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% en backend en 648 secondes, dans le cluster principal. C'est un grand changement par rapport au run précédent, où sa limite de huit erreurs avait arrêté la build prématurément et laissé un frontend vide. Ici, il a terminé la pile complète.

Comportement Backend

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

Comportement UI

L'étape de connexion a échoué en raison du même décalage d'origine CORS observé chez claude-code, sur une page _11329_9_ appelant un backend _11329_10_. Cinq étapes ont réussi, une a échoué, deux 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% en backend en 553 secondes, dans le cluster principal, mais a consommé 1,06M tokens d'entrée pour y parvenir. Il a terminé la pile complète cette fois, un changement par rapport au run précédent où le répertoire frontend était laissé vide.

Comportement Backend

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

Comportement UI

Le frontend a réussi les huit étapes de validation. 100% UI, contre 0% lors du run précédent.

Outils de codage IA

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

• CLI Agentique : Outils pour les flux de développement basés sur le terminal, génèrent, éditent et refactorisent le code via des prompts et des interactions en ligne de commande.
  • Exemples : Aider, Junie, Opencode, Claude Code, Codex

• Éditeurs de code IA : Également appelés IDE agentiques, ces outils fournissent une interface graphique similaire à VS Code (la plupart sont basés sur VS Code).
  • Exemples : Antigravity, Cursor, Kiro Code, Windsurf

• Constructeurs prompt-to-app : Plateformes low-code/no-code pour construire des applications en utilisant des prompts en langage naturel et des flux visuels.
  • Exemples : Bolt, Lovable, v0.dev, Firebase Studio, Dazl

Outils de revue de code IA

À mesure que le code généré par l'IA devient plus courant, les outils de revue de code sont essentiels pour détecter les bogues et les vulnérabilités. Nous avons évalué les meilleurs outils sur 309 PRs dans notre benchmark RevEval.

Que peuvent faire les outils CLI agentiques ?

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

• Travail de code de bout en bout : Créer et modifier des fichiers, corriger des bogues, refactoriser du code et exécuter des tests ou des linters directement depuis le terminal.
• Workflows agentiques : Effectuer des tâches en plusieurs étapes telles que le chaînage de tâches, le dépannage, la recherche et le débogage itératif.
• Gestion Git et de projet : Parcourir l'historique, résoudre les fusions, gérer les branches et créer des commits ou des pull requests.
• Command d'exécution et automatisation : Exécuter des commandes shell, automatiser des analyses et traduire le langage naturel en opérations CLI complexes.
• Gestion approfondie du contexte : Opérer sur des dépôts entiers avec une connaissance des dépendances et de la structure du projet.
• Flexibilité des modèles : Prise en charge de plusieurs modèles cloud et, dans certains cas, locaux ; certains outils permettent d'utiliser votre propre clé API ou de choisir entre des plans.
• 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

Benchmark A-CODE-CLI

Nous avons évalué les agents dans une configuration d'exécution en un seul essai pour mesurer la 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 tourné sur Claude Sonnet 4.6 (non reasoning). Deux agents ont nécessité un proxy pour atteindre ce modèle :

• Codex (OpenAI CLI) ne peut pas pointer nativement vers les modèles Anthropic. Il a été routé via une passerelle LiteLLM vers OpenRouter/Anthropic, avec un shim de cache rétablissant la mise en cache des prompts. Le proxy supprime les tokens de raisonnement (coût en capacité) 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 de modèle auxiliaires (détection de boucle, réparation d'outil malformé, compression de contexte) échouent ou renvoient un contenu invalide à travers le proxy, il a donc fonctionné sans ses propres filets de sécurité.

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

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

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

Claude Code a fonctionné via un abonnement utilisateur (OAuth). Kiro a fonctionné sur des crédits hébergés par Kiro (soutenu par Bedrock, multiplicateur 1,3x).

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

Notation. Backend : fumée fonctionnelle (adaptive_avg_step_pass_rate). Frontend : fumée UI via Playwright. Combiné : 0,7 × backend + 0,3 × frontend (pour les agents avec des données UI complètes). Le score backend est l'axe de classement principal. La performance frontend sature sur l'ensemble du panel.

Aider t-3 et t-4. Les deux tâches ont produit des backends qui ont planté au démarrage. Confirmé sur deux builds fraîches (mêmes erreurs : _11329_12_ sur _11329_13_ dans t-3, _11329_14_ sur _11329_15_ dans t-4). Noté 0 avec un drapeau _11329_16_, non exclu.

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

Versions CLI (run du benchmark de juin 2026)

Versions relevées sur les boîtes VPS du benchmark. Le run de build a été exécuté 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 dans 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 la chronologie des fonctionnalités spécifiées du framework et de citer une URL officielle par affirmation.

La notation a utilisé deux méthodes parallèles. Portail de vérité-terrain : une affirmation n'est noté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 à une clé de réponse vérifiée. Classification comportementale : un juge LLM a lu la transcription complète de chaque agent et l'a assigné à l'une des quatre catégories comportementales. La classification comportementale est la sortie principale ; les tableaux de précision notés seront publiés après que la clé de réponse aura terminé sa revue d'ancrage humain.

Les agents avec recherche intégrée (Codex, Gemini, Grok) ont tourné sur leurs modèles natifs car la tâche nécessite leur capacité de recherche intégrée. Les huit autres ont tourné sur Claude Sonnet 4.6. n=1.

Méthodologie de compaction du 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 toute question. Notation : correspondance exacte avec 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 retenants. La suppression des fichiers exclut la re-lecture ; les faits inventés excluent le rappel des données d'entraînement.

Tous les agents sauf Codex (GPT-5.5) et Gemini (Gemini 2.5 Pro) ont tourné sur Sonnet 4.6. Le modèle utilisé par agent est indiqué dans le tableau des résultats.

Pour en savoir plus

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 navigateur é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{kaleliolu2026,
  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}
}

Liens de référence

1.

Integration with Codex CLI | OpenRouter | OpenRouter | Documentation

Berk Kalelioğlu

Chercheur en IA

SuivreVoir le profil complet

Examiné techniquement par

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017. AIMultiple informe chaque mois des centaines de milliers d'entreprises (selon similarWeb), dont 55 % des entreprises du classement Fortune 500. Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes et le Washington Post, ainsi que par des entreprises mondiales comme Deloitte et HPE, des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne. Vous trouverez d'autres entreprises et ressources réputées ayant fait référence à AIMultiple. Tout au long de sa carrière, Cem a exercé les fonctions de consultant, d'acheteur et d'entrepreneur dans le secteur des technologies. 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 numérisation. Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité directe du PDG. Il a également piloté la croissance commerciale de la société de deep tech Hypatos, qui a atteint un chiffre d'affaires annuel récurrent à sept chiffres et une valorisation à neuf chiffres en seulement deux ans. Les travaux de Cem chez Hypatos ont été présentés dans des publications technologiques de référence telles que TechCrunch et Business Insider. Cem intervient régulièrement lors de conférences internationales sur les technologies. Diplômé en génie informatique de l'université de Bogazici, il est également 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