A-CODE-CLI Bench: Benchmark CLI Agentique

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 vérifications de validation atomiques par agent et plus de 5 000 exécutions de tests automatisés au total, incluant la logique backend, la fonctionnalité frontend et la vérification de cohérence multi-exécution.

Résultats du benchmark CLI agentique

Aperçu des performances des outils CLI agentiques

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

• Les neuf agents fonctionnant proprement utilisent tous le même Sonnet 4.6, pourtant le backend varie de 77,3% pour Opencode à 55,4% pour Goose. Cet écart de 22 points provient entièrement de l'orchestration.
• Un bon backend ne garantit pas un bon résultat final : Cline (4e en backend, 69,5%) et Forge (5e, 67,2%) se classent près du sommet en backend mais sont loin derrière en frontend, le 52,5% de Cline étant le plus faible du groupe, ce qui fait glisser les deux dans le classement combiné.
• Codex se classe 10e en backend (52,1%) malgré un frontend parfait de 100%. Il passe ici par un proxy pour accéder au 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 construction ne prédit pas le comportement : l'agent en tête ici ne retient rien après compactage, 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 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 comparé 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 à la fois : meilleur score combiné (81,6%), le coût le plus bas de tout agent performant (1,03 $ par tâche), parmi les plus faibles en tokens et les plus rapides en exécution. Il inverse le compromis habituel précision-coût.
• Le coût s'étend sur environ 40x, de Forge 0,18 $ à Junie 7,58 $, sans lien avec le classement. Forge est le moins cher car il en fait le moins : son backend échoue à la création de tickets. Les 7,58 $ de Junie achètent 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 $, pourtant le score propre le plus bas du groupe (62,5%). Les trois premiers en score restent économiques (Opencode 1,03 $, Claude Code 1,83 $, Grok 2,03 $).
• Ni le plus rapide ni le plus lent ne gagne : Kiro (439s) et Gemini (1 158s, surcoût du proxy) se classent tous deux au milieu. Les dépenses supplémentaires achètent des tentatives répétées et de la revalidation, pas de la profondeur de résolution de problèmes.
• Les chiffres de tokens sont principalement liés à la mise en cache. Codex, Claude Code, Cline, Opencode, Gemini et Grok mettent en cache 86–98% de leur entrée, donc les 4,18M tokens bruts de Claude Code se réduisent à un effectif de 115k. Junie, Goose, Kiro, Forge et Aider ne mettent pas en cache, donc ils paient pour chaque token renvoyé ; c'est pourquoi les 2,36M de Junie sont les plus élevés du groupe.
• Trois réserves sur les chiffres : pour les cinq agents sans cache, l'entrée effective est tout ce qu'ils ont envoyé, il faut donc la lire comme un plafond ; les 1,72 $ de Kiro sont un plancher (facturé au crédit, plus proche de 2,23 $) ; le 64,4% de Cline inclut quatre tâches où il a atteint sa limite d'erreur avant de livrer 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 à l'intérieur du terminal. Bien que la plupart des utilisateurs les déploient pour des tâches de codage, ils peuvent exécuter tout flux de travail réalisable via des commandes shell.

Ces agents fonctionnent généralement en boucle composée de trois phases :

1. Collecte du contexte
2. Prise d'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'à 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 effectue la planification, le raisonnement et la sélection des actions

Le framework d'agent fournit la 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 de navigateur, l'utilisation d'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 approfondi au prix d'une utilisation de tokens et d'une latence plus élevées. D'autres privilégient la vitesse et un coût réduit avec une robustesse comportementale moindre.

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 deux 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 : 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, 2,4 points de pourcentage d'écart en justesse 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 la contribution du CLI.

Les deux benchmarks d'observation ci-dessous poussent cela plus loin. Ils exécutent le même test de modèle commun sur la recherche web et le compactage 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 de la recherche web

Nous avons demandé à chaque agent d'auditer la documentation de frameworks : 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 effectué la sonde deux fois, une fois sur Unity et une fois sur Next.js/React. Les faits ont été sélectionnés de sorte 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 fausse. Nous avons vérifié une chose : l'agent a-t-il réellement récupéré la page qu'il a citée ?

Quatre agents ont 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 ont émergé.

