Serviços
Contate-nos

A-CODE-CLI Bench: Benchmark de CLI agêntica

Berk Kalelioğlu
Berk Kalelioğlu
atualizado em 29 jun. 2026

As ferramentas CLI agênticas são ferramentas de codificação de IA que podem criar e excluir arquivos, executar comandos, planejar e executar a codificação de todo o projeto. Avaliamos as principais ferramentas em 10 cenários reais de desenvolvimento web, realizando ~600 verificações atômicas de validação 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 agêntica

Loading Chart

Percepções de desempenho das ferramentas Agentic CLI

A correção do backend impulsiona o ranking; a pontuação combinada a pondera em 0.7 para 0.3 do frontend.

  • Todos os nove agentes que rodaram de forma 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 colocação final: Cline (4º no backend, 69.5%) e Forge (5º, 67.2%) estão perto do topo no backend, mas vão mal no frontend; Cline com 52.5% é o mais fraco do grupo, então ambos caem na classificação combinada.
  • Codex fica em 10º no backend (52.1%) apesar de um frontend perfeito de 100%. Aqui ele é executado 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.1 Gemini, também executado através de um proxy, é limitado da mesma forma.
  • A classificação de build não prevê o comportamento: o agente que lidera aqui não retém nada após a compactação, enquanto um agente de posição intermediária retém tudo.

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

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

A rapidez, o custo baixo ou o baixo consumo de tokens de um agente não preveem sua pontuação.

  • Opencode vence nas três ao mesmo tempo: maior pontuação combinada (81.6%), o menor custo entre os agentes capazes ($1,03 por tarefa), está entre os que menos usam tokens e é o mais rápido. Ele inverte a troca usual entre precisão e custo.
  • O custo varia cerca de 40x, de Forge com $0,18 a Junie com $7,58, sem relação com a classificação. Forge é o mais barato porque faz menos: seu backend falha na criação de tickets. O Junie com $7,58 compra uma pontuação intermediária de 74.7% e é um limite superior inflado.
  • Goose paga mais pelo menor retorno: é o segundo mais caro, a $3,23, e tem 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 agente mais rápido nem o mais lento vence: Kiro (439s) e Gemini (1.158s, overhead de proxy) ficam no pelotão intermediário. Gastos extras compram novas tentativas e revalidação, não profundidade na solução de problemas.
  • Os números de tokens dizem respeito principalmente a cache. Codex, Claude Code, Cline, Opencode, Gemini e Grok fazem cache de 86–98% da entrada, então Claude Code com 4.18M de tokens brutos se reduzem a um efetivo 115k. Junie, Goose, Kiro, Forge e Aider não fazem cache, então pagam por cada token reenviado; é 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 que não usam cache, a entrada efetiva é tudo o que eles enviaram, então leia como um teto; o Kiro com $1,72 é um piso (cobrado em créditos, mais próximo de $2,23); o Cline com 64.4% inclui quatro tarefas em que ele atingiu o limite de erros antes de entregar um frontend, cada uma com pontuação 0.

Você pode ver nossa metodologia abaixo.

Como funcionam as ferramentas CLI agênticas

As ferramentas CLI agênticas 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 por meio de 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 o 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 ao redor 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 de computador, integrações MCP ou “habilidades” reutilizáveis.

Diferentes arquiteturas de agente impõem diferentes estratégias de planejamento, políticas de repetição 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 agênticas não vêm de uma única fonte. Elas surgem de duas camadas: o modelo de fundação e o framework de orquestração que o envolve.

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

Opencode e Claude Code usam diretamente o Sonnet 4.6. Opencode marca 77.3% no backend; Claude Code marca 74.9%. Dois agentes, mesmo modelo, diferença de 2.4 pontos percentuais na correção do backend. Kiro e Opencode usam o Sonnet 4.6. Kiro marca 64.2% no backend; Opencode marca 77.3%. A diferença de 13 pontos é a contribuição da CLI.

