A-CODE-CLI Bench: Benchmark de CLI Agentic

Ferramentas CLI agentic são ferramentas de codificação com IA que podem criar e excluir arquivos, executar comandos, planejar e executar a codificação de todo o projeto. Comparamos as principais ferramentas em 10 cenários reais de desenvolvimento web, realizando ~600 verificações de validação atômicas por agente e mais de ~5.000 execuções de teste automatizadas no total, incluindo lógica de backend, funcionalidade de frontend e verificação de consistência em múltiplas execuções.

Resultados do benchmark de CLI agentic

Insights de Desempenho das ferramentas CLI Agentic

A correção do backend impulsiona o ranking; a pontuação combinada o pondera em 0,7 e o frontend em 0,3.

• Todos os nove agentes com execução limpa usam o mesmo Sonnet 4.6, mas o backend varia de Opencode com 77,3% até Goose com 55,4%. Essa diferença de 22 pontos vem inteiramente da orquestração.
• Um backend forte não garante uma boa classificação final: Cline (4º no backend, 69,5%) e Forge (5º, 67,2%) estão perto do topo no backend, mas ficam muito atrás no frontend, o Cline com 52,5% é o mais fraco do grupo, então ambos caem na tabela combinada.
• Codex fica em 10º no backend (52,1%) apesar de um frontend perfeito de 100%. Ele executa aqui através de um proxy para alcançar o modelo comum, o que pode prejudicar suas capacidades, então isso provavelmente é um piso, não o verdadeiro backend do agente.¹ Gemini, também executado através de um proxy, é limitado da mesma forma.
• A classificação na construção não prevê o comportamento: o agente que lidera aqui não retém nada após a compactação, enquanto um agente intermediário retém tudo.

Velocidade, uso de tokens e custo vs pontuação

Avaliamos a eficiência de execução usando o tempo médio de execução (segundos), uso efetivo de tokens (entrada + saída) e custo por tarefa (USD), cada um plotado contra a pontuação de precisão combinada:

O quão rápido, barato ou leve em tokens um agente é não prevê o seu desempenho.

• Opencode vence nos três critérios de uma vez: maior pontuação combinada (81,6%), o menor custo entre os agentes capazes ($1,03 por tarefa), entre os que usam menos tokens e com execuções mais rápidas. Ele inverte a troca usual de precisão por custo.
• O custo varia cerca de 40x, de Forge $0,18 a Junie $7,58, sem relação com a classificação. Forge é o mais barato porque faz o mínimo: seu backend falha na criação de tickets. Os $7,58 do Junie compram um intermediário 74,7% e são um limite superior inflado.
• Goose paga mais pelo menor resultado: segundo mais caro a $3,23, mas com a menor pontuação limpa do grupo (62,5%). Os três primeiros em pontuação permanecem baratos (Opencode $1,03, Claude Code $1,83, Grok $2,03).
• Nem o mais rápido nem o mais lento vencem: Kiro (439s) e Gemini (1.158s, sobrecarga do proxy) ambos ficam no meio do pelotão. Gastos extras compram retentativas e revalidação, não profundidade na resolução de problemas.
• Os números de tokens são principalmente sobre cache. Codex, Claude Code, Cline, Opencode, Gemini e Grok armazenam em cache 86–98% de sua entrada, então os 4,18M de tokens brutos do Claude Code se reduzem a 115k efetivos. Junie, Goose, Kiro, Forge e Aider não usam cache, então pagam por cada token que reenviam; é por isso que os 2,36M do Junie são os mais altos do grupo.
• Três ressalvas sobre os números: para os cinco agentes sem cache, a entrada efetiva é tudo o que eles enviaram, então leia como um teto; os $1,72 do Kiro são um piso (cobrança por crédito, mais próximo de $2,23); os 64,4% do Cline incluem quatro tarefas onde ele atingiu seu limite de erro antes de entregar um frontend, cada uma com pontuação 0.

Você pode ver nossa metodologia abaixo.

Como funcionam as ferramentas CLI agentic

Ferramentas CLI agentic são agentes autônomos que operam dentro do terminal. Embora a maioria dos usuários as utilize para tarefas de codificação, elas podem executar qualquer fluxo de trabalho que possa ser realizado via comandos de shell.

Esses agentes normalmente operam em um loop que consiste em três fases:

1. Coletar contexto
2. Executar ação
3. Verificar resultados

Após a verificação, o agente coleta contexto atualizado e repete o loop até concluir a tarefa ou atingir uma condição de parada.

