A-CODE-CLI Bench: Benchmark CLI Agentici

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 sottoposto a benchmark i principali strumenti in 10 scenari reali di sviluppo web, eseguendo ~600 controlli di validazione atomici per agente e più di ~5.000 esecuzioni totali di test automatizzati, inclusi logica backend, funzionalità frontend e verifica della coerenza multi-esecuzione.

Risultati del benchmark CLI agentici

Approfondimenti sulle prestazioni degli strumenti CLI Agentici

La correttezza del backend determina la classifica; il punteggio combinato la pondera 0.7 rispetto a 0.3 del frontend.

• Tutti e nove gli agenti eseguiti correttamente utilizzano lo stesso Sonnet 4.6, eppure il backend varia dal 77.3% di Opencode al 55.4% di Goose. Quel divario di 22 punti deriva interamente dall'orchestrazione.
• Un backend forte non garantisce un buon piazzamento: Cline (4° nel backend, 69.5%) e Forge (5°, 67.2%) si classificano vicino alla vetta nel backend ma arrancano 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 100% perfetto. Qui viene eseguito tramite un proxy per raggiungere il modello comune, il che potrebbe penalizzarne le capacità, quindi è probabile che questo sia un limite inferiore piuttosto che il vero backend dell'agente.¹ Anche Gemini, eseguito tramite proxy, è limitato allo stesso modo.
• La posizione nella classifica di build non predice il comportamento: l'agente in testa qui non conserva nulla dopo la compattazione, mentre un agente di metà classifica conserva tutto.

Velocità, utilizzo di token e costo vs 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 task (USD), ciascuno tracciato rispetto al punteggio combinato di accuratezza:

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

• Opencode vince su tutti e tre i fronti contemporaneamente: miglior punteggio combinato (81.6%), il costo più basso tra tutti gli agenti capaci ($1.03 per task), tra i token più ridotti e le esecuzioni più veloci. Inverte il solito 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 comprano un 74.7% di metà classifica ed è 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) atterrano entrambi a metà classifica. La spesa extra compra ripetizioni e ri-validazioni, non profondità di risoluzione dei problemi.
• I numeri dei token dipendono principalmente dalla cache. Codex, Claude Code, Cline, Opencode, Gemini e Grok mettono in cache 86–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 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 limite inferiore (fatturati a credito, più vicini a $2.23); il 64.4% di Cline include quattro task dove ha raggiunto il limite di errori prima di consegnare un frontend, ciascuno 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 impieghi per compiti 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 contesto
2. Intraprendere azione
3. Verificare i risultati

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

Il ciclo è influenzato da due fonti:

• L'utente umano, che fornisce il task 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 deve pianificare, quando eseguire comandi, come validare 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 agentiche impongono diverse strategie di pianificazione, politiche di ripetizione e logiche di verifica. Alcuni agenti privilegiano precisione e ragionamento più approfondito a 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 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 approfondiscono ulteriormente. Eseguono lo stesso test a modello comune su ricerca web e compattazione del contesto, dove i divari non sono di 13 punti ma la differenza tra trovare la risposta giusta e inventarne una sbagliata.

Ancoraggio alla ricerca web

Abbiamo chiesto a ogni agente di verificare la documentazione di 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 corrente e pubblicata. Rispondere dai dati di addestramento produce una risposta sicura ma sbagliata. Abbiamo controllato una cosa: l'agente ha effettivamente recuperato la pagina che ha citato?

