A-CODE-CLI Bench: Benchmark CLI Agentico

Gli strumenti CLI agentici sono strumenti di codifica IA che possono creare ed eliminare file, eseguire comandi, pianificare ed eseguire la codifica dell'intero progetto. Abbiamo confrontato i principali strumenti in 10 scenari reali di sviluppo web, eseguendo circa 600 controlli di validazione atomici per agente e oltre circa 5.000 esecuzioni totali di test automatizzati, inclusi logica backend, funzionalità frontend e verifica della coerenza multi-esecuzione.

Risultati del benchmark CLI agentico

Approfondimenti sulle Prestazioni degli strumenti CLI Agentici

La correttezza del backend determina la classifica; il punteggio combinato la pondera a 0,7 contro lo 0,3 del frontend.

• Tutti e nove gli agenti funzionanti in modo pulito usano lo stesso Sonnet 4.6, eppure il backend varia dal 77,3% di Opencode fino al 55,4% di Goose. Quel divario di 22 punti deriva interamente dall'orchestrazione.
• Un backend forte non garantisce un buon piazzamento finale: Cline (4° nel backend, 69,5%) e Forge (5°, 67,2%) si classificano vicino alla vetta nel backend ma restano indietro nel frontend, il 52,5% di Cline è il più debole del gruppo, quindi entrambi scivolano nella classifica combinata.
• Codex si classifica 10° nel backend (52,1%) nonostante un frontend perfetto al 100%. Qui viene eseguito tramite un proxy per raggiungere il modello comune, il che potrebbe penalizzare le sue capacità, quindi è probabile che questo rappresenti un limite minimo piuttosto che il vero backend dell'agente.¹ Anche Gemini, eseguito tramite proxy, è limitato allo stesso modo.
• La classifica nella build non predice il comportamento: l'agente che guida qui non conserva nulla dopo la compattazione, mentre un agente di metà classifica conserva tutto.

Velocità, utilizzo dei token e costo rispetto al punteggio

Abbiamo valutato l'efficienza di esecuzione utilizzando il tempo medio di esecuzione (secondi), l'utilizzo effettivo dei token (input + output) e il costo per attività (USD), ciascuno confrontato con il punteggio di accuratezza combinato:

Quanto un agente sia veloce, economico o parsimonioso nei token non predice il suo punteggio.

• Opencode vince su tutti e tre contemporaneamente: miglior punteggio combinato (81,6%), il costo più basso tra gli agenti capaci ($1,03 per attività), tra i minori token e le esecuzioni più rapide. Inverte il consueto compromesso accuratezza-costo.
• Il costo si estende per circa 40x, da Forge $0,18 a Junie $7,58, senza alcun legame con la classifica. Forge è il più economico perché fa il minimo: il suo backend fallisce la creazione dei ticket. I $7,58 di Junie acquistano un 74,7% di metà classifica e rappresentano un limite superiore gonfiato.
• Goose paga di più per il minimo risultato: secondo più costoso a $3,23, eppure il punteggio netto più basso del gruppo (62,5%). I primi tre per punteggio rimangono economici (Opencode $1,03, Claude Code $1,83, Grok $2,03).
• Né il più veloce né il più lento vince: Kiro (439s) e Gemini (1.158s, sovraccarico proxy) si piazzano entrambi a metà classifica. La spesa extra acquista nuovi tentativi e ri-validazioni, non profondità di risoluzione dei problemi.
• I numeri dei token riguardano principalmente la cache. Codex, Claude Code, Cline, Opencode, Gemini e Grok mettono in cache dall'86 al 98% del loro input, quindi i 4,18M token lordi di Claude Code si riducono a un effettivo di 115k. Junie, Goose, Kiro, Forge e Aider non usano la cache, quindi pagano per ogni token che reinviano; ecco perché i 2,36M di Junie sono i più alti del gruppo.
• Tre avvertenze sui numeri: per i cinque agenti senza cache, l'input effettivo è tutto ciò che hanno inviato, quindi va letto come un tetto massimo; i $1,72 di Kiro sono un minimo (fatturati a credito, più vicini a $2,23); il 64,4% di Cline include quattro attività in cui ha raggiunto il limite di errore prima di consegnare un frontend, ciascuna con punteggio 0.

Puoi consultare la nostra metodologia qui sotto.

Come funzionano gli strumenti CLI agentici

Gli strumenti CLI agentici sono agenti autonomi che operano all'interno del terminale. Sebbene la maggior parte degli utenti li utilizzi per attività di codifica, possono eseguire qualsiasi flusso di lavoro realizzabile tramite comandi shell.

Questi agenti operano tipicamente in un ciclo composto da tre fasi:

1. Raccogliere il contesto
2. Intraprendere un'azione
3. Verificare i risultati