O loop é influenciado por duas fontes:

• O usuário humano, que fornece a tarefa inicial e pode interromper a execução
• O modelo, que realiza planejamento, raciocínio e seleção de ações

O framework de agente fornece estrutura em torno do modelo. Ele define como o modelo deve planejar, quando deve executar comandos, como deve validar resultados e quais ferramentas estão disponíveis. Essas ferramentas podem incluir execução de shell, acesso ao sistema de arquivos, controle de navegador, uso do computador, integrações MCP ou “habilidades” reutilizáveis.

Diferentes arquiteturas de agente impõem diferentes estratégias de planejamento, políticas de retentativa e lógica de verificação. Alguns agentes priorizam precisão e raciocínio mais profundo ao custo de maior uso de tokens e latência. Outros priorizam velocidade e menor custo com menor robustez comportamental.

Inteligência do modelo vs arquitetura do agente

As diferenças de desempenho entre as ferramentas CLI agentic não vêm de uma única fonte. Elas emergem de duas camadas: o modelo de fundação e o framework de orquestração que o envolve.

Este benchmark testa ambos os agentes no mesmo modelo de fundação: Claude Sonnet 4.6. Qualquer diferença na pontuação é, portanto, uma diferença na orquestração: como a CLI coleta contexto, quando executa comandos, como valida a saída e se tenta novamente após falha.

Opencode e Claude Code ambos usam Sonnet 4.6 diretamente. Opencode pontua 77,3% no backend; Claude Code pontua 74,9%. Dois agentes, mesmo modelo, 2,4 pontos percentuais de diferença na correção de backend. Kiro e Opencode ambos usam Sonnet 4.6. Kiro pontua 64,2% no backend; Opencode pontua 77,3%. A lacuna de 13 pontos é a contribuição da CLI.

Os dois benchmarks observatórios abaixo levam isso adiante. Eles executam o mesmo teste de modelo comum em pesquisa na web e compactação de contexto, onde as lacunas não são 13 pontos, mas a diferença entre encontrar a resposta certa e inventar uma errada.

Fundamentação em pesquisa na web

Pedimos a cada agente que auditasse a documentação de um framework: qual versão introduziu um recurso, qual é seu status atual e o que mudou recentemente. Cada resposta tinha que citar uma fonte oficial. Executamos a sondagem duas vezes, uma no Unity e outra no Next.js/React. Os fatos foram selecionados de forma que a resposta correta só exista em uma página atual e publicada. Responder a partir dos dados de treinamento produz uma resposta confiante e errada. Verificamos uma coisa: o agente realmente buscou a página que citou?

Quatro agentes possuem busca na web integrada. Três deles (Codex, Gemini, Grok) executaram em seus modelos nativos não-Sonnet; os outros oito, incluindo o Claude Code, executaram no Sonnet 4.6.

Quatro padrões emergiram.

• Busca ao vivo real Codex, Claude Code, Gemini e Grok buscam páginas atuais e capturam mudanças recentes. Codex foi o único agente que chegou ao fórum de desenvolvedores, onde residem os fatos mais difíceis.
• Busca, mas encontra páginas antigas Cline buscou duas dúzias de páginas de documentação reais e ainda reportou uma versão que havia sido substituída. As buscas foram reais; as páginas estavam desatualizadas.
• Sem busca, responde pelo treinamento Aider não navega e declara isso. Esta é a resposta honesta.
• Fontes fabricadas Forge não buscou nada que funcionasse, mesmo assim citou 31 fontes na sondagem do Next.js. As páginas citadas não existem. Sua declaração final: “cada célula é proveniente de uma página realmente buscada durante esta sessão.”

Na sondagem do Next.js, todos os outros agentes com navegação fundamentaram quase todas as suas citações em páginas que eles realmente buscaram. O Forge não fundamentou nenhuma. O gráfico empilha as citações fundamentadas de cada agente contra as fabricadas, de modo que os agentes honestos aparecem como barras verdes cheias e o Forge como uma única barra vermelha. O gráfico cobre os oito agentes com um log de fetch por URL verificável. Grok (busca do lado do servidor), Gemini (execução truncada) e Aider (sem citações) aparecem na tabela acima, mas são excluídos aqui.

Cline e Claude Code ambos executaram no Sonnet 4.6 neste teste. O Claude Code encontrou e abriu a página com a resposta correta. O Cline não. Mesmo modelo, resultado diferente.