Quattro agenti dispongono di ricerca web integrata. Tre di loro (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 schemi.

• Ricerca live reale Codex, Claude Code, Gemini e Grok recuperano pagine aggiornate e colgono cambiamenti recenti. Codex è stato l'unico agente a raggiungere il forum degli sviluppatori, dove risiedono i fatti più difficili.
• Cerca, ma atterra su pagine obsolete 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 nella verifica Next.js. Le pagine citate non esistono. La sua dichiarazione conclusiva: "ogni cella proviene da una pagina effettivamente recuperata durante questa sessione."

Nella verifica 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 rispetto a quelle fabbricate, così gli agenti onesti appaiono come barre verdi piene e Forge come una singola 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 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 si allunga, l'agente compatta il suo contesto: sostituisce la cronologia dettagliata con un breve riassunto ed elimina gli originali. Abbiamo testato se il riassunto 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 ha compattato. Abbiamo quindi eliminato i file sorgente e chiesto tutti i 13 fatti. Con i file eliminati, l'unica fonte possibile è il riassunto 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 mentre potevano ancora rileggere i file. Stavano rileggendo a ogni richiesta. Quando i file sono spariti, hanno scritto "sconosciuto" anziché tirare a indovinare.

Goose, Forge, Opencode e Kiro eseguono tutti 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 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 sotto 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 riassuntore di Aider comprime i turni di chat, non i contenuti dei file aggiunti alla sessione, che è dove risiedevano i fatti. Junie non ha alcuna funzionalità di compattazione.

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Comportamenti degli agenti sul task 6

Abbiamo valutato gli agenti su 10 task. Di seguito è riportata una scomposizione dettagliata del Task 6 per mostrare come diverse architetture CLI si comportano sotto gli stessi vincoli quando tutte vengono eseguite sullo stesso modello.

Task 6: Sistema di ticket helpdesk (Web)

Il Task 6 richiedeva la creazione 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 accessi tra utenti)
• Backend FastAPI
• Frontend React/Vue/Svelte + Vite
• Comandi di esecuzione deterministici

Il test di fumo 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

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

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

• Backend 60%, sette agenti (codex, claude-code, cline, grok, goose, junie, opencode): identici sei passaggi falliti in tutte e tre le riesecuzioni. Auth, CRUD ticket, risposte e isolamento dei dati superati; entrambi i fallimenti riguardavano _11329_0_ e /tickets/{id}/status, dove hanno costruito un unico PATCH /tickets/{id} invece delle route separate delle specifiche. Logica di business corretta, contratto REST sbagliato. Nell'esecuzione nativa precedente su Gemini 3 Pro, Opencode ha costruito gli endpoint separati e 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 ha funzionato, ma la creazione dei ticket stessa è fallita, quindi ogni passaggio dipendente è collassato 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 è mai partito (health check fallito). Gli altri dieci agenti hanno ripetuto identicamente a ogni riesecuzione.
• UI all'interno del cluster 60%: claude-code e cline hanno fallito il login con un identico bug CORS, il frontend chiamava il backend su localhost:8000 da un'origine 127.0.0.1 e il browser lo bloccava, quindi entrambi hanno ottenuto 75%; gli altri cinque hanno renderizzato ed effettuato il login correttamente al 100%.
• La conclusione è la convergenza: sette diverse CLI sullo stesso modello hanno commesso lo stesso errore di contratto REST, quindi qui il modello domina e l'orchestrazione conta a malapena, 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 continuare con il tuo Account ChatGPT, o con la tua chiave API OpenAI. Nessuna opzione provider disponibile.

Report del Task

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

Comportamento Backend

Autenticazione, CRUD ticket, risposte e isolamento dei dati superati. I sei fallimenti riguardavano 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 restituivano 404. Stabile in tutte e tre le riesecuzioni.

Comportamento UI

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

Junie

Installazione

Junie è disponibile tramite JetBrains Toolbox o come CLI standalone:

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

Autenticazione

Continua 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.

Report del Task

Junie ha prodotto un sistema full-stack completo in 444 secondi e ha ottenuto 60% nel backend, nel cluster principale. Il suo input effettivo su questo task è 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 Backend

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

Comportamento UI

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

Kiro CLI

Installazione

Per macOS/Linux/WSL:

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

AppImage Linux 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 continuare con il tuo piano Kiro-Code. Nessuna opzione provider disponibile.

Report del Task