• Recherche en direct réelle Codex, Claude Code, Gemini et Grok récupèrent des pages actuelles et capturent les changements récents. Codex a été le seul agent à atteindre le forum développeur, 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 rapporté une version qui avait été remplacée. Les récupérations étaient réelles ; les pages étaient obsolètes.
• Pas de recherche, répond depuis 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, pourtant a cité 31 sources lors de la sonde Next.js. Les pages citées n'existent pas. Sa déclaration finale : « chaque cellule provient d'une page réellement récupérée durant cette session. »

Lors de la sonde Next.js, tous les autres agents navigants ont ancré presque toutes leurs citations dans des pages qu'ils avaient réellement récupérées. Forge n'en a ancré aucune. Le graphique empile les citations ancrées de chaque agent contre ses citations fabriquées, de sorte que les agents honnêtes apparaissent comme des barres vertes pleines et Forge comme une seule barre rouge. Le graphique couvre les huit agents avec 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 avec la bonne réponse. Cline ne l'a pas fait. Même modèle, résultat différent.

Nous avons noté chaque réponse pour sa précision factuelle, mais ces notes dépendent d'une clé de réponse actuellement en cours de révision. Nous ne publions pas les tableaux de précision tant que la clé n'est pas finalisée.

Compactage de 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 importe.

Nous avons donné à chaque agent environ 112 000 tokens de documents contenant 13 faits inventés intégré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 a compacté. Nous avons ensuite supprimé les fichiers sources et demandé les 13 faits. Les fichiers étant supprimés, la seule source possible est le résumé de compactage.

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

Goose, Forge, Opencode et Kiro exécutent tous 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 construction et ne retient rien au compactage. Kiro se classe septième au benchmark de construction et retient tout au compactage. Une performance solide en construction et un compactage solide sont des propriétés indépendantes.

Quatre agents sont hors du champ de ce test, chacun pour une raison concrète. Cline n'a pas pu être poussé jusqu'à son seuil de compactage. 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, donc les documents se sont réduits à de courts aperçus. Son contexte a plafonné à 214 000 tokens, 21% de sa fenêtre d'un million de tokens, et le compactage ne s'est jamais déclenché. Nous rapportons Cline comme non mesurable sous ce protocole plutôt que d'estimer un chiffre. Grok dispose d'une commande de compactage, mais il a lu nos documents par fragments plutôt que de les charger en entier, donc il n'y a jamais eu de contexte complet à compacter. Le résumeur d'Aider compresse les tours de discussion, pas le contenu des fichiers ajoutés à la session, là où se trouvaient les faits. Junie n'a pas de fonctionnalité de compactage.

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 toutes fonctionnent sur le même modèle.

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

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

• Deux rôles utilisateur (client et agent)
• Authentification basée sur JWT
• Transitions strictes de flux de statut
• 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é :

• Vérification de santé
• Authentification double rôle
• Opérations CRUD de tickets
• Affectation 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 du contrat REST et l'intégration frontend-backend. Visitez GitHub pour voir les détails de la tâche.

Sur un seul modèle, le champ s'est divisé 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 de tickets, réponses et isolation des données réussis ; les deux échecs portaient sur /tickets/{id}/assign et /tickets/{id}/status, où ils ont construit un seul PATCH /tickets/{id} unifié au lieu des routes séparées 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 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 tickets elle-même a échoué, donc chaque étape dépendante a cascade.
• 24,4%, Kiro : 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 de la vérification de santé). 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 localhost:8000 depuis une origine 127.0.0.1 et le navigateur l'a bloqué, donc les deux ont obtenu 75% ; les cinq autres ont rendu et connecté proprement à 100%.
• L'enseignement est la convergence : sept CLI différents sur le même modèle ont fait la même erreur de contrat REST, donc ici le modèle domine et l'orchestration compte à peine, 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é API OpenAI. 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 cluster 60%. La logique métier était correcte ; il a manqué le contrat REST sur l'affectation et le statut, comme le reste du groupe.

Comportement Backend

Authentification, CRUD de tickets, réponses et isolation des données réussis. Les six échecs étaient les étapes d'affectation 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é, donc ces appels ont retourné 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 groupe à 1,52M, une borne supérieure non mise en cache affectée par un bug connu de comptabilisation de cache (voir la note du tableau des résultats).