Pontuamos cada resposta quanto à precisão factual, mas essas pontuações dependem de uma chave de respostas atualmente sob revisão. Estamos retendo as tabelas de precisão até que a chave seja finalizada.

Compactação de contexto

Quando uma sessão se torna longa, o agente compacta seu contexto: ele substitui o histórico detalhado por um breve resumo e descarta os originais. Testamos se o resumo retém o que importa.

Demos a cada agente aproximadamente 112.000 tokens de documentos com 13 fatos inventados incorporados: um PIN de plantão, uma região de nuvem, uma tag de build e mais dez. Inventados significa que os valores são strings únicas sem presença nos dados de treinamento. O agente leu os documentos e compactou. Em seguida, excluímos os arquivos de origem e pedimos todos os 13 fatos. Com os arquivos excluídos, a única fonte possível é o resumo da compactação.

Quatro agentes retiveram todos os fatos. Três não retiveram nenhum. Os três que pontuaram 0 apenas de memória tinham respondido 13 de 13 enquanto ainda podiam reler os arquivos. Eles estavam relendo a cada consulta. Quando os arquivos desapareceram, escreveram “desconhecido” em vez de adivinhar.

Goose, Forge, Opencode e Kiro todos executam Sonnet 4.6. Kiro reteve todos os 13. Os outros três não retiveram nenhum. Mesmo modelo, resultado oposto.

Opencode ocupa o primeiro lugar no benchmark de construção e não retém nada na compactação. Kiro ocupa o sétimo lugar no benchmark de construção e retém tudo na compactação. Forte desempenho na construção e forte compactação são propriedades independentes.

Quatro agentes ficaram fora do escopo deste teste, cada um por um motivo concreto. Cline não pôde ser levado ao seu limiar de compactação. Construímos um conjunto de documentos de 863.000 tokens e o fizemos ler todos os arquivos, mas o cline trunca cada saída de ferramenta para cerca de 2.000 caracteres, então os documentos colapsaram em pré-visualizações curtas. Seu contexto estabilizou em 214.000 tokens, 21% de sua janela de um milhão de tokens, e a compactação nunca foi acionada. Reportamos o cline como não mensurável sob este protocolo em vez de estimar um número. Grok tem um comando de compactação, mas leu nossos documentos em fragmentos em vez de carregá-los integralmente, então nunca houve um contexto completo para ele compactar. O sumarizador do Aider comprime turnos de chat, não o conteúdo dos arquivos adicionados à sessão, que é onde os fatos residiam. Junie não possui funcionalidade de compactação.

Comportamentos dos agentes na tarefa 6

Avaliamos os agentes em 10 tarefas. Abaixo está uma análise detalhada da Tarefa 6 para mostrar como diferentes arquiteturas de CLI se comportam sob as mesmas restrições quando todas executam no mesmo modelo.

Tarefa 6: Sistema de tickets de helpdesk (Web)

A Tarefa 6 exigiu a construção de um sistema de tickets de helpdesk full-stack com:

• Dois papéis de usuário (cliente e agente)
• Autenticação baseada em JWT
• Transições estritas de fluxo de trabalho de status
• Isolamento de dados (404 em vez de 403 para acesso entre usuários)
• Backend FastAPI
• Frontend React/Vue/Svelte + Vite
• Comandos de execução determinísticos

O teste de fumaça validou:

• Verificação de saúde
• Autenticação de dois papéis
• Operações CRUD de tickets
• Atribuição e respostas
• Transições de status
• Aplicação de papéis
• Isolamento de dados
• Login na UI e comportamento pós-login

Esta tarefa estressa o gerenciamento de estado, a correção da autenticação, a disciplina de contrato REST e a integração frontend-backend. Visite o GitHub para ver os detalhes da tarefa.

Em um único modelo, o grupo se dividiu em três grupos.