Kiro è l'unico agente il cui punteggio riflette instabilità piuttosto che una singola scelta di design. Il suo 24.4% nel backend è una media su tre riesecuzioni che hanno prodotto tre risultati diversi. La build stessa era solida quando funzionava; il problema è che non funzionava allo stesso modo due volte.

Comportamento Backend

Nella prima esecuzione, Kiro ha superato nove dei sedici passaggi, lo stesso profilo del cluster 60%, fallendo solo le route di assegnazione e stato. Nella seconda esecuzione ne ha superati due. Nella terza il backend non è mai partito e persino l'health check è fallito. In media, questo fa 24.4%. È l'instabilità, non il design degli endpoint, a separare Kiro dal cluster qui.

Comportamento UI

Quando il backend era attivo, il frontend ha superato tutti gli otto passaggi di validazione. 100% UI. Questo è un cambiamento rispetto all'esecuzione precedente, dove il modulo di login non veniva renderizzato 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:

• 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.

Report del Task

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

Comportamento Backend

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

Comportamento UI

Il passaggio di login è fallito. Il frontend chiamava il backend su localhost:8000 mentre la pagina era servita da un'origine 127.0.0.1, e il browser bloccava la richiesta di login sotto 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 chiave API nel tuo ambiente con:

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

Report del Task

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

Comportamento Backend

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

Comportamento UI

Il passaggio di login è fallito per la stessa mancata corrispondenza di origine CORS osservata 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

Report del Task

Opencode guida il benchmark complessivo, ma sul Task 6 ha ottenuto 60% nel backend, nel cluster principale, in 542 secondi. Questa è la più chiara prova singola dell'influenza del modello in questo articolo. Nell'esecuzione nativa precedente su Gemini 3 Pro Preview, Opencode ha costruito gli endpoint separati delle specifiche e ottenuto 93.3% qui. La stessa CLI su Sonnet 4.6 ha scelto l'endpoint unificato ed è scesa al 60%. Lo strumento non è cambiato; il modello sì.

Comportamento Backend

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

Comportamento UI

Il frontend ha superato tutti gli otto passaggi di validazione. 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-…"

Report del Task

Grok è arrivato secondo complessivamente nel benchmark di build con 75.4% nel backend. Sul Task 6 ha ottenuto 60% nel backend in 433 secondi, nel cluster principale. In questa esecuzione Grok ha raggiunto Sonnet 4.6 tramite OpenRouter.

Comportamento Backend

Nove dei sedici passaggi superati: autenticazione, CRUD ticket, risposte e isolamento dei dati. I sei fallimenti riguardavano i passaggi di assegnazione e transizione di stato, che puntavano a /tickets/{id}/assign e /tickets/{id}/status. Grok ha instradato entrambi attraverso un endpoint di aggiornamento unificato, quindi quelle chiamate e i controlli di ruolo che ne dipendono restituivano 404. Stabile in tutte e tre le riesecuzioni.

Comportamento UI

Il frontend ha superato tutti gli otto passaggi di validazione. Login e 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 credenziali del tuo provider in modo interattivo con:

• forge provider login

E scegli il tuo provider.

Report del Task

Forge ha ottenuto 13.3% nel backend in 844 secondi. Il suo conteggio di token 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 dei ticket ed è collassata a cascata.

Comportamento Backend

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

Comportamento UI

Il passaggio di login è fallito per la stessa mancata corrispondenza di origine CORS osservata 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 (Google OAuth): 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.

Report del Task

Gemini CLI ha ottenuto 13.3% nel backend in 926 secondi, uno dei due agenti più lenti del gruppo. L'autenticazione ha funzionato, ma la creazione dei ticket è fallita ed è collassata 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 Backend

Due passaggi superati. 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 UI

Il frontend ha superato tutti gli otto passaggi di validazione. 100% UI, in aumento dal 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 continuare con il provider desiderato.

Report del Task

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

Comportamento Backend

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

Comportamento UI

Il passaggio di login è fallito per la stessa mancata corrispondenza di origine CORS osservata in claude-code, su una pagina 127.0.0.1 che chiama un backend localhost. 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