Os dois benchmarks observacionais abaixo vão além. Eles executam o mesmo teste de modelo comum em pesquisa na web e compactação de contexto, onde as diferenças não são de 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 do framework: qual versão introduziu um recurso, qual é seu status atual e o que mudou recentemente. Cada resposta tinha de citar uma fonte oficial. Executamos a investigação duas vezes, uma no Unity e outra no Next.js/React. Os fatos foram selecionados para que a resposta correta só exista em uma página atual e publicada. Responder a partir de dados de treinamento produz uma resposta confiante, porém errada. Verificamos uma coisa: o agente realmente buscou a página que citou?

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

Quatro padrões emergiram.

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


Na investigação do Next.js, todos os outros agentes com navegação fundamentaram quase todas as suas citações em páginas que realmente haviam buscado. 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 completas e o Forge como uma única barra vermelha. O gráfico abrange os oito agentes com um log de busca verificável por URL. Grok (busca no servidor), Gemini (execução truncada) e Aider (sem citações) aparecem na tabela acima, mas são excluídos aqui.

Cline e Claude Code rodaram 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 um gabarito atualmente em revisão. Estamos retendo as tabelas de precisão até que o gabarito seja finalizado.

Deixe nossa equipe automatizar um dos seus processos de negócio com agentes de IA, gratuitamente.
Automatizar um processo

Compactação de contexto

Quando uma sessão fica longa, o agente compacta seu contexto: ele substitui o histórico detalhado por um resumo curto 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 de memória só haviam respondido 13 de 13 enquanto ainda podiam reler os arquivos. Eles reliam a cada consulta. Quando os arquivos desapareceram, escreveram “desconhecido” em vez de adivinhar.

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

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

Quatro agentes ficaram fora do escopo deste teste, cada um por um motivo concreto. O Cline não pôde ser levado ao seu limiar de compactação. Criamos 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évias curtas. Seu contexto se estabilizou em 214.000 tokens, 21% de sua janela de um milhão de tokens, e a compactação nunca disparou. Relatamos o Cline como não mensurável sob este protocolo em vez de estimar um número. O Grok tem um comando de compactação, mas leu nossos documentos em fragmentos em vez de carregá-los por completo, então nunca houve um contexto completo para ele compactar. O sumarizador do Aider comprime os turnos de chat, não o conteúdo dos arquivos adicionados à sessão, que é onde os fatos viviam. O Junie não tem recurso 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 todos rodam no mesmo modelo.

Tarefa 6: Sistema de tickets de helpdesk (Web)

A Tarefa 6 exigiu construir um sistema full-stack de tickets de helpdesk com:

  • Dois perfis 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 smoke test validou:

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

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

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

  • 60% no backend, sete agentes (codex, claude-code, cline, grok, goose, junie, opencode): seis etapas de falha idênticas em todas as três reexecuções. Autenticação, CRUD de tickets, respostas e isolamento de dados passaram; ambas as falhas estavam em /tickets/{id}/assign e /tickets/{id}/status, onde construíram um PATCH /tickets/{id} 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 marcou 93.3%; no Sonnet 4.6, escolheu o design unificado como os demais.
  • 13.3%, três agentes (aider, forge, gemini-cli): a autenticação funcionou, mas a própria criação de tickets falhou, então todas as etapas dependentes falharam em cascata.
  • 24.4%, Kiro: instabilidade, não um modo de falha único. Ele passou nove etapas na primeira execução, duas na segunda e, na terceira, o backend nunca iniciou (a verificação de saúde falhou). Os outros dez agentes repetiram de forma idêntica em todas as reexecuções.
  • Interface dentro do cluster de 60%: claude-code e cline falharam no login devido a um bug idêntico de CORS; o frontend chamou o backend em localhost:8000 a partir de uma origem 127.0.0.1 e o navegador bloqueou, então ambos pontuaram 75%; os outros cinco renderizaram e fizeram login corretamente com 100%.
  • A lição é a 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 pouco importa, o inverso dos benchmarks observacionais abaixo.

Codex

Instalação

Instale globalmente com:

  • npm install -g @openai/codex