• 60% backend, sete agentes (codex, claude-code, cline, grok, goose, junie, opencode): seis etapas idênticas falharam em todas as três reexecuções. Autenticação, CRUD de tickets, respostas e isolamento de dados passaram; ambas as falhas foram em _11329_0_ e _11329_1_, onde eles construíram um _11329_2_ unificado em vez das rotas separadas da especificação. Lógica de negócio correta, contrato REST errado. Na execução nativa anterior no Gemini 3 Pro, o Opencode construiu os endpoints separados e pontuou 93,3%; no Sonnet 4.6 ele escolheu o design unificado como os demais.
• 13,3%, três agentes (aider, forge, gemini-cli): a autenticação funcionou, mas a criação de tickets em si falhou, então cada etapa dependente entrou em cascata.
• 24,4%, Kiro: instabilidade, não um único modo de falha. Ele passou nove etapas na primeira execução, duas na segunda e, na terceira, o backend nunca iniciou (verificação de saúde falhou). Os outros dez agentes repetiram de forma idêntica em cada reexecução.
• UI dentro do cluster de 60%: claude-code e cline falharam no login com um bug CORS idêntico, o frontend chamou o backend em _11329_3_ de uma origem _11329_4_ e o navegador bloqueou, então ambos pontuaram 75%; os outros cinco renderizaram e fizeram login perfeitamente com 100%.
• A conclusão é convergência: sete CLIs diferentes no mesmo modelo cometeram o mesmo erro de contrato REST, então aqui o modelo domina e a orquestração quase não importa, o inverso dos benchmarks observatórios abaixo.

Codex

Instalação

Instale globalmente com:

• npm install -g @openai/codex

Alternativamente, instale globalmente com Homebrew (macOS/Linux)

• brew install –cask codex

Autenticação

Após configurar o Codex, você pode continuar com sua Conta ChatGPT, ou com sua OpenAI API Key. Nenhuma opção de provedor disponível.

Relatório da Tarefa

Codex construiu um sistema funcional em 454 segundos e ficou no cluster de 60%. A lógica de negócio estava correta; ele perdeu o contrato REST em atribuição e status, como o resto do grupo.

Comportamento do Backend

Autenticação, CRUD de tickets, respostas e isolamento de dados passaram. As seis falhas foram as etapas de atribuição e transição de status, que visavam `/tickets/{id}/assign` e `/tickets/{id}/status`. Codex roteou ambos por um endpoint de atualização unificado, então essas chamadas retornaram 404. Estável em todas as três reexecuções.

Comportamento da UI

Frontend passou em todas as oito etapas de validação. Login e estado pós-login se comportaram corretamente. 100% UI.

Junie

Instalação

Junie está disponível através do JetBrains Toolbox ou como uma CLI autônoma:

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

Autenticação

Continue com sua conta JetBrains ou gere uma JUNIE_API_KEY em junie.jetbrains.com/cli, ou exporte sua própria chave de API da Anthropic, OpenAI, Google ou outros provedores suportados. Múltiplas opções de provedor disponíveis.

Relatório da Tarefa

Junie produziu um sistema full-stack completo em 444 segundos e pontuou 60% no backend, no cluster principal. Sua entrada efetiva nesta tarefa é a mais alta do grupo, com 1,52M, um limite superior sem cache afetado por um bug conhecido de contabilização de cache (veja a nota da tabela de resultados).

Comportamento do Backend

Nove das dezesseis etapas passaram: autenticação, CRUD de tickets, respostas e isolamento de dados. As seis falhas foram as etapas de atribuição e transição de status. Junie manipulou status e atribuição através de um endpoint de atualização unificado, então as rotas `/tickets/{id}/assign` e `/tickets/{id}/status` da especificação retornaram 404. A lógica de transição em si estava correta. Estável em todas as três reexecuções.

Comportamento da UI

Frontend passou em todas as oito etapas de validação. 100% UI.

Kiro CLI

Instalação

Para macOS/Linux/WSL:

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

AppImage Linux alternativa (opção portátil):

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

Então execute:

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

Autenticação

Você pode continuar com seu plano Kiro-Code. Nenhuma opção de provedor disponível.

Relatório da Tarefa

Kiro é o único agente cuja pontuação reflete instabilidade em vez de uma única escolha de design. Seu backend de 24,4% é uma média em três reexecuções que produziram três resultados diferentes. A construção em si era sólida quando executada; o problema foi que não executou da mesma forma duas vezes.

Comportamento do Backend

Na primeira execução, Kiro passou nove das dezesseis etapas, o mesmo perfil do cluster de 60%, falhando apenas nas rotas de atribuição e status. Na segunda execução, passou duas. Na terceira, o backend nunca iniciou e até a verificação de saúde falhou. Em média, isso é 24,4%. A instabilidade, não o design do endpoint, é o que separa Kiro do cluster aqui.

Comportamento da UI

Quando o backend estava ativo, o frontend passou em todas as oito etapas de validação. 100% UI. Isso é uma mudança em relação à execução anterior, onde o formulário de login falhou ao renderizar em um 422 na montagem.

Claude Code

Instalação

Para macOS/Linux/WSL, considerando seu gerenciador de pacotes preferido, você pode instalar o Claude Code com:

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