Comportement Backend

Neuf étapes sur seize réussies : authentification, CRUD de tickets, réponses et isolation des données. Les six échecs étaient les étapes d'affectation et de transition de statut. Junie a géré le statut et l'affectation via un endpoint de mise à jour unifié, donc les routes `/tickets/{id}/assign` et `/tickets/{id}/status` de la spécification ont retourné 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échargement : 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 forfait Kiro-Code. Aucune option de fournisseur disponible.

Rapport de tâche

Kiro est le seul agent dont le score reflète l'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 construction elle-même était solide quand elle s'exécutait ; le problème est qu'elle ne s'est pas exécutée de la même manière deux fois.

Comportement Backend

Lors de la première exécution, Kiro a réussi neuf étapes sur seize, le même profil que le cluster 60%, n'échouant que sur les routes d'affectation et de statut. Lors de la deuxième exécution, il en a réussi deux. Lors de la troisième, le backend n'a jamais démarré et même la vérification de santé a échoué. En moyenne, cela donne 24,4%. L'instabilité, pas la conception des endpoints, est ce qui sépare Kiro du cluster ici.

Comportement UI

Quand le backend était fonctionnel, 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 n'a pas réussi à s'afficher suite à 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 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% en backend en 379 secondes, dans le cluster principal. C'est une amélioration marquée par rapport à l'exécution précédente, où un bug de validation JWT retournait 401 sur chaque route authentifiée et échouait 13 des 16 étapes. Dans cette exécution, le backend a fonctionné ; la perte était sur l'UI.

Comportement Backend

Authentification, CRUD de tickets, réponses et isolation des données réussis. Les six échecs étaient les étapes d'affectation et de transition de statut, routées via un endpoint de mise à jour unifié au lieu des chemins séparés de la spécification. Stable sur les trois ré-exécutions.

Comportement UI

L'étape de connexion a échoué. Le frontend appelait le backend sur localhost:8000 tandis que la page était servie depuis une origine 127.0.0.1, et le navigateur a bloqué la requête de connexion en raison de la politique CORS. Cinq étapes réussies, une échouée, deux 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é, installez d'abord 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 en entrée et 18k tokens en sortie. Il a également obtenu 13,3% en 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 Backend

Deux étapes réussies. La construction s'est cassée à la création de tickets, donc les listes de tickets client et agent, les réponses, l'affectation, les transitions de statut et les vérifications de rôles ont tous cascade en échec. Stable sur les trois ré-exécutions. C'est une classe d'échec différente du cluster 60%, qui créait les tickets correctement et ne manquait que les routes d'affectation et de statut.

Comportement UI

L'étape de connexion a échoué en raison du même décalage d'origine CORS observé dans claude-code et cline. Cinq étapes réussies, une échouée, 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 votre 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% 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 de l'exécution précédente en modèle natif sur Gemini 3 Pro Preview, Opencode a construit les endpoints séparés 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é ; c'est le modèle qui a changé.

Comportement Backend

Authentification, CRUD de tickets, réponses et isolation des données réussis. Les six échecs étaient les étapes d'affectation 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.

Build Grok

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 headless :

• export XAI_API_KEY="xai-…"

Rapport de tâche

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

Comportement Backend

Neuf étapes sur seize réussies : authentification, CRUD de tickets, réponses et isolation des données. Les six échecs étaient les étapes d'affectation et de transition de statut, qui ciblaient /tickets/{id}/assign et /tickets/{id}/status. Grok a routé les deux via un endpoint de mise à jour unifié, donc ces appels et les vérifications de rôles qui en dépendent ont retourné 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 avec :

• 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 groupe à 1,6k, ce qui indique une implémentation superficielle. Comme lors de l'exécution précédente, la construction s'est cassée à la création de tickets et a cascade.

Comportement Backend

