A-CODE-CLI Bench: Benchmark dei CLI agentici
Gli strumenti CLI agentici sono strumenti di codifica IA in grado di 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 più di circa 5.000 esecuzioni di test automatizzate totali, tra cui logica backend, funzionalità frontend e verifica della coerenza multi-esecuzione.
Risultati del benchmark dei CLI agentici
Approfondimenti sulle prestazioni degli strumenti CLI agentici
La correttezza del backend determina la classifica; il punteggio combinato la pondera 0.7 rispetto al 0.3 del frontend.
- Tutti i nove agenti che girano correttamente usano lo stesso Sonnet 4.6, eppure il backend varia dal Opencode 77.3% al Goose 55.4%. Quel divario di 22 punti deriva interamente dall'orchestrazione.
- Una forte prestazione backend non garantisce un ottimo piazzamento finale: Cline (4° nel backend, 69.5%) e Forge (5°, 67.2%) sono vicini alla vetta nel backend ma restano molto indietro nel frontend; Cline 52.5% è il più debole del gruppo, quindi entrambi scivolano nella classifica combinata.
- Codex si classifica 10° nel backend (52.1%) nonostante un frontend perfetto del 100%. Qui gira tramite un proxy per raggiungere il modello comune, il che potrebbe penalizzarne le capacità, quindi è probabile che sia un limite minimo piuttosto che il vero backend dell'agente.1 Gemini, anch'esso eseguito tramite un proxy, è limitato allo stesso modo.
- La posizione nella build non predice il comportamento: l'agente che guida qui non conserva nulla dopo la compattazione, mentre un agente a metà classifica conserva tutto.
Velocità, utilizzo dei token e costo rispetto al punteggio
Abbiamo valutato l'efficienza di esecuzione usando il tempo di esecuzione medio (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 è veloce, economico o leggero in termini di token non predice quanto bene ottiene il punteggio.
- Opencode vince su tutti e tre contemporaneamente: punteggio combinato più alto (81.6%), costo più basso tra gli agenti capaci ($1,03 per attività), tra i token più bassi e le esecuzioni più veloci. Inverte il solito compromesso accuratezza-costo.
- Il costo varia di 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 nella creazione dei ticket. I $7,58 di Junie comprano un 74.7% a metà classifica e rappresentano un limite superiore gonfiato.
- Goose paga di più per il minimo: secondo più caro a $3,23, eppure il punteggio pulito più basso del gruppo (62.5%). I primi tre per punteggio restano economici (Opencode $1,03, Claude Code $1,83, Grok $2,03).
- Né l'agente più veloce né quello più lento vince: Kiro (439s) e Gemini (1.158s, overhead del proxy) si collocano entrambi a metà classifica. La spesa extra acquista nuovi tentativi e ri-validazioni, non profondità di risoluzione dei problemi.
- I numeri dei token riguardano soprattutto la cache. Codex, Claude Code, Cline, Opencode, Gemini e Grok mettono in cache l'86–98% del loro input, quindi i 4.18M token lordi di Claude Code si riducono a un effettivo 115k. Junie, Goose, Kiro, Forge e Aider non usano la cache, quindi pagano per ogni token che inviano di nuovo; ecco perché i 2.36M di Junie sono i più alti del gruppo.
- Tre avvertenze sui numeri: per i cinque agenti che non usano la cache, l'input effettivo è tutto ciò che hanno inviato, quindi va letto come un tetto massimo; i $1,72 di Kiro sono un limite minimo (fatturati come credito, più vicini a $2,23); il 64.4% di Cline include quattro attività in cui ha raggiunto il limite di errori prima di consegnare un frontend, ciascuna valutata 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 che può essere svolto tramite comandi shell.
Questi agenti operano tipicamente in un ciclo composto da tre fasi:
- Raccogliere il contesto
- Intraprendere un'azione
- Verificare i risultati
Dopo la verifica, l'agente raccoglie il contesto aggiornato e ripete il ciclo finché non completa l'attività o raggiunge 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 agentico fornisce struttura attorno al modello. Definisce come il modello dovrebbe pianificare, quando dovrebbe eseguire comandi, come dovrebbe convalidare i risultati e quali strumenti sono disponibili. Questi strumenti possono includere l'esecuzione di shell, l'accesso al file system, il controllo del browser, l'uso del computer, le integrazioni MCP o “competenze” riutilizzabili.
Architetture agente diverse impongono strategie di pianificazione, politiche di retry e logiche di verifica diverse. Alcuni agenti privilegiano precisione e ragionamento più profondo a costo di un maggiore utilizzo di token e latenza. Altri privilegiano velocità e costi inferiori con minore robustezza comportamentale.
Intelligenza del modello vs architettura dell'agente
Le differenze di prestazioni tra gli strumenti CLI agentici non derivano da un'unica fonte. Emergono da due livelli: il modello di fondazione e il framework di orchestrazione che lo avvolge.
Questo benchmark testa entrambi gli agenti sullo stesso modello di fondazione: Claude Sonnet 4.6. Qualsiasi differenza di punteggio è quindi una differenza di orchestrazione: come la CLI raccoglie il contesto, quando esegue i comandi, come convalida l'output e se riprova dopo un errore.
Opencode e Claude Code usano entrambi direttamente Sonnet 4.6. Opencode ottiene 77.3% nel backend; Claude Code ottiene 74.9%. Due agenti, stesso modello, 2.4 punti percentuali di differenza nella correttezza del backend. Kiro e Opencode usano entrambi Sonnet 4.6. Kiro ottiene 64.2% nel backend; Opencode ottiene 77.3%. Il divario di 13 punti è il contributo della CLI.
I due benchmark osservativi qui sotto spingono ulteriormente questo concetto. Eseguono lo stesso test sul modello comune su ricerca web e compattazione del contesto, dove i divari non sono 13 punti ma la differenza tra trovare la risposta giusta e inventarne una sbagliata.
Grounding nella ricerca web
Abbiamo chiesto a ogni agente di verificare la documentazione dei 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 la verifica 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 pubblicata e attuale. Rispondere dai dati di addestramento produce una risposta sicura ma errata. Abbiamo controllato una cosa: l'agente ha davvero recuperato la pagina che ha citato?
Quattro agenti dispongono di ricerca web integrata. Tre di essi (Codex, Gemini, Grok) hanno girato sui loro modelli nativi non-Sonnet; gli altri otto, incluso Claude Code, hanno girato su Sonnet 4.6.
Sono emersi quattro modelli.
- Ricerca dal vivo 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 finisce 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, risposte dall'addestramento Aider non naviga e lo dice. Questa è la risposta onesta.
- Fonti inventate Forge non ha recuperato nulla che funzionasse, eppure ha citato 31 fonti nella verifica su Next.js. Le pagine citate non esistono. La sua dichiarazione finale: “ogni cella proviene da una pagina effettivamente recuperata durante questa sessione.”
Nella verifica su Next.js, ogni altro agente con navigazione ha ancorato quasi tutte le sue citazioni a pagine che aveva effettivamente recuperato. Forge non ne ha ancorata nessuna. Il grafico sovrappone le citazioni ancorate di ciascun agente a quelle inventate, quindi gli agenti onesti appaiono come barre verdi piene e Forge come un'unica barra rossa. Il grafico copre gli otto agenti con un log 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 hanno girato entrambi 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 revisione. Tratteniamo le tabelle di accuratezza finché la chiave non è finalizzata.
Compattazione del contesto
Quando una sessione diventa lunga, l'agente compatta il suo contesto: sostituisce la cronologia dettagliata con un breve riepilogo e scarta gli originali. Abbiamo verificato se il riepilogo conserva ciò che conta.
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 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 ottenuto 0 dalla memoria avevano risposto 13 su 13 solo finché potevano rileggere i file. Rileggevano a ogni richiesta. Quando i file non c'erano più, hanno scritto “sconosciuto” invece di indovinare.
Goose, Forge, Opencode e Kiro girano tutti su Sonnet 4.6. Kiro ha conservato tutti i 13. 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 di build elevate e compattazione elevata sono proprietà indipendenti.
Quattro agenti sono rimasti fuori dall'ambito di questo test, ciascuno per un motivo concreto. Cline non è riuscito a raggiungere la sua soglia di compattazione. Abbiamo creato un set di documenti da 863.000 token e gli abbiamo fatto leggere ogni file, ma cline tronca ogni output dello strumento 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 questo protocollo piuttosto che stimare un numero. Grok ha un comando di compattazione, ma ha letto i nostri documenti in frammenti anziché caricarli per intero, quindi non c'è mai stato un contesto completo da compattare. Il riepilogatore di Aider comprime i turni di chat, non il contenuto dei file aggiunti alla sessione, che è dove risiedevano i fatti. Junie non ha alcuna funzionalità di compattazione.
Comportamenti degli agenti nell'attività 6
Abbiamo valutato gli agenti in 10 attività. Di seguito è riportato un dettaglio dell'Attività 6 per mostrare come diverse architetture CLI si comportano sotto gli stessi vincoli quando tutte girano sullo stesso modello.
Attività 6: Sistema di ticket per helpdesk (Web)
L'Attività 6 richiedeva la creazione di un sistema di ticket per 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 l'accesso tra utenti)
- Backend FastAPI
- Frontend React/Vue/Svelte + Vite
- Comandi di esecuzione deterministici
Il test smoke ha convalidato:
- Controllo di salute
- Autenticazione a doppio ruolo
- Operazioni CRUD sui ticket
- Assegnazione e risposte
- Transizioni di stato
- Applicazione dei ruoli
- Isolamento dei dati
- Login dell'interfaccia utente 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à.
Con un unico modello, il campo si è diviso in tre gruppi.
- 60% nel backend, sette agenti (codex, claude-code, cline, grok, goose, junie, opencode): identici sei passaggi falliti in tutte e tre le riesecuzioni. Auth, CRUD dei ticket, risposte e isolamento dei dati sono passati; entrambi i fallimenti erano su
/tickets/{id}/assigne/tickets/{id}/status, dove hanno costruito unPATCH /tickets/{id}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 ottenuto 93.3%; su Sonnet 4.6 ha scelto il design unificato come gli altri. - 13.3%, tre agenti (aider, forge, gemini-cli): l'autenticazione funzionava, ma la creazione stessa dei ticket falliva, quindi ogni passaggio dipendente è crollato a cascata.
- 24.4%, Kiro: instabilità, non un unico modo di guasto. Ha superato nove passaggi nella prima esecuzione, due nella seconda e nella terza il backend non è mai partito (controllo di salute fallito). Gli altri dieci agenti hanno ripetuto in modo identico a ogni riesecuzione.
- UI all'interno del cluster 60%: claude-code e cline hanno fallito il login per un identico bug CORS, il frontend ha chiamato il backend su
localhost:8000da un'origine127.0.0.1e il browser lo ha bloccato, quindi entrambi hanno ottenuto 75%; gli altri cinque hanno renderizzato e effettuato l'accesso senza problemi 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, al contrario dei benchmark osservativi 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 continuare con il tuo account ChatGPT oppure con la tua OpenAI API Key. Nessuna opzione provider disponibile.
Rapporto sull'attività
Codex ha costruito un sistema funzionante in 454 secondi ed è finito nel cluster 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 dei ticket, risposte e isolamento dei dati sono passati. 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'interfaccia utente
Il frontend ha superato tutti gli otto passaggi di convalida. Lo stato di login e post-login si è comportato correttamente. UI 100%.
Junie
Installazione
Junie è disponibile tramite JetBrains Toolbox o come CLI autonoma:
- curl -fsSL https://junie.jetbrains.com/install | bash
Autenticazione
Continua con il tuo account JetBrains oppure genera una JUNIE_API_KEY su junie.jetbrains.com/cli, oppure esporta la tua API key da Anthropic, OpenAI, Google o altri provider supportati. Sono disponibili più opzioni provider.
Rapporto sull'attività
Junie ha prodotto un sistema full-stack completo in 444 secondi e ha ottenuto il 60% nel backend, nel cluster principale. Il suo input effettivo in questa attività è il più alto del gruppo con 1.52M, un limite superiore senza cache influenzato da un bug noto di contabilizzazione della cache (vedi la nota nella tabella dei risultati).
Comportamento del backend
Nove dei sedici passaggi sono passati: autenticazione, CRUD dei ticket, risposte e isolamento dei dati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato. Junie ha gestito stato e assegnazione tramite un endpoint di aggiornamento unificato, quindi le route della specifica `/tickets/{id}/assign` e `/tickets/{id}/status` hanno restituito 404. La logica di transizione in sé era corretta. Stabile in tutte e tre le riesecuzioni.
Comportamento dell'interfaccia utente
Il frontend ha superato tutti gli otto passaggi di convalida. UI 100%.
Kiro CLI
Installazione
Per macOS/Linux/WSL:
- curl -fsSL https://cli.kiro.dev/install | bash
AppImage Linux alternativo (opzione portatile):
- Download: 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 continuare con il tuo piano Kiro-Code. Nessuna opzione provider disponibile.
Rapporto sull'attività
Kiro è l'unico agente il cui punteggio riflette l'instabilità piuttosto che una singola scelta progettuale. Il suo 24.4% nel backend è una media su tre riesecuzioni che hanno prodotto tre esiti diversi. La build in sé era solida quando girava; il problema è che non girava allo stesso modo due volte.
Comportamento del backend
Alla prima esecuzione, Kiro ha superato nove passaggi su sedici, lo stesso profilo del cluster 60%, fallendo solo le route di assegnazione e stato. Alla seconda ne ha superati due. Alla terza il backend non è mai partito e persino il controllo di salute è fallito. Mediato, questo è 24.4%. L'instabilità, non il design degli endpoint, è ciò che separa Kiro dal cluster in questo caso.
Comportamento dell'interfaccia utente
Quando il backend era attivo, il frontend ha superato tutti gli otto passaggi di convalida. UI 100%. Si tratta di un cambiamento rispetto all'esecuzione precedente, in cui il modulo di login non riusciva a renderizzare a causa di un 422 al montaggio.
Claude Code
Installazione
Per macOS/Linux/WSL, considerando il tuo gestore di pacchetti preferito, puoi installare Claude Code con uno dei seguenti comandi:
- curl -fsSL https://claude.ai/install.sh | bash
- npm install -g @anthropic-ai/claude-code
Autenticazione
Dopo aver configurato Claude Code, puoi continuare con il tuo account Claude. Nessuna opzione provider disponibile.
Rapporto sull'attività
Claude Code ha ottenuto il 60% nel backend in 379 secondi, nel cluster principale. Si tratta di un netto miglioramento rispetto all'esecuzione precedente, in cui un bug di convalida JWT restituiva 401 su ogni rotta autenticata e falliva 13 passaggi su 16. In questa esecuzione il backend ha funzionato; la perdita è stata sull'interfaccia utente.
Comportamento del backend
Autenticazione, CRUD dei ticket, risposte e isolamento dei dati sono passati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, instradati tramite un endpoint di aggiornamento unificato invece dei percorsi separati della specifica. Stabile in tutte e tre le riesecuzioni.
Comportamento dell'interfaccia utente
Il passaggio di login è fallito. Il frontend ha chiamato il backend su localhost:8000 mentre la pagina era servita da un'origine 127.0.0.1, e il browser ha bloccato la richiesta di login per la policy CORS. Cinque passaggi sono passati, uno è fallito, due sono stati bloccati. UI 75%. Cline è fallito allo stesso modo.
Aider
Installazione
Se hai già installato Python 3.8-3.13, installa prima 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 con 236 secondi e il più leggero, con 1.3k token di input e 18k di output. Ha anche ottenuto il 13.3% nel backend. L'autenticazione funzionava, ma la creazione dei ticket falliva e ogni passaggio che richiedeva un ticket esistente falliva di conseguenza.
Comportamento del backend
Sono passati due passaggi. La build si è rotta alla creazione dei ticket, quindi gli elenchi di 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. Si tratta di una classe di errore diversa dal cluster 60%, che creava i ticket correttamente e mancava solo le route di assegnazione e stato.
Comportamento dell'interfaccia utente
Il passaggio di login è fallito a causa della stessa mancata corrispondenza di origine CORS vista in claude-code e cline. Cinque passaggi sono passati, uno è fallito, due sono stati bloccati. UI 75%.
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 guida il benchmark complessivo, ma nell'Attività 6 ha ottenuto il 60% nel backend, nel cluster principale, in 542 secondi. Questa è la prova più chiara dell'influenza del modello nell'articolo. Nell'esecuzione precedente su modello nativo Gemini 3 Pro Preview, Opencode ha costruito gli endpoint separati della specifica e ha ottenuto 93.3% qui. La stessa CLI su Sonnet 4.6 ha scelto l'endpoint unificato ed è sceso a 60%. Lo strumento non è cambiato; è cambiato il modello.
Comportamento del backend
Autenticazione, CRUD dei ticket, risposte e isolamento dei dati sono passati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, instradati tramite un endpoint di aggiornamento unificato. Stabile in tutte e tre le riesecuzioni.
Comportamento dell'interfaccia utente
Il frontend ha superato tutti gli otto passaggi di convalida. UI 100%.
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 oppure imposta una API key per l'uso headless:
- export XAI_API_KEY=”xai-…”
Rapporto sull'attività
Grok è arrivato secondo in assoluto nel benchmark di build con il 75.4% nel backend. Nell'Attività 6 ha ottenuto il 60% nel backend in 433 secondi, nel cluster principale. In questa esecuzione Grok ha raggiunto Sonnet 4.6 tramite OpenRouter.
Comportamento del backend
Nove dei sedici passaggi sono passati: autenticazione, CRUD dei ticket, risposte e isolamento dei dati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, che puntavano a /tickets/{id}/assign e /tickets/{id}/status. Grok ha instradato entrambi tramite 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'interfaccia utente
Il frontend ha superato tutti gli otto passaggi di convalida. Lo stato di login e post-login si è comportato correttamente. UI 100%.
Forge
Installazione
Per macOS/Linux/WSL:
- curl -fsSL https://forgecode.dev/cli | sh
Autenticazione
Configura le credenziali del provider in modo interattivo con:
- forge provider login
E scegli il tuo provider.
Rapporto sull'attività
Forge ha ottenuto il 13.3% nel backend in 844 secondi. Il suo conteggio di token di output è il più basso del gruppo con 1.6k, il che indica un'implementazione superficiale. Come nell'esecuzione precedente, la build si è rotta alla creazione dei ticket ed è crollata a cascata.
Comportamento del backend
Sono passati due passaggi. La creazione dei ticket è fallita, quindi elenchi di ticket, risposte, assegnazione, transizioni di stato e controlli dei ruoli sono tutti falliti di conseguenza. Stabile in tutte e tre le riesecuzioni, lo stesso profilo 13.3% di aider e gemini-cli.
Comportamento dell'interfaccia utente
Il passaggio di login è fallito a causa della stessa mancata corrispondenza di origine CORS vista in claude-code, cline e aider. Cinque passaggi sono passati, uno è fallito, due sono stati bloccati. UI 75%.
Gemini CLI
Installazione
Esegui immediatamente:
- npx @google/gemini-cli
Oppure installa globalmente:
- npm install -g @google/gemini-cli
- brew install gemini-cli
Autenticazione
Opzione 1 (OAuth Google): esporta GOOGLE_CLOUD_PROJECT=”YOUR_PROJECT_ID” quindi avvia gemini.
Opzione 2 (API key): esporta GEMINI_API_KEY=”YOUR_API_KEY” quindi avvia gemini.
Opzione 3 (Vertex IA): esporta GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true.
Rapporto sull'attività
Gemini CLI ha ottenuto il 13.3% nel backend in 926 secondi, uno dei due agenti più lenti del gruppo. L'autenticazione funzionava, ma la creazione dei ticket falliva e crollava a cascata. Il suo frontend, che era fallito del tutto nell'esecuzione precedente a causa di un'incompatibilità tra Node 18 e Vite 7, questa volta ha superato ogni passaggio.
Comportamento del backend
Sono passati due passaggi. La creazione dei ticket è fallita, quindi tutti i passaggi dipendenti sono falliti. Stabile in tutte e tre le riesecuzioni, lo stesso profilo 13.3% di aider e forge.
Comportamento dell'interfaccia utente
Il frontend ha superato tutti gli otto passaggi di convalida. UI 100%, in aumento rispetto al 0% dell'esecuzione precedente. Un 401 è apparso nella console in una chiamata autenticata, ma non ha bloccato il flusso renderizzato.
Cline
Installazione
Installa globalmente con:
- npm install -g cline
Autenticazione
Digitando `cline auth` puoi selezionare il tuo account Cline o continuare con il provider desiderato.
Rapporto sull'attività
Cline ha ottenuto il 60% nel backend in 648 secondi, nel cluster principale. Si tratta di un grande cambiamento rispetto all'esecuzione precedente, in cui il limite di otto errori ha terminato anticipatamente la build lasciando un frontend vuoto. Qui ha completato l'intero stack.
Comportamento del backend
Autenticazione, CRUD dei ticket, risposte e isolamento dei dati sono passati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, instradati tramite un endpoint di aggiornamento unificato. Stabile in tutte e tre le riesecuzioni.
Comportamento dell'interfaccia utente
Il passaggio di login è fallito a causa della stessa mancata corrispondenza di origine CORS vista in claude-code, con una pagina 127.0.0.1 che chiamava un backend localhost. Cinque passaggi sono passati, uno è fallito, due sono stati bloccati. UI 75%.
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 ottenuto il 60% nel backend in 553 secondi, nel cluster principale, ma ha consumato 1.06M token di input per arrivarci. Ha completato l'intero stack questa volta, un cambiamento rispetto all'esecuzione precedente in cui la directory del frontend è rimasta vuota.
Comportamento del backend
Autenticazione, CRUD dei ticket, risposte e isolamento dei dati sono passati. I sei fallimenti erano i passaggi di assegnazione e transizione di stato, instradati tramite un endpoint di aggiornamento unificato. Stabile in tutte e tre le riesecuzioni.
Comportamento dell'interfaccia utente
Il frontend ha superato tutti gli otto passaggi di convalida. UI 100%, in aumento rispetto al 0% dell'esecuzione precedente.
Aggiungi come fonte preferitaStrumenti di codifica IA
Gli strumenti di codifica IA possono essere raggruppati in tre categorie:
- CLI agentici: strumenti per flussi di lavoro di sviluppo basati su terminale, generano, modificano e rifattorizzano il codice tramite prompt e interazioni da riga di comando.
- Esempi: Aider, Junie, Opencode, Claude Code, Codex
- Editor di codice IA: Conosciuti anche come IDE agentici, questi strumenti forniscono una GUI simile a VS Code (la maggior parte sono costruiti su VS Code).
- Esempi: Antigravity, Cursor, Kiro Code, Windsurf
- Builder da prompt ad app: Piattaforme low-code/no-code per creare app usando prompt in linguaggio naturale e flussi di lavoro visivi.
- Esempi: Bolt, Lovable, v0.dev, Firebase Studio, Dazl
Strumenti di revisione del codice IA
Poiché il codice generato dall'IA diventa sempre 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 gli strumenti come Codex, Junie, Kiro e Claude Code, le capacità comuni includono:
- Lavoro sul codice end-to-end: Crea e modifica file, correggi bug, rifattorizza il codice ed esegui test o linter direttamente dal terminale.
- Flussi di lavoro agentici: Esegui attività multi-passaggio come concatenazione di attività, risoluzione dei problemi, ricerca e debug iterativo.
- Git e gestione dei progetti: Esamina la cronologia, risolvi i merge, gestisci i rami e crea commit o pull request.
- Esecuzione di Command e automazione: Esegui comandi shell, automatizza le analisi e traduci il linguaggio naturale in operazioni CLI complesse.
- Gestione profonda del contesto: Opera su repository completi con consapevolezza delle dipendenze e della struttura del progetto.
- Flessibilità del modello: Supporta più modelli cloud e, in alcuni casi, locali; alcuni strumenti consentono di utilizzare la propria API key o di scegliere tra piani.
- Accesso sandbox o controllato: Offrono modalità che vanno dalla sola lettura all'automazione completa, spesso con ambienti isolati per sicurezza.
Metodologia
Benchmark A-CODE-CLI
Abbiamo valutato gli agenti con una configurazione di esecuzione one-shot per misurare la capacità autonoma senza intervento umano. Gli agenti sono stati poi valutati usando test smoke di backend e frontend per misurare la prontezza dell'infrastruttura e la correttezza comportamentale.
Configurazione del modello. Tutti gli 11 agenti hanno girato su Claude Sonnet 4.6 (non-reasoning). Due agenti hanno richiesto un proxy per raggiungere questo modello:
- Codex (OpenAI CLI) non può puntare nativamente ai modelli Anthropic. È stato instradato tramite un gateway LiteLLM verso OpenRouter/Anthropic, con uno shim di cache che ripristina la cache dei prompt. Il proxy rimuove i token di ragionamento (costo di capacità) e aggiunge latenza.
- Gemini CLI non può chiamare nativamente i modelli Anthropic. È stato instradato tramite uno shim SSE e un gateway LiteLLM. Le sue chiamate ausiliarie al modello (rilevamento dei loop, riparazione di strumenti malformati, compressione del contesto) falliscono o restituiscono contenuti non validi attraverso il proxy, quindi ha girato senza le proprie reti di sicurezza.
Forge ha richiesto un proxy separato per eliminare i blocchi di pensiero esteso dalle risposte, che Forge forza e che causano errori 400 quando rinviati. 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 prudenti.
Junie esegue in parallelo un helper GPT-4.1-mini non sovrascrivibile accanto al modello 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 ha girato tramite abbonamento utente (OAuth). Kiro ha girato su crediti ospitati da Kiro (basati su Bedrock, moltiplicatore 1.3x).
Nessun agente ha avuto parametri di temperatura, retry o ragionamento ottimizzati. Ciascuno ha eseguito la sua configurazione predefinita.
Punteggio. Backend: smoke funzionale (adaptive_avg_step_pass_rate). Frontend: smoke dell'interfaccia utente tramite Playwright. Combinato: 0.7 × backend + 0.3 × frontend (per gli agenti con dati UI completi). Il punteggio backend è l'asse di classificazione primario. Le prestazioni 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: TypeError su class Card in t-3, AmbiguousForeignKeysError su User.auctions in t-4). Valutati 0 con un flag backend_never_ready, non esclusi.
Per la metodologia di valutazione, visita: Metodologia del benchmark di codifica IA
Versioni delle CLI (esecuzione del benchmark di giugno 2026)
Versioni lette dalle macchine VPS del benchmark. L'esecuzione della build è avvenuta 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 grounding della ricerca web
Due sonde: un audit sulla migrazione di Unity (sonda 2) e un audit sulle versioni Next.js/React (sonda 3). A ciascuna è stato chiesto all'agente di riportare versione, stato e tempistica per le funzionalità specifiche del framework e di citare un URL ufficiale per ogni affermazione.
La valutazione ha usato due metodi paralleli. Gating di ground-truth: un'affermazione ottiene punti solo se l'URL citato compare nel log 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 l'ha assegnata a una delle quattro categorie comportamentali. La classificazione comportamentale è l'output primario; le tabelle di accuratezza con punteggi saranno pubblicate dopo che la chiave di risposta avrà completato la revisione umana di ancoraggio.
Gli agenti con ricerca integrata (Codex, Gemini, Grok) hanno girato sui loro modelli nativi perché l'attività richiede la loro capacità di ricerca integrata. I restanti otto hanno girato su Claude Sonnet 4.6. N=1.
Metodologia della compattazione del contesto
Gli agenti hanno ricevuto circa 112.000 token di documenti filler contenenti 13 fatti infrastrutturali inventati. Dopo che l'agente aveva letto i documenti e compattato il suo contesto, abbiamo eliminato i file sorgente prima di porre qualsiasi domanda. Punteggio: corrispondenza esatta con 13 valori inventati, automatizzata da uno script di valutazione con una regex per fatto. N=3.
Gli agenti che hanno ottenuto 13/13 con i file presenti e 0/13 con i file eliminati sono classificati come rilettori. Gli agenti che hanno ottenuto 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) hanno girato su Sonnet 4.6. Il modello usato per ciascun agente è elencato nella tabella dei risultati.
Ulteriori letture
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 dei CLI agentici}},
year = {2026},
month = jun,
howpublished = {\url{https://aimultiple.com/agentic-cli}},
note = {AIMultiple. Consultato il 29 Giugno 2026}
}Risultati e timestamp di 139 punti dati. Scarica i dati utilizzati in questo articolo come file ZIP contenente 4 file CSV e un README.
Registro delle modifiche
21 aggiornamenti- 2026
Aggiunta, una frase all'introduzione, chiarendo che tutti gli agenti sono stati eseguiti sullo stesso modello.
Aggiornata la sezione Metodologia, fornendo una spiegazione più dettagliata della configurazione del modello, del punteggio e delle versioni CLI utilizzate, offrendo ai lettori una comprensione più chiara dell'impostazione sperimentale.
Espansa la metodologia di benchmark nell'introduzione, offrendo una comprensione più chiara del rigore dei test.
Rimossa la metodologia dettagliata, riducendo la lunghezza dell'articolo.
Aggiornata la formattazione delle intestazioni per una migliore leggibilità e coerenza.
Ridotto l'ambito del benchmark nell'introduzione, fornendo ai lettori una comprensione più accurata dell'ampiezza della valutazione.
Ampliata la sezione Metodologia, fornendo un resoconto dettagliato della configurazione di valutazione, delle configurazioni del modello e dei meccanismi di punteggio per gli agenti.
Aggiornata l'introduzione, la sezione 'Pool di progetti e configurazioni del modello', la sezione 'Liste di controllo funzionali (audit lato browser)', la sezione 'Esempio di attività di benchmark: dashboard della piattaforma di e-learning', la sezione 'Ambito del progetto e stack tecnologico', la sezione 'Risultati dettagliati del benchmark: prestazioni di Kiro vs Gemini CLI Kiro (95% di successo)', la sezione 'Come visto sopra, Kiro ha fornito un'interfaccia utente di livello professionale con
Espansa la sezione 'Cosa sono gli agenti di codifica basati su CLI?', fornendo una spiegazione più dettagliata delle loro capacità e benefici per i lettori.
Aggiornata l'Introduzione, fornendo una panoramica più chiara dell'ambito e della metodologia del benchmark.
Aggiunta una frase alla sezione Metodologia, chiarendo come gli strumenti CLI sono stati richiesti per un benchmark più equo.
- 2025
Ampliata la sezione Metodologia, fornendo un caso di studio dettagliato del progetto 'EduSphere', offrendo ai lettori una comprensione più approfondita dell'applicazione e dei risultati del benchmark.
Aggiunto, Risultati all'articolo, fornendo ai lettori un'analisi delle prestazioni degli strumenti e della metodologia utilizzata.
Aggiornata l'introduzione, sezione "Esplora i principali strumenti CLI agentici per ottimizzare ed elevare il tuo flusso di lavoro di modifica del codice", per chiarire la definizione e l'ambito degli strumenti CLI agentici.
Rimossi i dettagli dalla sezione 'Gestione output e contesto', semplificando la descrizione delle prestazioni e della gestione del contesto di Claude Code.
Spostati Claude Code e Cline CLI, nelle descrizioni dei prodotti, per migliorare il flusso logico delle informazioni.
Aggiunti Gemini CLI, OpenHands, Cline CLI e Codex CLI alla sezione 'Agenti di codifica basati su CLI', fornendo ai lettori informazioni su quattro nuovi strumenti.
Rimossa la sezione 'Casi d'uso migliori', riducendo le informazioni sulle applicazioni ideali di Claude Code.
Aggiornata l'introduzione per riflettere meglio l'attenzione dell'articolo sui principali strumenti CLI agentici.
Aggiornata l'Introduzione, fornendo ai lettori esempi attuali di modelli linguistici di grandi dimensioni.
Aggiornata la descrizione degli 'agenti di codifica basati su CLI' nella sezione 'strumenti di codifica AI', fornendo una comprensione più chiara della loro funzione.
Collegamenti di riferimento
Il lavoro di Cem presso AIMultiple è stato citato da importanti testate internazionali tra cui Business Insider, Forbes, Morning Brew e Washington Post, da aziende globali come Deloitte e HPE, da ONG come il World Economic Forum e da organizzazioni sovranazionali come la Commissione europea. [1], [2], [3], [4], [5]
Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente tecnologico e imprenditore tecnologico. Ha consigliato le aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per più di un decennio. Ha inoltre pubblicato un report McKinsey sulla digitalizzazione.
Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto ricavi ricorrenti annuali a 7 cifre e una valutazione a 9 cifre partendo da zero in 2 anni. Il lavoro di Cem in Hypatos è stato ripreso da importanti testate tecnologiche come TechCrunch e Business Insider.
Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato come ingegnere informatico presso l'Università di Bogazici e possiede un MBA della Columbia Business School.
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.