Autenticação

Após configurar o Claude Code, você pode continuar com sua conta Claude. Nenhuma opção de provedor disponível.

Relatório da Tarefa

Claude Code pontuou 60% no backend em 379 segundos, no cluster principal. Esta é uma melhoria significativa em relação à execução anterior, onde um bug de validação JWT retornou 401 em todas as rotas autenticadas e falhou 13 de 16 etapas. Nesta execução, o backend funcionou; a perda foi na UI.

Comportamento do Backend

Autenticação, CRUD de tickets, respostas e isolamento de dados passaram. As seis falhas foram as etapas de atribuição e transição de status, roteadas através de um endpoint de atualização unificado em vez dos caminhos separados da especificação. Estável em todas as três reexecuções.

Comportamento da UI

A etapa de login falhou. O frontend chamou o backend em _11329_5_ enquanto a página era servida de uma origem _11329_6_, e o navegador bloqueou a solicitação de login sob a política CORS. Cinco etapas passaram, uma falhou, duas foram bloqueadas. 75% UI. Cline falhou da mesma forma.

Aider

Instalação

Se você já tem python 3.8-3.13 instalado, primeiro instale o aider:

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

Autenticação

Faça login na sua conta OpenRouter e autorize, ou exporte sua API Key no seu ambiente com:

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

Relatório da Tarefa

Aider foi o agente mais rápido, com 236 segundos, e o mais leve, com 1,3k tokens de entrada e 18k de saída. Também pontuou 13,3% no backend. A autenticação funcionou, mas a criação de tickets falhou, e cada etapa que precisava de um ticket existente falhou junto.

Comportamento do Backend

Duas etapas passaram. A construção quebrou na criação de tickets, então as listas de tickets de cliente e agente, respostas, atribuição, transições de status e verificações de papel todos entraram em cascata para falha. Estável em todas as três reexecuções. Esta é uma classe de falha diferente do cluster de 60%, que criou tickets corretamente e apenas perdeu as rotas de atribuição e status.

Comportamento da UI

A etapa de login falhou sob a mesma incompatibilidade de origem CORS vista no claude-code e cline. Cinco etapas passaram, uma falhou, duas bloqueadas. 75% UI.

OpenCode

Instalação

Para macOS/Linux/WSL:

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

Instale globalmente com:

• npm i -g opencode-ai

Para macOS/Linux, considerando seu gerenciador de pacotes preferido:

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

Autenticação

Há muitas opções de provedor, selecione seu provedor desejado e autentique-se com /connect

Relatório da Tarefa

Opencode lidera o benchmark geral, mas na Tarefa 6 pontuou 60% no backend, no cluster principal, em 542 segundos. Esta é a evidência mais clara de modelo único no artigo. Na execução anterior com modelo nativo no Gemini 3 Pro Preview, Opencode construiu os endpoints separados da especificação e pontuou 93,3% aqui. A mesma CLI no Sonnet 4.6 escolheu o endpoint unificado e caiu para 60%. A ferramenta não mudou; o modelo sim.

Comportamento do Backend

Autenticação, CRUD de tickets, respostas e isolamento de dados passaram. As seis falhas foram as etapas de atribuição e transição de status, roteadas através de um endpoint de atualização unificado. Estável em todas as três reexecuções.

Comportamento da UI

Frontend passou em todas as oito etapas de validação. 100% UI.

Grok Build

Instalação

Para macOS/Linux:

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

Autenticação

Faça login com sua conta xAI no primeiro lançamento, ou defina uma chave de API para uso headless:

• export XAI_API_KEY=”xai-…”

Relatório da Tarefa

Grok terminou em segundo lugar geral no benchmark de construção com 75,4% no backend. Na Tarefa 6, pontuou 60% no backend em 433 segundos, no cluster principal. Nesta execução, o Grok alcançou o Sonnet 4.6 através do OpenRouter.

Comportamento do Backend

Nove das dezesseis etapas passaram: autenticação, CRUD de tickets, respostas e isolamento de dados. As seis falhas foram as etapas de atribuição e transição de status, que visavam /tickets/{id}/assign e /tickets/{id}/status. Grok roteou ambos por um endpoint de atualização unificado, então essas chamadas e as verificações de papel que dependem delas retornaram 404. Estável em todas as três reexecuções.

Comportamento da UI

Frontend passou em todas as oito etapas de validação. Login e estado pós-login se comportaram corretamente. 100% UI.

Forge

Instalação