Dopo la verifica, l'agente raccoglie il contesto aggiornato e ripete il ciclo fino al completamento dell'attività o al raggiungimento di una condizione di arresto.

Il ciclo è influenzato da due fonti:

• L'utente umano, che fornisce l'attività iniziale e può interrompere l'esecuzione
• Il modello, che esegue pianificazione, ragionamento e selezione delle azioni

Il framework agente fornisce struttura attorno al modello. Definisce come il modello deve pianificare, quando deve eseguire i comandi, come deve convalidare i risultati e quali strumenti sono disponibili. Questi strumenti possono includere esecuzione shell, accesso al file system, controllo del browser, uso del computer, integrazioni MCP o «competenze» riutilizzabili.

Diverse architetture di agente impongono diverse strategie di pianificazione, politiche di retry e logiche di verifica. Alcuni agenti privilegiano precisione e ragionamento più approfondito al costo di un maggiore utilizzo di token e latenza. Altri privilegiano velocità e costi inferiori con una minore robustezza comportamentale.

Intelligenza del modello vs architettura dell'agente

Le differenze di prestazioni tra gli strumenti CLI agentici non provengono da un'unica fonte. Emergono da due livelli: il modello di base e il framework di orchestrazione che lo avvolge.

Questo benchmark testa entrambi gli agenti sullo stesso modello di base: Claude Sonnet 4.6. Qualsiasi differenza di punteggio è quindi una differenza nell'orchestrazione: come la CLI raccoglie il contesto, quando esegue i comandi, come convalida l'output e se ritenta dopo un fallimento.

Opencode e Claude Code usano entrambi Sonnet 4.6 direttamente. Opencode ottiene un backend del 77,3%; Claude Code ottiene un backend del 74,9%. Due agenti, stesso modello, 2,4 punti percentuali di differenza nella correttezza del backend. Anche Kiro e Opencode usano Sonnet 4.6. Kiro ottiene un backend del 64,2%; Opencode ottiene un backend del 77,3%. Il divario di 13 punti è il contributo della CLI.

I due benchmark osservativi qui sotto spingono oltre questo concetto. Eseguono lo stesso test con modello comune sulla ricerca web e la compattazione del contesto, dove i divari non sono di 13 punti ma la differenza tra trovare la risposta giusta e inventarne una sbagliata.

Radicamento nella ricerca web

Abbiamo chiesto a ogni agente di verificare la documentazione di un framework: quale versione ha introdotto una funzionalità, qual è il suo stato attuale e cosa è cambiato di recente. Ogni risposta doveva citare una fonte ufficiale. Abbiamo eseguito l'indagine due volte, una su Unity e una su Next.js/React. I fatti sono stati selezionati in modo che la risposta corretta esista solo su una pagina attuale e pubblicata. Rispondere basandosi sui dati di addestramento produce una risposta sicura ma sbagliata. Abbiamo verificato una cosa: l'agente ha effettivamente recuperato la pagina che ha citato?

Quattro agenti dispongono di ricerca web integrata. Tre di essi (Codex, Gemini, Grok) sono stati eseguiti sui loro modelli nativi non Sonnet; gli altri otto, incluso Claude Code, sono stati eseguiti su Sonnet 4.6.

Sono emersi quattro modelli.

• Ricerca live reale Codex, Claude Code, Gemini e Grok recuperano pagine aggiornate e colgono le modifiche recenti. Codex è stato l'unico agente a raggiungere il forum degli sviluppatori, dove risiedono i fatti più difficili.
• Cerca, ma approda su pagine vecchie Cline ha recuperato due dozzine di pagine di documentazione reali e ha comunque riportato una versione che era stata sostituita. I recuperi erano reali; le pagine erano obsolete.
• Nessuna ricerca, risponde dall'addestramento Aider non naviga e lo dichiara. Questa è la risposta onesta.
• Fonti fabbricate Forge non ha recuperato nulla di funzionante, eppure ha citato 31 fonti nell'indagine su Next.js. Le pagine citate non esistono. La sua dichiarazione conclusiva: «ogni cella proviene da una pagina effettivamente recuperata durante questa sessione».

Nell'indagine su Next.js, ogni altro agente dotato di navigazione ha fondato quasi tutte le sue citazioni su pagine effettivamente recuperate. Forge non ne ha fondata nessuna. Il grafico confronta le citazioni fondate di ciascun agente con quelle fabbricate, così gli agenti onesti appaiono come barre verdi piene e Forge come un'unica barra rossa. Il grafico copre gli otto agenti con un registro di recupero per URL verificabile. Grok (ricerca lato server), Gemini (esecuzione troncata) e Aider (nessuna citazione) compaiono nella tabella sopra ma sono esclusi qui.

Cline e Claude Code sono stati entrambi eseguiti su Sonnet 4.6 in questo test. Claude Code ha trovato e aperto la pagina con la risposta corretta. Cline no. Stesso modello, risultato diverso.