Como alternativa, instale globalmente com Homebrew (macOS/Linux)

  • brew install –cask codex

Autenticação

Depois de 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

O Codex construiu um sistema funcional em 454 segundos e ficou no cluster de 60%. A lógica de negócio estava correta; ele errou o contrato REST em atribuição e status, como o restante 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 tinham como alvo `/tickets/{id}/assign` e `/tickets/{id}/status`. O Codex roteou ambas por meio de um endpoint de atualização unificado, então essas chamadas retornaram 404. Estável em todas as três reexecuções.

Comportamento da Interface

O frontend passou em todas as oito etapas de validação. O estado de login e pós-login se comportou corretamente. 100% na interface.

Junie

Instalação

O Junie está disponível por meio 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. Várias opções de provedor disponíveis.

Relatório da Tarefa

O Junie produziu um sistema full-stack completo em 444 segundos e marcou 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 na 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. O Junie tratou status e atribuição por meio de um endpoint de atualização unificado, então as rotas `/tickets/{id}/assign` e `/tickets/{id}/status` da especificação retornaram 404. A própria lógica de transição estava correta. Estável em todas as três reexecuções.

Comportamento da Interface

O frontend passou em todas as oito etapas de validação. 100% na interface.

Kiro CLI

Instalação

Para macOS/Linux/WSL:

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

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

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

Em seguida, 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

O Kiro é o único agente cuja pontuação reflete instabilidade em vez de uma única escolha de design. Seus 24.4% no backend são uma média de três reexecuções que produziram três resultados diferentes. O build em si era sólido quando rodava; o problema é que não rodava da mesma forma duas vezes.

Comportamento do Backend

Na primeira execução, 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 subiu e até a verificação de saúde falhou. Em média, isso dá 24.4%. A instabilidade, e não o design do endpoint, é o que separa o Kiro do cluster aqui.

Comportamento da Interface

Quando o backend estava no ar, o frontend passou em todas as oito etapas de validação. 100% na interface. Isso é uma mudança em relação à execução anterior, em que o formulário de login falhou ao renderizar com 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 uma das opções:

  • 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

O Claude Code marcou 60% no backend em 379 segundos, no cluster principal. Esta é uma melhora acentuada em relação à execução anterior, em que 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 interface.

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 por meio 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 Interface

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

Aider

Instalação

Se você já tiver o 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 chave de API no seu ambiente com:

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

Relatório da Tarefa

O 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. Ele também marcou 13.3% no backend. A autenticação funcionou, mas a criação de tickets falhou, e toda etapa que precisava de um ticket existente falhou junto.

Comportamento do Backend

Duas etapas passaram. O build 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 papéis falharam em cascata. Estável em todas as três reexecuções. Esta é uma classe de falha diferente do cluster de 60%, que criava tickets corretamente e só errava as rotas de atribuição e status.

Comportamento da Interface

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

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 o provedor desejado e autentique-se com /connect

Relatório da Tarefa

O Opencode lidera o benchmark geral, mas na Tarefa 6 marcou 60% no backend, no cluster principal, em 542 segundos. Esta é a evidência de modelo mais clara do artigo. Na execução anterior com modelo nativo no Gemini 3 Pro Preview, o Opencode construiu os endpoints separados da especificação e marcou 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 mudou.

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 por meio de um endpoint de atualização unificado. Estável em todas as três reexecuções.

Comportamento da Interface

O frontend passou em todas as oito etapas de validação. 100% na interface.

Grok Build

Instalação

Para macOS/Linux:

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

Autenticação

Entre 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

O Grok terminou em segundo lugar geral no benchmark de build com 75.4% no backend. Na Tarefa 6, marcou 60% no backend em 433 segundos, no cluster principal. Nesta execução, o Grok chegou ao Sonnet 4.6 por meio 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 tinham como alvo /tickets/{id}/assign e /tickets/{id}/status. O Grok roteou ambas por meio de um endpoint de atualização unificado, então essas chamadas e as verificações de papéis que dependem delas retornaram 404. Estável em todas as três reexecuções.