Para macOS/Linux/WSL:

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

Autenticação

Configure suas credenciais de provedor interativamente com:

• forge provider login

E escolha seu provedor.

Relatório da Tarefa

Forge pontuou 13,3% no backend em 844 segundos. Sua contagem de tokens de saída é a mais baixa do grupo, com 1,6k, o que aponta para uma implementação superficial. Como na execução anterior, a construção quebrou na criação de tickets e entrou em cascata.

Comportamento do Backend

Duas etapas passaram. A criação de tickets falhou, então as listas de tickets, respostas, atribuição, transições de status e verificações de papel todos falharam junto. Estável em todas as três reexecuções, o mesmo perfil de 13,3% do aider e gemini-cli.

Comportamento da UI

A etapa de login falhou sob a mesma incompatibilidade de origem CORS vista no claude-code, cline e aider. Cinco etapas passaram, uma falhou, duas bloqueadas. 75% UI.

Gemini CLI

Instalação

Execute instantaneamente:

• npx @google/gemini-cli

Ou instale globalmente:

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

Autenticação

Opção 1 (Google OAuth): export GOOGLE_CLOUD_PROJECT=”YOUR_PROJECT_ID” e então inicie o gemini.
Opção 2 (chave de API): export GEMINI_API_KEY=”YOUR_API_KEY” e então inicie o gemini.
Opção 3 (Vertex IA): export GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true.

Relatório da Tarefa

Gemini CLI pontuou 13,3% no backend em 926 segundos, um dos dois agentes mais lentos do grupo. A autenticação funcionou, mas a criação de tickets falhou e entrou em cascata. Seu frontend, que falhou completamente na execução anterior devido a uma incompatibilidade entre Node 18 e Vite 7, passou em todas as etapas desta vez.

Comportamento do Backend

Duas etapas passaram. A criação de tickets falhou, então todas as etapas dependentes falharam. Estável em todas as três reexecuções, o mesmo perfil de 13,3% do aider e forge.

Comportamento da UI

Frontend passou em todas as oito etapas de validação. 100% UI, acima de 0% na execução anterior. Um 401 apareceu no console em uma chamada autenticada, mas não bloqueou o fluxo renderizado.

Cline

Instalação

Instale globalmente com:

• npm install -g cline

Autenticação

Ao escrever `cline auth`, você pode selecionar sua conta Cline ou continuar com seu provedor desejado.

Relatório da Tarefa

Cline pontuou 60% no backend em 648 segundos, no cluster principal. Esta é uma grande mudança em relação à execução anterior, onde seu limite de oito erros encerrou a construção prematuramente e deixou um frontend vazio. Aqui, ele completou a pilha completa.

Comportamento do Backend

Autenticação, CRUD de tickets, respostas e isolamento de dados passaram. As seis falhas foram as etapas de atribuição e transição de status, roteadas através de um endpoint de atualização unificado. Estável em todas as três reexecuções.

Comportamento da UI

A etapa de login falhou sob a mesma incompatibilidade de origem CORS vista no claude-code, em uma página 127.0.0.1 chamando um backend localhost. Cinco etapas passaram, uma falhou, duas bloqueadas. 75% UI.

Goose

Instalação

Para macOS/Linux/WSL:

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

Relatório da Tarefa

Goose pontuou 60% no backend em 553 segundos, no cluster principal, mas consumiu 1,06M tokens de entrada para chegar lá. Ele completou a pilha completa desta vez, uma mudança em relação à execução anterior, onde o diretório do frontend foi deixado vazio.

Comportamento do Backend

Autenticação, CRUD de tickets, respostas e isolamento de dados passaram. As seis falhas foram as etapas de atribuição e transição de status, roteadas através de um endpoint de atualização unificado. Estável em todas as três reexecuções.

Comportamento da UI

Frontend passou em todas as oito etapas de validação. 100% UI, acima de 0% na execução anterior.

Veja mais dos nossos benchmarks e insights baseados em dados na Pesquisa Google.

Adicionar como fonte preferencial

Ferramentas de codificação com IA

Ferramentas de codificação com IA podem ser agrupadas em três categorias:

• CLI Agentic: Ferramentas para fluxos de trabalho de desenvolvimento baseados em terminal, geram, editam e refatoram código através de prompts e interações de linha de comando.
  • Exemplos: Aider, Junie, Opencode, Claude Code, Codex