Abbiamo valutato ogni risposta per l'accuratezza fattuale, ma quei punteggi dipendono da una chiave di risposta attualmente in fase di revisione. Sospendiamo la pubblicazione delle tabelle di accuratezza fino alla finalizzazione della chiave.

Compattazione del contesto

Quando una sessione diventa lunga, l'agente compatta il suo contesto: sostituisce la cronologia dettagliata con un breve riepilogo ed elimina gli originali. Abbiamo testato se il riepilogo conserva ciò che è importante.

Abbiamo fornito a ciascun agente circa 112.000 token di documenti con 13 fatti inventati incorporati: un PIN di reperibilità, una regione cloud, un tag di build e altri dieci. Inventati significa che i valori sono stringhe uniche senza presenza nei dati di addestramento. L'agente ha letto i documenti e ha compattato. Abbiamo quindi eliminato i file sorgente e chiesto tutti i 13 fatti. Con i file eliminati, l'unica fonte possibile è il riepilogo di compattazione.

Quattro agenti hanno conservato ogni fatto. Tre non ne hanno conservato nessuno. I tre che hanno totalizzato 0 basandosi solo sulla memoria avevano risposto 13 su 13 mentre potevano ancora rileggere i file. Stavano rileggendo a ogni interrogazione. Quando i file sono scomparsi, hanno scritto «sconosciuto» invece di tirare a indovinare.

Goose, Forge, Opencode e Kiro eseguono tutti Sonnet 4.6. Kiro ha conservato tutti i 13 fatti. Gli altri tre non ne hanno conservato nessuno. Stesso modello, risultato opposto.

Opencode è primo nel benchmark di build e non conserva nulla nella compattazione. Kiro è settimo nel benchmark di build e conserva tutto nella compattazione. Prestazioni elevate nella build e compattazione efficace sono proprietà indipendenti.

Quattro agenti sono rimasti fuori dall'ambito di questo test, ciascuno per una ragione concreta. Cline non ha potuto essere portato alla sua soglia di compattazione. Abbiamo costruito un set di documenti da 863.000 token e gli abbiamo fatto leggere ogni file, ma cline tronca ogni output degli strumenti a circa 2.000 caratteri, quindi i documenti sono collassati in brevi anteprime. Il suo contesto si è stabilizzato a 214.000 token, il 21% della sua finestra da un milione di token, e la compattazione non è mai scattata. Riportiamo cline come non misurabile in base a questo protocollo anziché stimare un numero. Grok ha un comando di compattazione, ma ha letto i nostri documenti in frammenti invece di caricarli completamente, quindi non c'è mai stato un contesto completo da compattare. Il riepilogatore di Aider comprime i turni di chat, non i contenuti dei file aggiunti alla sessione, che è dove risiedevano i fatti. Junie non ha una funzionalità di compattazione.

Comportamenti degli agenti sull'attività 6

Abbiamo valutato gli agenti su 10 attività. Di seguito è riportata un'analisi dettagliata dell'Attività 6 per mostrare come diverse architetture CLI si comportano sotto gli stessi vincoli quando tutte vengono eseguite sullo stesso modello.

Attività 6: Sistema di ticket helpdesk (Web)

L'Attività 6 richiedeva la costruzione di un sistema di ticket helpdesk full-stack con:

• Due ruoli utente (cliente e agente)
• Autenticazione basata su JWT
• Transizioni rigorose del flusso di lavoro degli stati
• Isolamento dei dati (404 invece di 403 per accesso tra utenti)
• Backend FastAPI
• Frontend React/Vue/Svelte + Vite
• Comandi di esecuzione deterministici

Il test fumogeno ha convalidato:

• Health check
• Autenticazione a doppio ruolo
• Operazioni CRUD sui ticket
• Assegnazione e risposte
• Transizioni di stato
• Applicazione dei ruoli
• Isolamento dei dati
• Login UI e comportamento post-login

Questa attività mette sotto stress la gestione dello stato, la correttezza dell'autenticazione, la disciplina del contratto REST e l'integrazione frontend-backend. Visita GitHub per vedere i dettagli dell'attività.

Su un solo modello, il gruppo si è diviso in tre categorie.