Comportamento da Interface

O frontend passou em todas as oito etapas de validação. O estado de login e pós-login se comportou corretamente. 100% na interface.

Forge

Instalação

Para macOS/Linux/WSL:

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

Autenticação

Configure as credenciais do seu provedor interativamente com:

  • forge provider login

E escolha seu provedor.

Relatório da Tarefa

O Forge marcou 13.3% no backend em 844 segundos. Sua contagem de tokens de saída é a menor do grupo, com 1.6k, o que indica uma implementação superficial. Como na execução anterior, o build quebrou na criação de tickets e falhou 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 papéis falharam junto. Estável em todas as três reexecuções, o mesmo perfil de 13.3% do aider e do gemini-cli.

Comportamento da Interface

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

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 (OAuth do Google): export GOOGLE_CLOUD_PROJECT=”YOUR_PROJECT_ID” e inicie o gemini.
Opção 2 (chave de API): export GEMINI_API_KEY=”YOUR_API_KEY” e inicie o gemini.
Opção 3 (Vertex IA): export GOOGLE_API_KEY + GOOGLE_GENAI_USE_VERTEXAI=true.

Relatório da Tarefa

A CLI do Gemini marcou 13.3% no backend em 926 segundos, sendo um dos dois agentes mais lentos do grupo. A autenticação funcionou, mas a criação de tickets falhou e cascateou. Seu frontend, que havia falhado totalmente na execução anterior por 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 do forge.

Comportamento da Interface

O frontend passou em todas as oito etapas de validação. 100% na interface, acima dos 0% da 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 digitar `cline auth`, você pode selecionar sua conta Cline ou continuar com o provedor desejado.

Relatório da Tarefa

O Cline marcou 60% no backend em 648 segundos, no cluster principal. Esta é uma grande mudança em relação à execução anterior, em que seu limite de oito erros encerrou o build prematuramente e deixou um frontend vazio. Aqui ele completou o full stack.

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 por meio de um endpoint de atualização unificado. Estável em todas as três reexecuções.

Comportamento da Interface

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

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

O Goose marcou 60% no backend em 553 segundos, no cluster principal, mas consumiu 1.06M tokens de entrada para isso. Ele completou o full stack desta vez, uma mudança em relação à execução anterior, em que o diretório do frontend ficou 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 por meio de um endpoint de atualização unificado. Estável em todas as três reexecuções.

Comportamento da Interface

O frontend passou em todas as oito etapas de validação. 100% na interface, acima dos 0% da execução anterior.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.
GoogleAdicionar como fonte preferencial

Ferramentas de codificação de IA

As ferramentas de codificação de IA podem ser agrupadas em três categorias:

  • CLI agêntica: Ferramentas para fluxos de trabalho de desenvolvimento baseados em terminal, geram, editam e refatoram código por meio de prompts e interações de linha de comando.
    • Exemplos: Aider, Junie, Opencode, Claude Code, Codex
  • Editores de código de IA: Também conhecidos como IDEs agênticos, essas ferramentas fornecem uma GUI semelhante 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 criar aplicativos 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 de 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 detectar bugs e vulnerabilidades. Avaliamos as principais ferramentas em 309 PRs em nosso benchmark RevEval.

O que as ferramentas CLI agênticas podem fazer?

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

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

Metodologia

A-CODE-CLI Benchmark

Avaliamos os agentes sob uma configuração de execução one-shot para medir a capacidade autônoma sem intervenção humana. Os agentes foram então avaliados usando smoke tests de backend e frontend para medir a prontidão da infraestrutura e a correção comportamental.

Configuração do modelo. Todos os 11 agentes rodaram no Claude Sonnet 4.6 (sem raciocínio). Dois agentes precisaram de um proxy para alcançar este modelo:

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

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

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

O Junie executa simultaneamente 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 o build. Suas pontuações carregam um asterisco de múltiplos modelos.