Report del Task

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

Comportamento Backend

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

Comportamento UI

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

Strumenti di codifica IA

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

• CLI Agentiche: Strumenti per flussi di lavoro di sviluppo basati su terminale, generano, modificano e rifattorizzano il 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 grafica simile a VS Code (la maggior parte sono costruiti su VS Code).
  • Esempi: Antigravity, Cursor, Kiro Code, Windsurf

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

Strumenti di revisione 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 capacità comuni includono:

• Lavoro di codice end-to-end: Creare e modificare file, correggere bug, rifattorizzare il codice ed eseguire test o linter direttamente dal terminale.
• Flussi di lavoro agentici: Eseguire compiti multi-step come concatenamento di task, risoluzione dei problemi, ricerca e debugging iterativo.
• Git e gestione progetti: Rivedere 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 profonda del contesto: Operare su repository completi con consapevolezza delle dipendenze e della struttura del progetto.
• Flessibilità di modello: Supportare molteplici modelli cloud e, in alcuni casi, locali; alcuni strumenti consentono di utilizzare la propria chiave API o scegliere tra 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 con una configurazione a esecuzione singola per misurare la capacità autonoma senza intervento umano. Gli agenti sono stati poi valutati utilizzando test di fumo 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 elimina i token di ragionamento (costo in capacità) e aggiunge latenza.
• Gemini CLI non può chiamare nativamente i modelli Anthropic. È stato instradato attraverso uno shim SSE e un gateway LiteLLM. Le sue chiamate ai modelli ausiliari (rilevamento loop, riparazione tool malformati, compressione del contesto) falliscono o restituiscono contenuti non validi attraverso il proxy, quindi è stato eseguito senza le sue reti di sicurezza.

Forge ha richiesto un proxy separato per eliminare i blocchi di pensiero esteso dalle risposte, che Forge abilita forzatamente e che causano errori 400 quando rinviati. Tutti gli altri agenti hanno utilizzato Sonnet 4.6 direttamente tramite la loro configurazione nativa del provider 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 a Sonnet 4.6 primario. È 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, ripetizione o ragionamento modificati. Ciascuno ha eseguito la sua configurazione predefinita.

Punteggio. Backend: test di fumo funzionale (adaptive_avg_step_pass_rate). Frontend: test di fumo 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 frontend saturano in tutto il gruppo.

Aider t-3 e t-4. Entrambi i task hanno prodotto backend che andavano in crash all'avvio. Confermato su due build pulite (stessi errori: TypeError su class Card in t-3, AmbiguousForeignKeysError su User.auctions in t-4). Punteggio 0 con flag backend_never_ready, non escluso.

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

Versioni CLI (esecuzione benchmark giugno 2026)

Versioni lette dalle macchine VPS del benchmark. L'esecuzione di build è stata eseguita 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 di ancoraggio alla ricerca web

Due verifiche: un audit di migrazione Unity (verifica 2) e un audit di versione Next.js/React (verifica 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 riferimento: 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 l'ha assegnata 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é il task richiede la loro capacità di ricerca integrata. I restanti otto sono stati eseguiti su Claude Sonnet 4.6. N=1.

Metodologia di compattazione del contesto

Gli agenti hanno ricevuto circa 112.000 token di documenti riempitivi contenenti 13 fatti infrastrutturali 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 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) sono stati eseguiti su Sonnet 4.6. Il modello utilizzato per agente è elencato nella tabella dei risultati.

Leggi di più

Per coloro che esplorano l'ecosistema più ampio degli strumenti agentici per sviluppatori, ecco i nostri ultimi benchmark:

• 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{kaleliolu2026,
  author = {Kalelioğlu, Berk and Dilmegani, Cem},
  title  = {{A-CODE-CLI Bench: Benchmark CLI Agentici}},
  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

Berk Kalelioğlu

Ricercatore AI

Segui

Berk è un Ricercatore AI presso AIMultiple, specializzato in 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