• Backend al 60%, sette agenti (codex, claude-code, cline, grok, goose, junie, opencode): sei passaggi falliti identici in tutte e tre le riesecuzioni. Auth, CRUD ticket, risposte e isolamento dei dati superati; entrambi i fallimenti erano su _11329_0_ e _11329_1_, dove hanno costruito un _11329_2_ unificato invece delle route separate della specifica. Logica di business corretta, contratto REST sbagliato. Nell'esecuzione nativa precedente su Gemini 3 Pro, Opencode ha costruito gli endpoint separati e ha totalizzato 93,3%; su Sonnet 4.6 ha scelto il design unificato come gli altri.
• 13,3%, tre agenti (aider, forge, gemini-cli): l'autenticazione ha funzionato, ma la creazione dei ticket stessa è fallita, quindi ogni passaggio dipendente è crollato a cascata.
• 24,4%, Kiro: instabilità, non un'unica modalità di fallimento. Ha superato nove passaggi nella prima esecuzione, due nella seconda, e nella terza il backend non si è mai avviato (health check fallito). Gli altri dieci agenti si sono ripetuti in modo identico a ogni riesecuzione.
• UI all'interno del cluster del 60%: claude-code e cline hanno fallito il login per un identico bug CORS, il frontend chiamava il backend su _11329_3_ da un'origine _11329_4_ e il browser lo bloccava, quindi entrambi hanno totalizzato 75%; gli altri cinque hanno renderizzato e fatto il login correttamente al 100%.
• Il punto chiave è la convergenza: sette CLI diverse sullo stesso modello hanno commesso lo stesso errore di contratto REST, quindi qui il modello domina e l'orchestrazione conta appena, l'opposto dei benchmark osservativi qui sotto.

Codex

Installazione

Installa globalmente con:

• npm install -g @openai/codex

In alternativa, installa globalmente con Homebrew (macOS/Linux)

• brew install –cask codex

Autenticazione

Dopo aver configurato Codex, puoi proseguire con il tuo Account ChatGPT, o con la tua API Key OpenAI. Nessuna opzione provider disponibile.

Rapporto sull'Attività

Codex ha costruito un sistema funzionante in 454 secondi e si è posizionato nel cluster del 60%. La logica di business era corretta; ha mancato il contratto REST su assegnazione e stato, come il resto del gruppo.

Comportamento del Backend

Autenticazione, CRUD ticket, risposte e isolamento dei dati superati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, che puntavano a `/tickets/{id}/assign` e `/tickets/{id}/status`. Codex ha instradato entrambi attraverso un endpoint di aggiornamento unificato, quindi quelle chiamate hanno restituito 404. Stabile in tutte e tre le riesecuzioni.

Comportamento dell'UI

Il frontend ha superato tutti gli otto passaggi di convalida. Il login e lo stato post-login si sono comportati correttamente. 100% UI.

Junie

Installazione

Junie è disponibile tramite JetBrains Toolbox o come CLI autonoma:

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

Autenticazione

Prosegui con il tuo account JetBrains o genera una JUNIE_API_KEY su junie.jetbrains.com/cli, oppure esporta la tua chiave API da Anthropic, OpenAI, Google o altri provider supportati. Molteplici opzioni provider disponibili.

Rapporto sull'Attività

Junie ha prodotto un sistema full-stack completo in 444 secondi e ha totalizzato un backend del 60%, nel cluster principale. Il suo input effettivo su questa attività è il più alto del gruppo a 1,52M, un limite superiore senza cache influenzato da un bug noto di contabilizzazione della cache (vedi la nota della tabella dei risultati).

Comportamento del Backend

Nove dei sedici passaggi superati: autenticazione, CRUD ticket, risposte e isolamento dei dati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato. Junie ha gestito stato e assegnazione attraverso un endpoint di aggiornamento unificato, quindi le route `/tickets/{id}/assign` e `/tickets/{id}/status` della specifica hanno restituito 404. La logica di transizione stessa era corretta. Stabile in tutte e tre le riesecuzioni.

Comportamento dell'UI

Il frontend ha superato tutti gli otto passaggi di convalida. 100% UI.

Kiro CLI

Installazione

Per macOS/Linux/WSL:

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

Linux AppImage alternativa (opzione portatile):

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

Poi esegui:

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

Autenticazione

Puoi proseguire con il tuo piano Kiro-Code. Nessuna opzione provider disponibile.

Rapporto sull'Attività

Kiro è l'unico agente il cui punteggio riflette instabilità piuttosto che una singola scelta progettuale. Il suo 24,4% di backend è una media su tre riesecuzioni che hanno prodotto tre esiti diversi. La build stessa era valida quando veniva eseguita; il problema era che non veniva eseguita allo stesso modo due volte.

Comportamento del Backend

Alla prima esecuzione, Kiro ha superato nove dei sedici passaggi, lo stesso profilo del cluster del 60%, fallendo solo le route di assegnazione e stato. Alla seconda esecuzione ne ha superati due. Alla terza il backend non si è mai avviato e persino l'health check è fallito. In media, questo fa 24,4%. L'instabilità, non il design degli endpoint, è ciò che separa Kiro dal cluster in questo caso.

Comportamento dell'UI

Quando il backend era attivo, il frontend ha superato tutti gli otto passaggi di convalida. 100% UI. Questo è un cambiamento rispetto all'esecuzione precedente, dove il modulo di login non veniva renderizzato a causa di un 422 al mount.