O Claude Code rodou por assinatura do usuário (OAuth). O Kiro rodou em créditos hospedados pelo Kiro (com suporte Bedrock, multiplicador de 1.3x).

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

Pontuação. Backend: smoke funcional (adaptive_avg_step_pass_rate). Frontend: smoke de UI via Playwright. Combinada: 0.7 × backend + 0.3 × frontend (para agentes com dados completos de UI). A pontuação de backend é o eixo primário de classificação. O desempenho de frontend satura em todo o grupo.

Aider t-3 e t-4. Ambas as tarefas produziram backends que travavam na inicialização. Confirmado em dois builds novos (mesmos erros: TypeError em class Card no t-3, AmbiguousForeignKeysError em User.auctions no t-4). Pontuados com 0 com uma flag backend_never_ready, não excluídos.

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

Versões das CLIs (execução do benchmark de junho de 2026)

Versões lidas nas VMs do benchmark. A execução de build 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 web

Duas investigações: uma auditoria de migração do Unity (investigação 2) e uma auditoria de versão do Next.js/React (investigação 3). Cada uma pedia ao agente que relatasse versão, status e cronograma de recursos especificados do framework e citasse uma URL oficial por afirmação.

A avaliação usou dois métodos paralelos. Gating de ground truth: uma afirmação pontua apenas se a URL citada aparecer no log de busca real do agente E a página buscada contiver o fato, medido em relação a um gabarito verificado. 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 é o resultado primário; as tabelas de precisão pontuadas serão publicadas depois que o gabarito concluir sua revisão humana de âncora.

Agentes com busca integrada (Codex, Gemini, Grok) rodaram em seus modelos nativos porque a tarefa exige sua capacidade de busca integrada. Os oito restantes rodaram 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. Depois que o agente leu os documentos e compactou seu contexto, excluímos os arquivos de origem antes de fazer qualquer pergunta. Pontuação: correspondência exata com 13 valores inventados, automatizada por um script de avaliaçã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 lembrança de dados de treinamento.

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

Leia mais

Para quem explora o ecossistema mais amplo de ferramentas de desenvolvimento agênticas, aqui estão nossos benchmarks mais recentes:

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

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.

Berk Kalelioğlu and Cem Dilmegani (2026) - "A-CODE-CLI Bench: Benchmark de CLI agêntica". Publicado on-line em AIMultiple.com. Acessado em 29 Junho 2026, em: https://aimultiple.com/agentic-cli [Recurso on-line]

Kalelioğlu, B., & Dilmegani, C. (2026, 29 Junho). A-CODE-CLI Bench: Benchmark de CLI agêntica. AIMultiple. https://aimultiple.com/agentic-cli

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

Resultados e carimbos de data/hora de 139 pontos de dados. Baixe os dados utilizados neste artigo como um arquivo ZIP contendo 4 arquivos CSV e um README.

Última atualização: 17 Agosto 2026
Baixar

Registro de alterações