Deux étapes réussies. La création de tickets a échoué, donc les listes de tickets, les réponses, l'affectation, les transitions de statut et les vérifications de rôles ont tous échoué avec elle. 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é dans claude-code, cline et aider. Cinq étapes réussies, une échouée, 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 (OAuth Google) : export GOOGLE_CLOUD_PROJECT="VOTRE_ID_PROJET" puis lancez gemini.
Option 2 (clé API) : export GEMINI_API_KEY="VOTRE_CLE_API" 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 groupe. L'authentification a fonctionné, mais la création de tickets a échoué et a cascade. Son frontend, qui avait complètement échoué lors de l'exécution précédente en raison d'une incompatibilité Node 18 versus Vite 7, a réussi chaque étape cette fois-ci.

Comportement Backend

Deux étapes réussies. La création de tickets 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 de l'exécution précédente. Une 401 est apparue dans la console sur un appel authentifié, mais n'a pas bloqué le flux rendu.

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 à l'exécution précédente, où sa limite de huit erreurs avait interrompu la construction prématurément et laissé un frontend vide. Ici, il a terminé la pile complète.

Comportement Backend

Authentification, CRUD de tickets, réponses et isolation des données réussis. Les six échecs étaient les étapes d'affectation 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é dans claude-code, sur une page 127.0.0.1 appelant un backend localhost. Cinq étapes réussies, une échouée, 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-ci, un changement par rapport à l'exécution précédente où le répertoire frontend était resté vide.

Comportement Backend

Authentification, CRUD de tickets, réponses et isolation des données réussis. Les six échecs étaient les étapes d'affectation 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 de l'exécution précédente.

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

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 remanient 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 construits 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 bugs 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 ?

À travers 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 bugs, remanier 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 le chaînage de tâches, le dépannage, la recherche et le débogage itératif.
• Git et gestion de projet : Examiner l'historique, résoudre les fusions, gérer les branches et créer des commits ou des pull requests.
• Exécution de commandes et automatisation : Exécuter des commandes shell, automatiser des analyses et traduire le langage naturel en opérations CLI complexes.
• Gestion de contexte profond : Opérer sur des dépôts entiers avec une conscience des dépendances et de la structure du projet.
• Flexibilité de modèle : 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érents forfaits.
• Accès sandboxé ou contrôlé : Offrir 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 unique 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 fonctionné sur Claude Sonnet 4.6 (non-raisonnement). Deux agents ont nécessité un proxy pour atteindre ce modèle :

• Codex (CLI OpenAI) 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 restaurant 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 auxiliaire (détection de boucle, réparation d'outil malformé, compression de contexte) échouent ou retournent un contenu invalide à travers le proxy, donc il a fonctionné sans ses propres filets de sécurité.

Forge a nécessité un proxy séparé pour supprimer les blocs de réflexion étendue des réponses, que Forge active de force et qui causent des erreurs 400 lorsqu'ils sont renvoyés en écho. 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 construction. Ses scores portent un astérisque multi-modèle.

Claude Code a fonctionné via abonnement utilisateur (OAuth). Kiro a fonctionné sur 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 nouvelle tentative ou de raisonnement ajustés. Chacun a fonctionné avec sa configuration par défaut.

Notation. Backend : test de fumée fonctionnel (adaptive_avg_step_pass_rate). Frontend : test de 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 à travers le groupe.

Aider t-3 et t-4. Les deux tâches ont produit des backends qui ont planté au démarrage. Confirmé sur deux constructions fraîches (mêmes erreurs : TypeError sur class Card dans t-3, AmbiguousForeignKeysError sur User.auctions dans t-4). Noté 0 avec un indicateur backend_never_ready, non exclu.

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

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

Versions lues depuis les boîtes VPS du benchmark. L'exécution de construction 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 d'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 la chronologie 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 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 si 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 une fois que la clé de réponse aura terminé sa revue d'ancrage humain.

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

Méthodologie de compactage 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 sources avant de poser des questions. 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 véritables reteneurs. La suppression des fichiers exclut la re-lecture ; les faits inventés excluent le rappel depuis les données d'entraînement.

Tous les agents sauf Codex (GPT-5.5) et Gemini (Gemini 2.5 Pro) ont fonctionné 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 émergente de navigateurs 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 CLI Agentique}},
  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

OpenRouter | Documentation

Berk Kalelioğlu

Chercheur en IA

Suivre

Berk est chercheur en IA chez AIMultiple, se concentrant sur les systèmes d'IA agentique et les language models.

Voir 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