Claude Code

Installazione

Per macOS/Linux/WSL, considerando il tuo gestore di pacchetti preferito, puoi installare Claude Code con:

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

Autenticazione

Dopo aver configurato Claude Code, puoi proseguire con il tuo Account Claude. Nessuna opzione provider disponibile.

Rapporto sull'Attività

Claude Code ha totalizzato un backend del 60% in 379 secondi, nel cluster principale. Si tratta di un netto miglioramento rispetto all'esecuzione precedente, dove un bug di convalida JWT restituiva 401 su ogni route autenticata e falliva 13 dei 16 passaggi. In questa esecuzione il backend ha funzionato; la perdita è stata sull'UI.

Comportamento del Backend

Autenticazione, CRUD ticket, risposte e isolamento dei dati superati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, instradati attraverso un endpoint di aggiornamento unificato invece dei percorsi separati della specifica. Stabile in tutte e tre le riesecuzioni.

Comportamento dell'UI

Il passaggio di login è fallito. Il frontend chiamava il backend su _11329_5_ mentre la pagina veniva servita da un'origine _11329_6_, e il browser ha bloccato la richiesta di login per la politica CORS. Cinque passaggi superati, uno fallito, due bloccati. 75% UI. Cline è fallito allo stesso modo.

Aider

Installazione

Se hai già python 3.8-3.13 installato, per prima cosa installa aider:

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

Autenticazione

Accedi al tuo account OpenRouter e autorizza, oppure esporta la tua API Key nel tuo ambiente con:

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

Rapporto sull'Attività

Aider è stato l'agente più veloce a 236 secondi e il più leggero, con 1,3k token in input e 18k in output. Ha anche totalizzato un backend del 13,3%. L'autenticazione ha funzionato, ma la creazione dei ticket è fallita, e ogni passaggio che richiedeva un ticket esistente è fallito con essa.

Comportamento del Backend

Due passaggi superati. La build si è interrotta alla creazione del ticket, quindi le liste dei ticket cliente e agente, le risposte, l'assegnazione, le transizioni di stato e i controlli dei ruoli sono tutti crollati a cascata. Stabile in tutte e tre le riesecuzioni. Questa è una classe di fallimento diversa dal cluster del 60%, che ha creato i ticket correttamente e ha mancato solo le route di assegnazione e stato.

Comportamento dell'UI

Il passaggio di login è fallito per la stessa discrepanza di origine CORS vista in claude-code e cline. Cinque passaggi superati, uno fallito, due bloccati. 75% UI.

OpenCode

Installazione

Per macOS/Linux/WSL:

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

Installa globalmente con:

• npm i -g opencode-ai

Per macOS/Linux, considerando il tuo gestore di pacchetti preferito:

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

Autenticazione

Ci sono molte opzioni provider, seleziona il provider desiderato e autenticati con /connect

Rapporto sull'Attività

Opencode è in testa al benchmark complessivo, ma sull'Attività 6 ha totalizzato un backend del 60%, nel cluster principale, in 542 secondi. Questa è la prova più chiara a favore del modello nell'articolo. Nell'esecuzione precedente con modello nativo su Gemini 3 Pro Preview, Opencode ha costruito gli endpoint separati della specifica e ha totalizzato 93,3% in questo caso. La stessa CLI su Sonnet 4.6 ha scelto l'endpoint unificato ed è scesa al 60%. Lo strumento non è cambiato; il modello sì.

Comportamento del Backend

Autenticazione, CRUD ticket, risposte e isolamento dei dati superati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, instradati attraverso un endpoint di aggiornamento unificato. Stabile in tutte e tre le riesecuzioni.

Comportamento dell'UI

Il frontend ha superato tutti gli otto passaggi di convalida. 100% UI.

Grok Build

Installazione

Per macOS/Linux:

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

Autenticazione

Accedi con il tuo account xAI al primo avvio, o imposta una chiave API per uso headless:

• export XAI_API_KEY="xai-…"

Rapporto sull'Attività

Grok si è classificato secondo in assoluto nel benchmark di build con un backend del 75,4%. Sull'Attività 6 ha totalizzato un backend del 60% in 433 secondi, nel cluster principale. In questa esecuzione Grok ha raggiunto Sonnet 4.6 tramite OpenRouter.

Comportamento del Backend

Nove dei sedici passaggi superati: autenticazione, CRUD ticket, risposte e isolamento dei dati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, che puntavano a _11329_7_ e _11329_8_. Grok ha instradato entrambi attraverso un endpoint di aggiornamento unificato, quindi quelle chiamate e i controlli dei ruoli che dipendono da esse hanno restituito 404. Stabile in tutte e tre le riesecuzioni.

Comportamento dell'UI

Il frontend ha superato tutti gli otto passaggi di convalida. Il login e lo stato post-login si sono comportati correttamente. 100% UI.