21 atualizações
  1. 2026

    Adicionado, uma frase à introdução, esclarecendo que todos os agentes rodaram no mesmo modelo.

  2. Atualizada a seção de Metodologia, fornecendo uma explicação mais detalhada da configuração do modelo, pontuação e versões CLI utilizadas, oferecendo aos leitores uma compreensão mais clara da configuração experimental.

  3. Expandida a metodologia de benchmark na introdução, oferecendo uma compreensão mais clara do rigor dos testes.

  4. Removida a metodologia detalhada, reduzindo o comprimento do artigo.

  5. A formatação dos cabeçalhos foi atualizada para melhorar a legibilidade e a consistência.

  6. Reduzido o escopo do benchmark na introdução, dando aos leitores uma compreensão mais precisa da amplitude da avaliação.

  7. Expandida a seção Metodologia, fornecendo um relato detalhado da configuração de avaliação, configurações do modelo e mecanismos de pontuação para os agentes.

  8. Atualizada a introdução, a seção 'Pool de projetos e configurações de modelo', a seção 'Listas de verificação funcionais (auditoria do lado do navegador)', a seção 'Exemplo de tarefa de benchmark: painel da plataforma de educação online', a seção 'Escopo do projeto e pilha de tecnologia', a seção 'Resultados detalhados do benchmark: desempenho de Kiro vs Gemini CLI Kiro (95% de sucesso)', a seção 'Como visto acima, Kiro entregou uma interface de usuário de nível profissional com uma barra de pes

  9. Expandida a seção 'O que são agentes de codificação baseados em CLI?', fornecendo uma explicação mais detalhada de suas capacidades e benefícios para os leitores.

  10. A Introdução foi atualizada, fornecendo uma visão geral mais clara do escopo e da metodologia do benchmark.

  11. Adicionada uma frase à seção de Metodologia, esclarecendo como as ferramentas CLI foram solicitadas para um benchmark mais justo.

  12. 2025

    Expandida a seção de Metodologia, fornecendo um estudo de caso detalhado do projeto 'EduSphere', oferecendo aos leitores uma compreensão mais profunda da aplicação e dos resultados do benchmark.

  13. Adicionado, Resultados ao artigo, fornecendo aos leitores uma análise do desempenho da ferramenta e da metodologia utilizada.

  14. Atualizada a introdução, seção "Explore as principais ferramentas CLI agênticas para otimizar e elevar seu fluxo de trabalho de edição de código", para clarificar a definição e o escopo das ferramentas CLI agênticas.

  15. Detalhes removidos da seção 'Manuseio de saída e contexto', simplificando a descrição do desempenho e manuseio de contexto do Claude Code.

  16. Movidos Claude Code e Cline CLI, nas descrições dos produtos, para melhorar o fluxo lógico das informações.

  17. Adicionado Gemini CLI, OpenHands, Cline CLI e Codex CLI à seção 'Agentes de Codificação Baseados em CLI', fornecendo aos leitores informações sobre quatro novas ferramentas.

  18. Removida a seção 'Melhores casos de uso', reduzindo informações sobre as aplicações ideais do Claude Code.

  19. Atualizada a introdução para refletir melhor o foco do artigo nas principais ferramentas CLI agênticas.

  20. Atualizada a Introdução, fornecendo aos leitores exemplos atuais de grandes modelos de linguagem.

  21. Atualizada a descrição dos 'agentes de codificação baseados em CLI' na seção 'ferramentas de codificação de IA', proporcionando uma compreensão mais clara de sua função.

Berk Kalelioğlu
Berk Kalelioğlu
Pesquisador de IA
Berk é um Pesquisador de IA na equipe de benchmark da AIMultiple, com foco em IA agêntica, aprendizado de máquina e grandes e pequenos language models (LLMs e SLMs).
Ver perfil completo
Revisado tecnicamente por
Cem Dilmegani
Cem Dilmegani
Analista Principal
Cem é o analista principal da AIMultiple desde 2017.

O trabalho de Cem na AIMultiple foi citado por publicações globais líderes, incluindo Business Insider, Forbes, Morning Brew e Washington Post, por empresas globais como Deloitte e HPE, ONGs como o World Economic Forum e organizações supranacionais como a European Commission. [1], [2], [3], [4], [5]

Ao longo de sua carreira, Cem atuou como consultor de tecnologia, comprador de tecnologia e empreendedor de tecnologia. Ele aconselhou empresas sobre suas decisões de tecnologia na McKinsey & Company e na Altman Solon por mais de uma década. Ele também publicou um relatório da McKinsey sobre digitalização.

Ele liderou a estratégia de tecnologia e as compras de uma operadora de telecomunicações, reportando-se ao CEO. Ele também liderou o crescimento comercial da empresa de deep tech Hypatos, que atingiu uma receita recorrente anual de 7 dígitos e uma avaliação de 9 dígitos partindo do zero em 2 anos. O trabalho de Cem na Hypatos foi coberto por publicações de tecnologia líderes como TechCrunch e Business Insider.

Cem fala regularmente em conferências internacionais de tecnologia. Ele se formou como engenheiro da computação pela Bogazici University 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.

0/450