• Editores de código com IA: Também conhecidos como IDEs agentic, essas ferramentas fornecem uma GUI similar ao VS Code (a maioria delas é construída sobre o VS Code).
  • Exemplos: Antigravity, Cursor, Kiro Code, Windsurf

• Construtores de prompt-para-app: Plataformas low-code/no-code para construir apps usando prompts de linguagem natural e fluxos de trabalho visuais.
  • Exemplos: Bolt, Lovable, v0.dev, Firebase Studio, Dazl

Ferramentas de revisão de código com IA

À medida que o código gerado por IA se torna mais comum, as ferramentas de revisão de código são essenciais para capturar bugs e vulnerabilidades. Avaliamos as principais ferramentas em 309 PRs em nosso benchmark RevEval.

O que as ferramentas CLI agentic podem fazer?

Entre ferramentas como Codex, Junie, Kiro e Claude Code, as capacidades comuns incluem:

• Trabalho de código ponta a ponta: Criar e modificar arquivos, corrigir bugs, refatorar código e executar testes ou linters diretamente do terminal.
• Fluxos de trabalho agentic: Realizar tarefas de múltiplas etapas, como encadeamento de tarefas, solução de problemas, busca e depuração iterativa.
• Git & gerenciamento de projetos: Revisar histórico, resolver merges, gerenciar branches e criar commits ou pull requests.
• Execução de command & automação: Executar comandos shell, automatizar análises e traduzir linguagem natural em operações CLI complexas.
• Manipulação de contexto profundo: Operar em repositórios completos com consciência de dependências e estrutura do projeto.
• Flexibilidade de modelo: Suporta múltiplos modelos em nuvem e, em alguns casos, locais; algumas ferramentas permitem usar sua própria chave de API ou escolher entre planos.
• Acesso em sandbox ou controlado: Oferece modos que variam de somente leitura a automação total, frequentemente com ambientes isolados para segurança.

Metodologia

Benchmark A-CODE-CLI

Avaliamos os agentes sob uma configuração de execução única para medir a capacidade autônoma sem intervenção humana. Os agentes foram então avaliados usando testes de fumaça de backend e frontend para medir a prontidão da infraestrutura e a correção comportamental.

Configuração do modelo. Todos os 11 agentes executaram no Claude Sonnet 4.6 (não raciocinador). Dois agentes precisaram de um proxy para alcançar este modelo:

• Codex (CLI da OpenAI) não pode apontar para modelos da Anthropic nativamente. Ele foi roteado através de um gateway LiteLLM para OpenRouter/Anthropic, com um shim de cache restaurando o prompt caching. O proxy remove tokens de raciocínio (custo de capacidade) e adiciona latência.
• A CLI do Gemini não pode chamar modelos da Anthropic nativamente. Ela foi roteada através de um shim SSE e gateway LiteLLM. Suas chamadas de modelo auxiliares (detecção de loop, reparo de ferramenta malformada, compressão de contexto) falham ou retornam conteúdo inválido através do proxy, então executou sem suas próprias redes de segurança.

Forge exigiu um proxy separado para remover blocos de pensamento estendido das respostas, que o Forge habilita à força e que causam erros 400 quando ecoados de volta. Todos os outros agentes usaram o Sonnet 4.6 diretamente via sua configuração de provedor nativo ou OpenRouter.

O proxy só pode prejudicar o codex e o gemini-cli, nunca inflá-los. Suas pontuações são conservadoras.

Junie co-executa um auxiliar GPT-4.1-mini não substituível junto com o Sonnet 4.6 primário. É o único agente com um segundo modelo ativo durante a construção. Suas pontuações carregam um asterisco de multi-modelo.

Claude Code executou via assinatura de usuário (OAuth). Kiro executou em créditos hospedados pelo Kiro (com suporte Bedrock, multiplicador 1,3x).

Nenhum agente teve parâmetros de temperatura, retentativa ou raciocínio ajustados. Cada um executou sua configuração padrão.

Pontuação. Backend: fumaça funcional (adaptive_avg_step_pass_rate). Frontend: fumaça de UI via Playwright. Combinado: 0,7 × backend + 0,3 × frontend (para agentes com dados de UI completos). A pontuação do backend é o eixo de classificação primário. O desempenho do frontend satura em todo o grupo.

Aider t-3 e t-4. Ambas as tarefas produziram backends que falharam na inicialização. Confirmado em duas construções novas (mesmos erros: TypeError em class Card no t-3, AmbiguousForeignKeysError em User.auctions no t-4). Pontuaram 0 com uma bandeira backend_never_ready, não excluídos.