Forge

Installazione

Per macOS/Linux/WSL:

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

Autenticazione

Configura le tue credenziali provider in modo interattivo con:

• forge provider login

E scegli il tuo provider.

Rapporto sull'Attività

Forge ha totalizzato un backend del 13,3% in 844 secondi. Il suo conteggio dei token di output è il più basso del gruppo a 1,6k, il che indica un'implementazione superficiale. Come nell'esecuzione precedente, la build si è interrotta alla creazione del ticket ed è crollata a cascata.

Comportamento del Backend

Due passaggi superati. La creazione del ticket è fallita, quindi le liste dei ticket, le risposte, l'assegnazione, le transizioni di stato e i controlli dei ruoli sono tutti falliti di conseguenza. Stabile in tutte e tre le riesecuzioni, lo stesso profilo del 13,3% di aider e gemini-cli.

Comportamento dell'UI

Il passaggio di login è fallito per la stessa discrepanza di origine CORS vista in claude-code, cline e aider. Cinque passaggi superati, uno fallito, due bloccati. 75% UI.

Gemini CLI

Installazione

Esegui istantaneamente:

• npx @google/gemini-cli

Oppure installa globalmente:

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

Autenticazione

Opzione 1 (OAuth Google): export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID" poi avvia gemini.
Opzione 2 (chiave API): export GEMINI_API_KEY="YOUR_API_KEY" poi avvia gemini.
Opzione 3 (Vertex IA): export GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true.

Rapporto sull'Attività

Gemini CLI ha totalizzato un backend del 13,3% in 926 secondi, uno dei due agenti più lenti del gruppo. L'autenticazione ha funzionato, ma la creazione dei ticket è fallita ed è crollata a cascata. Il suo frontend, che era fallito completamente nell'esecuzione precedente per un'incompatibilità tra Node 18 e Vite 7, ha superato ogni passaggio questa volta.

Comportamento del Backend

Due passaggi superati. La creazione del ticket è fallita, quindi tutti i passaggi dipendenti sono falliti. Stabile in tutte e tre le riesecuzioni, lo stesso profilo del 13,3% di aider e forge.

Comportamento dell'UI

Il frontend ha superato tutti gli otto passaggi di convalida. 100% UI, in aumento dallo 0% dell'esecuzione precedente. Un 401 è apparso nella console su una chiamata autenticata, ma non ha bloccato il flusso renderizzato.

Cline

Installazione

Installa globalmente con:

• npm install -g cline

Autenticazione

Scrivendo `cline auth` puoi selezionare il tuo account Cline o proseguire con il provider desiderato.

Rapporto sull'Attività

Cline ha totalizzato un backend del 60% in 648 secondi, nel cluster principale. Si tratta di un grande cambiamento rispetto all'esecuzione precedente, dove il suo limite di otto errori aveva terminato la build prematuramente lasciando un frontend vuoto. Qui ha completato l'intero stack.

Comportamento del Backend

Autenticazione, CRUD ticket, risposte e isolamento dei dati superati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, instradati attraverso un endpoint di aggiornamento unificato. Stabile in tutte e tre le riesecuzioni.

Comportamento dell'UI

Il passaggio di login è fallito per la stessa discrepanza di origine CORS vista in claude-code, su una pagina _11329_9_ che chiamava un backend _11329_10_. Cinque passaggi superati, uno fallito, due bloccati. 75% UI.

Goose

Installazione

Per macOS/Linux/WSL:

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

Rapporto sull'Attività

Goose ha totalizzato un backend del 60% in 553 secondi, nel cluster principale, ma ha consumato 1,06M token in input per arrivarci. Ha completato l'intero stack questa volta, un cambiamento rispetto all'esecuzione precedente in cui la directory del frontend era rimasta vuota.

Comportamento del Backend

Autenticazione, CRUD ticket, risposte e isolamento dei dati superati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, instradati attraverso un endpoint di aggiornamento unificato. Stabile in tutte e tre le riesecuzioni.

Comportamento dell'UI

Il frontend ha superato tutti gli otto passaggi di convalida. 100% UI, in aumento dallo 0% dell'esecuzione precedente.

Scopri altri nostri benchmark e approfondimenti basati sui dati nella Ricerca Google.

Aggiungi come fonte preferita

Strumenti di codifica IA

Gli strumenti di codifica IA possono essere raggruppati in tre categorie:

• CLI agentica: Strumenti per flussi di lavoro di sviluppo basati su terminale, generano, modificano e rifattorizzano codice tramite prompt e interazioni a riga di comando.
  •  Esempi: Aider, Junie, Opencode, Claude Code, Codex

• Editor di codice IA: Conosciuti anche come IDE agentici, questi strumenti forniscono un'interfaccia GUI simile a VS Code (la maggior parte è costruita su VS Code).
  • Esempi: Antigravity, Cursor, Kiro Code, Windsurf

• Strumenti prompt-to-app: Piattaforme low-code/no-code per costruire app utilizzando prompt in linguaggio naturale e flussi di lavoro visuali.
  • Esempi: Bolt, Lovable, v0.dev, Firebase Studio, Dazl

Strumenti di revisione del codice IA

Man mano che il codice generato dall'IA diventa più comune, gli strumenti di revisione del codice sono essenziali per individuare bug e vulnerabilità. Abbiamo valutato i migliori strumenti su 309 PR nel nostro benchmark RevEval.

Cosa possono fare gli strumenti CLI agentici?

Tra strumenti come Codex, Junie, Kiro e Claude Code, le funzionalità comuni includono:

• Lavoro sul codice end-to-end: Creare e modificare file, correggere bug, rifattorizzare codice ed eseguire test o linter direttamente dal terminale.
• Flussi di lavoro agentici: Eseguire attività multi-step come concatenamento di attività, risoluzione dei problemi, ricerca e debugging iterativo.
• Git e gestione del progetto: Revisionare la cronologia, risolvere merge, gestire branch e creare commit o pull request.
• Esecuzione di command e automazione: Eseguire comandi shell, automatizzare analisi e tradurre il linguaggio naturale in operazioni CLI complesse.
• Gestione approfondita del contesto: Operare su interi repository con consapevolezza delle dipendenze e della struttura del progetto.
• Flessibilità del modello: Supportare più modelli cloud e, in alcuni casi, locali; alcuni strumenti consentono di usare la propria chiave API o di scegliere tra diversi piani.
• Accesso sandbox o controllato: Offrire modalità che vanno dalla sola lettura all'automazione completa, spesso con ambienti isolati per la sicurezza.

Metodologia

Benchmark A-CODE-CLI

Abbiamo valutato gli agenti in una configurazione di esecuzione one-shot per misurare la capacità autonoma senza intervento umano. Gli agenti sono stati poi valutati utilizzando test fumogeni di backend e frontend per misurare la prontezza dell'infrastruttura e la correttezza comportamentale.

Configurazione del modello. Tutti gli 11 agenti sono stati eseguiti su Claude Sonnet 4.6 (non-reasoning). Due agenti hanno richiesto un proxy per raggiungere questo modello:

• Codex (CLI OpenAI) non può puntare nativamente ai modelli Anthropic. È stato instradato attraverso un gateway LiteLLM verso OpenRouter/Anthropic, con uno shim di cache che ripristina la cache dei prompt. Il proxy rimuove i token di reasoning (costo in capacità) e aggiunge latenza.
• Gemini CLI non può chiamare nativamente i modelli Anthropic. È stata instradata attraverso uno shim SSE e un gateway LiteLLM. Le sue chiamate ai modelli ausiliari (rilevamento dei loop, riparazione di strumenti malformati, compressione del contesto) falliscono o restituiscono contenuti non validi attraverso il proxy, quindi è stata eseguita senza le sue reti di sicurezza.

Forge ha richiesto un proxy separato per rimuovere i blocchi di pensiero esteso dalle risposte, che Forge abilita forzatamente e che causano errori 400 quando rimbalzano indietro. Tutti gli altri agenti hanno usato Sonnet 4.6 direttamente tramite la loro configurazione provider nativa o OpenRouter.

Il proxy può solo penalizzare codex e gemini-cli, mai gonfiarli. I loro punteggi sono conservativi.

Junie co-esegue un helper GPT-4.1-mini non sovrascrivibile insieme al primario Sonnet 4.6. È l'unico agente con un secondo modello attivo durante la build. I suoi punteggi portano un asterisco multi-modello.

Claude Code è stato eseguito tramite abbonamento utente (OAuth). Kiro è stato eseguito su crediti ospitati da Kiro (con backend Bedrock, moltiplicatore 1,3x).

Nessun agente ha avuto parametri di temperatura, retry o reasoning modificati. Ciascuno è stato eseguito con la sua configurazione predefinita.

Punteggio. Backend: fumogeno funzionale (adaptive_avg_step_pass_rate). Frontend: fumogeno UI tramite Playwright. Combinato: 0,7 × backend + 0,3 × frontend (per agenti con dati UI completi). Il punteggio backend è l'asse di classificazione primario. Le prestazioni del frontend saturano in tutto il gruppo.

Aider t-3 e t-4. Entrambe le attività hanno prodotto backend che andavano in crash all'avvio. Confermato su due build fresche (stessi errori: _11329_12_ su _11329_13_ in t-3, _11329_14_ su _11329_15_ in t-4). Punteggio 0 con flag _11329_16_, non escluso.

Per la metodologia di valutazione, visita: Metodologia del benchmark di codifica IA

Versioni CLI (esecuzione benchmark giugno 2026)