Para a metodologia de avaliação, visite: Metodologia do benchmark de codificação com IA

Versões da CLI (execução do benchmark de junho de 2026)

Versões lidas das caixas VPS do benchmark. A execução de construção ocorreu de 5 a 8 de junho de 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 de fundamentação em pesquisa na web

Duas sondagens: uma auditoria de migração do Unity (sonda 2) e uma auditoria de versão do Next.js/React (sonda 3). Cada uma pedia ao agente que reportasse versão, status e cronograma para recursos específicos do framework e citasse uma URL oficial por afirmação.

A classificação usou dois métodos paralelos. Portal de verdade fundamental: uma afirmação pontua apenas se a URL citada aparecer no log de fetch real do agente E a página buscada contiver o fato, medido contra uma chave de respostas verificada. Classificação comportamental: um juiz LLM leu a transcrição completa de cada agente e o atribuiu a uma das quatro categorias comportamentais. A classificação comportamental é a saída primária; as tabelas de precisão pontuadas serão publicadas após a chave de respostas completar sua revisão de âncora humana.

Agentes com busca integrada (Codex, Gemini, Grok) executaram em seus modelos nativos porque a tarefa requer sua capacidade de busca integrada. Os oito restantes executaram no Claude Sonnet 4.6. N=1.

Metodologia de compactação de contexto

Os agentes receberam aproximadamente 112.000 tokens de documentos de preenchimento contendo 13 fatos de infraestrutura inventados. Após o agente ler os documentos e compactar seu contexto, excluímos os arquivos de origem antes de fazer qualquer pergunta. Pontuação: correspondência exata contra 13 valores inventados, automatizada por um script de classificação com uma regex por fato. N=3.

Agentes que pontuaram 13/13 com arquivos presentes e 0/13 com arquivos excluídos são classificados como releitores. Agentes que pontuaram 13/13 com arquivos excluídos são classificados como retentores verdadeiros. A exclusão de arquivos descarta a releitura; fatos inventados descartam a recordação de dados de treinamento.

Todos os agentes, exceto Codex (GPT-5.5) e Gemini (Gemini 2.5 Pro), executaram no Sonnet 4.6. O modelo usado por agente está listado na tabela de resultados.

Leia mais

Para aqueles que exploram o ecossistema mais amplo de ferramentas de desenvolvimento agentic, aqui estão nossos benchmarks mais recentes:

• Benchmark de MCP: Uma comparação dos principais servidores MCP para acesso web.
• Navegadores remotos: Como a infraestrutura de navegadores emergente permite que agentes de IA interajam com a web de forma segura.

Cite este benchmark

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

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

Links de referência

1.

Integration with Codex CLI | OpenRouter | OpenRouter | Documentation

OpenRouter | Documentation

Berk Kalelioğlu

Pesquisador de IA

Siga-nos

Berk é um Pesquisador de IA na AIMultiple, com foco em sistemas de IA agentiva e modelos de linguagem.

Ver perfil completo

Revisado tecnicamente por

Cem Dilmegani

Analista Principal

Siga-nos

Cem é o analista principal da AIMultiple desde 2017. A AIMultiple fornece informações para centenas de milhares de empresas (segundo o SimilarWeb), incluindo 55% das empresas da Fortune 500, todos os meses. O trabalho de Cem foi citado por importantes publicações globais, como Business Insider, Forbes e Washington Post, além de empresas globais como Deloitte e HPE, ONGs como o Fórum Econômico Mundial e organizações supranacionais como a Comissão Europeia. Você pode ver mais empresas e recursos renomados que mencionaram a AIMultiple. Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor na área. Ele assessorou empresas em suas decisões tecnológicas na McKinsey & Company e na Altman Solon por mais de uma década. Também publicou um relatório da McKinsey sobre digitalização. Liderou a estratégia de tecnologia e a área de compras de uma empresa de telecomunicações, reportando-se diretamente ao CEO. Além disso, liderou o crescimento comercial da empresa de tecnologia avançada Hypatos, que atingiu uma receita recorrente anual de sete dígitos e uma avaliação de nove dígitos, partindo de zero, em apenas dois anos. O trabalho de Cem no Hypatos foi noticiado por importantes publicações de tecnologia, como TechCrunch e Business Insider. Cem participa regularmente como palestrante em conferências internacionais de tecnologia. Ele se formou em engenharia da computação pela Universidade Bogazici e possui um MBA pela Columbia Business School.

Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

Nome

Endereço de email

Comentário

0/450

Postar comentário