Versioni lette dai box VPS del benchmark. L'esecuzione della build è stata effettuata dal 5 all'8 giugno 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

Metodologia del radicamento nella ricerca web

Due indagini: un audit sulla migrazione Unity (indagine 2) e un audit sulle versioni Next.js/React (indagine 3). A ciascuna è stato chiesto all'agente di riportare versione, stato e cronologia per funzionalità specifiche del framework e citare un URL ufficiale per ogni affermazione.

La valutazione ha utilizzato due metodi paralleli. Verifica con verità di base: un'affermazione ottiene punteggio solo se l'URL citato appare nel registro di recupero reale dell'agente E la pagina recuperata contiene il fatto, misurato rispetto a una chiave di risposta verificata. Classificazione comportamentale: un giudice LLM ha letto l'intera trascrizione di ciascun agente e lo ha assegnato a una delle quattro categorie comportamentali. La classificazione comportamentale è l'output primario; le tabelle di accuratezza con punteggio saranno pubblicate dopo che la chiave di risposta avrà completato la sua revisione umana di ancoraggio.

Gli agenti con ricerca integrata (Codex, Gemini, Grok) sono stati eseguiti sui loro modelli nativi perché l'attività richiede la loro capacità di ricerca integrata. I restanti otto sono stati eseguiti su Claude Sonnet 4.6. N=1.

Metodologia della compattazione del contesto

Gli agenti hanno ricevuto circa 112.000 token di documenti riempitivi contenenti 13 fatti di infrastruttura inventati. Dopo che l'agente ha letto i documenti e compattato il suo contesto, abbiamo eliminato i file sorgente prima di porre qualsiasi domanda. Punteggio: corrispondenza esatta con i 13 valori inventati, automatizzata da uno script di valutazione con una regex per fatto. N=3.

Gli agenti che hanno totalizzato 13/13 con i file presenti e 0/13 con i file eliminati sono classificati come ri-lettori. Gli agenti che hanno totalizzato 13/13 con i file eliminati sono classificati come veri conservatori. L'eliminazione dei file esclude la rilettura; i fatti inventati escludono il richiamo dai dati di addestramento.

Tutti gli agenti tranne Codex (GPT-5.5) e Gemini (Gemini 2.5 Pro) sono stati eseguiti su Sonnet 4.6. Il modello utilizzato per agente è elencato nella tabella dei risultati.

Approfondisci

Per chi esplora l'ecosistema più ampio degli strumenti di sviluppo agentici, ecco i nostri benchmark più recenti:

• Benchmark MCP: Un confronto dei migliori server MCP per l'accesso web.
• Browser remoti: Come l'infrastruttura browser emergente consente agli agenti IA di interagire con il web in modo sicuro.

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{kalelioglu2026,
  author = {Kalelioğlu, Berk and Dilmegani, Cem},
  title  = {{A-CODE-CLI Bench: Benchmark CLI Agentico}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/agentic-cli}},
  note   = {AIMultiple. Consultato il 29 Giugno 2026}
}

Collegamenti di riferimento

1.

Integration with Codex CLI | OpenRouter | OpenRouter | Documentation

OpenRouter | Documentation

Berk Kalelioğlu

Ricercatore AI

Segui

Berk è un Ricercatore AI presso AIMultiple, concentrandosi su sistemi di IA agentica e modelli linguistici.

Visualizza il profilo completo

Revisionato tecnicamente da

Cem Dilmegani

Analista principale

Segui

Cem è analista principale presso AIMultiple dal 2017. AIMultiple fornisce informazioni a centinaia di migliaia di aziende (secondo SimilarWeb), tra cui il 55% delle aziende Fortune 500, ogni mese. Il lavoro di Cem è stato citato da importanti pubblicazioni globali come Business Insider, Forbes, Washington Post, società globali come Deloitte e HPE, ONG come il World Economic Forum e organizzazioni sovranazionali come la Commissione Europea. È possibile consultare l'elenco di altre aziende e risorse autorevoli che hanno citato AIMultiple. Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, responsabile acquisti tecnologici e imprenditore nel settore tecnologico. Ha fornito consulenza alle aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per oltre un decennio. Ha anche pubblicato un report di McKinsey sulla digitalizzazione. Ha guidato la strategia tecnologica e gli acquisti di un'azienda di telecomunicazioni, riportando direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto un fatturato annuo ricorrente a 7 cifre e una valutazione a 9 cifre partendo da zero in soli 2 anni. Il lavoro di Cem in Hypatos è stato oggetto di articoli su importanti pubblicazioni tecnologiche come TechCrunch e Business Insider. Cem partecipa regolarmente come relatore a conferenze internazionali di settore. Si è laureato in ingegneria informatica presso l'Università di Bogazici e ha conseguito un MBA presso la Columbia Business School.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento