A-CODE-CLI Bench: Benchmark de CLI Agênticas

Ferramentas CLI agênticas são ferramentas de codificação com IA que podem criar e eliminar ficheiros, executar comandos, planear 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 totais de testes automatizados, 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ênticas

Perceções de Desempenho das ferramentas CLI Agênticas

A correção do backend determina a classificação; a pontuação combinada pondera-a em 0,7 contra 0,3 do frontend.

• 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 um bom resultado final: Cline (4º em backend, 69,5%) e Forge (5º, 67,2%) classificam-se perto do topo em backend mas ficam muito atrás em frontend, os 52,5% do Cline são os mais fracos do grupo, por isso ambos descem na classificação combinada.
• Codex fica em 10º em backend (52,1%) apesar de um frontend perfeito de 100%. Executa aqui através de um proxy para alcançar o modelo comum, o que pode prejudicar as suas capacidades, por isso este é provavelmente um piso e não o verdadeiro backend do agente.¹ Gemini, também executado através de um proxy, está limitado da mesma forma.
• A classificação de 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 do meio da tabela retém tudo.

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

Avaliámos a eficiência de execução usando o tempo médio de execução (segundos), o uso efetivo de tokens (input + output) e o custo por tarefa (USD), cada um representado graficamente em função da pontuação combinada de precisão:

O quão rápido, barato ou económico em tokens um agente é não prevê a sua pontuação.

• Opencode vence nos três ao mesmo tempo: melhor pontuação combinada (81,6%), o custo mais baixo de qualquer agente capaz ($1,03 por tarefa), entre os que menos tokens usam e as execuções mais rápidas. Inverte o habitual compromisso entre precisão e custo.
• O custo abrange cerca de 40x, desde Forge $0,18 até Junie $7,58, sem relação com a classificação. Forge é o mais barato porque faz o mínimo: o seu backend falha na criação de tickets. Os $7,58 do Junie compram uma pontuação de meio da tabela de 74,7% e são um limite superior inflacionado.
• Goose paga o mais caro pelo menor resultado: segundo mais caro a $3,23, mas com a pontuação limpa mais baixa do grupo (62,5%). Os três melhores em pontuação mantêm-se 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, sobrecarga do proxy) ambos ficam no meio da tabela. O gasto extra compra repetições e revalidações, não profundidade de resolução de problemas.
• Os números de tokens são sobretudo sobre caching. Codex, Claude Code, Cline, Opencode, Gemini e Grok fazem cache de 86–98% do seu input, por isso os 4,18M tokens brutos do Claude Code reduzem-se a um efetivo de 115k. Junie, Goose, Kiro, Forge e Aider não fazem cache, por isso 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 que não usam cache, o input efetivo é tudo o que enviaram, por isso leia-o como um teto; os $1,72 do Kiro são um piso (faturado por créditos, mais próximo de $2,23); os 64,4% do Cline incluem quatro tarefas onde atingiu o seu limite de erros antes de entregar um frontend, cada uma com pontuação 0.

Pode consultar a nossa metodologia abaixo.

Como funcionam as ferramentas CLI agênticas

Ferramentas CLI agênticas são agentes autónomos que operam dentro do terminal. Embora a maioria dos utilizadores as utilize para tarefas de codificação, podem executar qualquer fluxo de trabalho que possa ser realizado através de comandos de shell.

Estes agentes operam tipicamente num ciclo composto por três fases:

1. Recolher contexto
2. Tomar ação
3. Verificar resultados

Após a verificação, o agente recolhe contexto atualizado e repete o ciclo até completar a tarefa ou atingir uma condição de paragem.

O ciclo é influenciado por duas fontes:

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

A framework de agente fornece estrutura em torno do modelo. Define como o modelo deve planear, quando deve executar comandos, como deve validar resultados e quais as ferramentas disponíveis. Estas ferramentas podem incluir execução de shell, acesso ao sistema de ficheiros, controlo de navegador, uso de computador, integrações MCP ou "competências" reutilizáveis.

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

Inteligência do modelo vs arquitetura do agente

As diferenças de desempenho entre ferramentas CLI agênticas não provêm de uma única fonte. Emergem de duas camadas: o modelo de fundação e a 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 recolhe contexto, quando executa comandos, como valida a saída e se repete após falha.

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

Os dois benchmarks observacionais abaixo levam isto mais longe. Executam o mesmo teste de modelo comum em pesquisa web e compactação de contexto, onde as diferenças não são de 13 pontos mas sim a diferença entre encontrar a resposta certa e inventar uma errada.

Fundamentação em pesquisa web

Pedimos a cada agente que auditasse documentação de frameworks: que versão introduziu uma funcionalidade, qual o seu estado atual e o que mudou recentemente. Cada resposta tinha de citar uma fonte oficial. Executámos a sonda duas vezes, uma no Unity e outra em Next.js/React. Os factos foram selecionados para que a resposta correta só exista numa página atual e publicada. Responder a partir dos dados de treino produz uma resposta confiante, mas errada. Verificámos uma coisa: o agente foi realmente buscar a página que citou?

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

Emergiram quatro padrões.

• Pesquisa real ao vivo Codex, Claude Code, Gemini e Grok obtêm páginas atuais e detetam mudanças recentes. Codex foi o único agente que chegou ao fórum de programadores, onde residem os factos mais difíceis.
• Pesquisa, mas aterra em páginas antigas Cline obteve duas dúzias de páginas de documentação reais e ainda assim reportou uma versão que já tinha sido substituída. As obtenções foram reais; as páginas estavam desatualizadas.
• Sem pesquisa, responde a partir do treino Aider não navega e diz isso mesmo. Esta é a resposta honesta.
• Fontes fabricadas Forge não obteve nada que funcionasse, mas citou 31 fontes na sonda Next.js. As páginas citadas não existem. A sua declaração final: "cada célula provém de uma página realmente obtida durante esta sessão."

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

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

Pontuámos cada resposta quanto à precisão factual, mas essas pontuações dependem de uma chave de respostas atualmente em revisão. Estamos a reter 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 o seu contexto: substitui o histórico detalhado por um breve resumo e descarta os originais. Testámos se o resumo retém o que é importante.

Demos a cada agente aproximadamente 112.000 tokens de documentos com 13 factos inventados incorporados: um PIN de prevenção, uma região de cloud, uma etiqueta de build e mais dez. Inventados significa que os valores são strings únicas sem presença nos dados de treino. O agente leu os documentos e compactou. Depois eliminámos os ficheiros de origem e perguntámos pelos 13 factos. Com os ficheiros eliminados, a única fonte possível é o resumo da compactação.

Quatro agentes retiveram todos os factos. Três não retiveram nenhum. Os três que obtiveram 0 de memória tinham respondido 13 de 13 enquanto ainda podiam reler os ficheiros. Estavam a reler em cada consulta. Quando os ficheiros 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 classifica-se em primeiro no benchmark de construção e não retém nada na compactação. Kiro classifica-se em sétimo no benchmark de construção e retém tudo na compactação. Forte desempenho de construção e forte compactação são propriedades independentes.

Quatro agentes ficaram fora do âmbito deste teste, cada um por uma razão concreta. Cline não pôde ser levado ao seu limiar de compactação. Construímos um conjunto de documentos de 863.000 tokens e fizemo-lo ler cada ficheiro, mas o cline trunca cada saída de ferramenta para cerca de 2.000 caracteres, por isso os documentos colapsaram em pré-visualizações curtas. O seu contexto estabilizou em 214.000 tokens, 21% da 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 os nossos documentos em fragmentos em vez de os carregar na íntegra, por isso nunca houve um contexto completo para compactar. O summarizer do Aider comprime turnos de chat, não o conteúdo dos ficheiros adicionados à sessão, que é onde os factos residiam. Junie não tem funcionalidade de compactação.

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.

Adicionar como fonte preferencial

Comportamentos dos agentes na tarefa 6

Avaliámos 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 exigia a construção de um sistema de tickets de helpdesk full-stack com:

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

O teste de fumo validou:

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

Esta tarefa pressiona a gestão 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.

Num único modelo, o grupo dividiu-se em três grupos.

• 60% backend, sete agentes (codex, claude-code, cline, grok, goose, junie, opencode): seis passos falhados idênticos em todas as três repetições. Autenticação, CRUD de tickets, respostas e isolamento de dados passaram; ambas as falhas foram 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, Opencode construiu os endpoints separados e pontuou 93,3%; no Sonnet 4.6 escolheu o design unificado como os restantes.
• 13,3%, três agentes (aider, forge, gemini-cli): a autenticação funcionou, mas a criação de tickets em si falhou, por isso cada passo dependente caiu em cascata.
• 24,4%, Kiro: instabilidade, não um único modo de falha. Passou nove passos na primeira execução, dois na segunda, e na terceira o backend nunca iniciou (verificação de saúde falhou). Os outros dez agentes repetiram-se de forma idêntica em todas as repetições.
• UI dentro do cluster de 60%: claude-code e cline falharam o login num bug CORS idêntico, o frontend chamou o backend em localhost:8000 a partir de uma origem 127.0.0.1 e o navegador bloqueou-o, por isso ambos pontuaram 75%; os outros cinco renderizaram e fizeram login corretamente a 100%.
• A conclusão é convergência: sete CLIs diferentes no mesmo modelo cometeram o mesmo erro de contrato REST, por isso aqui o modelo domina e a orquestração mal importa, o inverso dos benchmarks observacionais 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, pode continuar com a sua Conta ChatGPT, ou com a sua Chave API do OpenAI. Sem opções de fornecedor disponíveis.

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; falhou o contrato REST na atribuição e estado, como o resto do grupo.

Comportamento do Backend

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

Comportamento da UI

Frontend passou todos os oito passos de validação. O estado de login e pós-login comportou-se 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 a sua conta JetBrains ou gere uma JUNIE_API_KEY em junie.jetbrains.com/cli, ou exporte a sua própria chave API do Anthropic, OpenAI, Google ou outros fornecedores suportados. Múltiplas opções de fornecedor disponíveis.

Relatório da Tarefa

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

Comportamento do Backend

Nove de dezasseis passos passaram: autenticação, CRUD de tickets, respostas e isolamento de dados. As seis falhas foram os passos de atribuição e transição de estado. Junie tratou estado e atribuição através de um endpoint de atualização unificado, por isso 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 repetições.

Comportamento da UI

Frontend passou todos os oito passos 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

Depois execute:

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

Autenticação

Pode continuar com o seu plano Kiro-Code. Sem opções de fornecedor disponíveis.

Relatório da Tarefa

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

Comportamento do Backend

Na primeira execução, Kiro passou nove de dezasseis passos, o mesmo perfil do cluster de 60%, falhando apenas as rotas de atribuição e estado. Na segunda execução passou dois. Na terceira o backend nunca subiu e até a verificação de saúde falhou. Em média, isto é 24,4%. A instabilidade, não o design do endpoint, é o que separa Kiro do cluster aqui.

Comportamento da UI

Quando o backend estava a funcionar, o frontend passou todos os oito passos de validação. 100% UI. Isto é uma mudança em relação à execução anterior, onde o formulário de login falhou ao renderizar num 422 na montagem.

Claude Code

Instalação

Para macOS/Linux/WSL, considerando o seu gestor de pacotes preferido, 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, pode continuar com a sua Conta Claude. Sem opções de fornecedor disponíveis.

Relatório da Tarefa

Claude Code pontuou 60% no backend em 379 segundos, no cluster principal. Isto é uma melhoria marcada 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 passos. 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 os passos de atribuição e transição de estado, encaminhados através de um endpoint de atualização unificado em vez dos caminhos separados da especificação. Estável em todas as três repetições.

Comportamento da UI

O passo de login falhou. O frontend chamou o backend em localhost:8000 enquanto a página era servida a partir de uma origem 127.0.0.1, e o navegador bloqueou o pedido de login sob a política CORS. Cinco passos passaram, um falhou, dois foram bloqueados. 75% UI. Cline falhou da mesma forma.

Aider

Instalação

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

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

Autenticação

Inicie sessão na sua conta OpenRouter e autorize, ou exporte a sua Chave API 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 de input e 18k de tokens de output. Também pontuou 13,3% no backend. A autenticação funcionou, mas a criação de tickets falhou, e cada passo que precisava de um ticket existente falhou com ele.

Comportamento do Backend

Dois passos passaram. A construção quebrou na criação de tickets, por isso as listas de tickets de cliente e agente, respostas, atribuição, transições de estado e verificações de papéis caíram todas em cascata para falha. Estável em todas as três repetições. Esta é uma classe de falha diferente do cluster de 60%, que criou tickets corretamente e apenas falhou as rotas de atribuição e estado.

Comportamento da UI

O passo de login falhou sob a mesma incompatibilidade de origem CORS vista em claude-code e cline. Cinco passos passaram, um falhou, dois bloqueados. 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 o seu gestor de pacotes preferido:

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

Autenticação

Existem muitas opções de fornecedor, selecione o seu fornecedor 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 mudou.

Comportamento do Backend

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

Comportamento da UI

Frontend passou todos os oito passos de validação. 100% UI.

Grok Build

Instalação

Para macOS/Linux:

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

Autenticação

Inicie sessão com a sua conta xAI no primeiro lançamento, ou defina uma chave 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 de dezasseis passos passaram: autenticação, CRUD de tickets, respostas e isolamento de dados. As seis falhas foram os passos de atribuição e transição de estado, que visavam /tickets/{id}/assign e /tickets/{id}/status. Grok encaminhou ambos através de um endpoint de atualização unificado, por isso essas chamadas e as verificações de papéis que dependem delas retornaram 404. Estável em todas as três repetições.

Comportamento da UI

Frontend passou todos os oito passos de validação. O estado de login e pós-login comportou-se corretamente. 100% UI.

Forge

Instalação

Para macOS/Linux/WSL:

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

Autenticação

Configure as suas credenciais de fornecedor interativamente com:

• forge provider login

E escolha o seu fornecedor.

Relatório da Tarefa

Forge pontuou 13,3% no backend em 844 segundos. A sua contagem de tokens de output é 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 caiu em cascata.

Comportamento do Backend

Dois passos passaram. A criação de tickets falhou, por isso as listas de tickets, respostas, atribuição, transições de estado e verificações de papéis falharam todas com ela. Estável em todas as três repetições, o mesmo perfil de 13,3% que aider e gemini-cli.

Comportamento da UI

O passo de login falhou sob a mesma incompatibilidade de origem CORS vista em claude-code, cline e aider. Cinco passos passaram, um falhou, dois bloqueados. 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 (OAuth Google): export GOOGLE_CLOUD_PROJECT=”YOUR_PROJECT_ID” e depois inicie o gemini.
Opção 2 (chave API): export GEMINI_API_KEY=”YOUR_API_KEY” e depois 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 caiu em cascata. O seu frontend, que falhou totalmente na execução anterior numa incompatibilidade entre Node 18 e Vite 7, passou todos os passos desta vez.

Comportamento do Backend

Dois passos passaram. A criação de tickets falhou, por isso todos os passos dependentes falharam. Estável em todas as três repetições, o mesmo perfil de 13,3% que aider e forge.

Comportamento da UI

Frontend passou todos os oito passos de validação. 100% UI, acima de 0% na execução anterior. Um 401 apareceu na consola numa 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` pode selecionar a sua conta Cline ou continuar com o seu fornecedor 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 o seu limite de oito erros terminou a construção precocemente e deixou um frontend vazio. Aqui completou a stack completa.

Comportamento do Backend

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

Comportamento da UI

O passo de login falhou sob a mesma incompatibilidade de origem CORS vista em claude-code, numa página 127.0.0.1 a chamar um backend localhost. Cinco passos passaram, um falhou, dois bloqueados. 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 input para lá chegar. Completou a stack completa desta vez, uma mudança em relação à execução anterior onde 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 os passos de atribuição e transição de estado, encaminhados através de um endpoint de atualização unificado. Estável em todas as três repetições.

Comportamento da UI

Frontend passou todos os oito passos de validação. 100% UI, acima de 0% na execução anterior.

Ferramentas de codificação com IA

As ferramentas de codificação com 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 através de prompts e interações de linha de comandos.
  • Exemplos: Aider, Junie, Opencode, Claude Code, Codex

• Editores de código com IA: Também conhecidos como IDEs agênticos, estas ferramentas fornecem uma GUI semelhante ao VS Code (a maioria é 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 em 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 detetar bugs e vulnerabilidades. Avaliámos as principais ferramentas em 309 PRs no nosso benchmark RevEval.

O que podem fazer as ferramentas CLI agênticas?

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

• Trabalho de código ponta a ponta: Criar e modificar ficheiros, corrigir bugs, refatorar código e executar testes ou linters diretamente do terminal.
• Fluxos de trabalho agênticos: Realizar tarefas em vários passos, como encadeamento de tarefas, resolução de problemas, pesquisa e depuração iterativa.
• Git e gestão de projetos: Rever histórico, resolver merges, gerir branches e criar commits ou pull requests.
• Execução de comandos e automação: Executar comandos de shell, automatizar análises e traduzir linguagem natural em operações CLI complexas.
• Manipulação profunda de contexto: Operar em repositórios completos com consciência de dependências e estrutura do projeto.
• Flexibilidade de modelo: Suportar múltiplos modelos de cloud e, em alguns casos, modelos locais; algumas ferramentas permitem usar a sua própria chave API ou escolher entre planos.
• Acesso em sandbox ou controlado: Oferecer modos que vão desde apenas leitura até automação completa, frequentemente com ambientes isolados para segurança.

Metodologia

Benchmark A-CODE-CLI

Avaliámos os agentes sob uma configuração de execução única para medir a capacidade autónoma sem intervenção humana. Os agentes foram depois avaliados usando testes de fumo 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 (sem raciocínio). Dois agentes precisaram de um proxy para alcançar este modelo:

• Codex (CLI do OpenAI) não pode apontar para modelos Anthropic nativamente. Foi encaminhado 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.
• Gemini CLI não pode chamar modelos Anthropic nativamente. Foi encaminhado através de um shim SSE e gateway LiteLLM. As suas chamadas de modelo auxiliar (deteção de loops, reparação de ferramentas malformadas, compressão de contexto) falham ou retornam conteúdo inválido através do proxy, por isso executou sem as suas próprias redes de segurança.

Forge precisou de um proxy separado para remover blocos de pensamento estendido das respostas, que Forge ativa à força e que causam erros 400 quando reenviados. Todos os outros agentes usaram Sonnet 4.6 diretamente através da sua configuração nativa de fornecedor ou OpenRouter.

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

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

Claude Code executou via subscrição de utilizador (OAuth). Kiro executou em créditos alojados pelo Kiro (com suporte Bedrock, multiplicador 1,3x).

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

Pontuação. Backend: fumo funcional (adaptive_avg_step_pass_rate). Frontend: fumo de UI via Playwright. Combinada: 0,7 × backend + 0,3 × frontend (para agentes com dados de UI completos). 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 falharam no arranque. Confirmado em duas construções novas (mesmos erros: TypeError em class Card em t-3, AmbiguousForeignKeysError em User.auctions em t-4). Pontuado 0 com uma bandeira backend_never_ready, não excluído.

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

Versões das 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 web

Duas sondas: uma auditoria de migração Unity (sonda 2) e uma auditoria de versão Next.js/React (sonda 3). Cada uma pedia ao agente que reportasse versão, estado e cronologia para funcionalidades de framework especificadas e citasse um URL oficial por alegação.

A classificação usou dois métodos paralelos. Filtragem por verdade fundamental: uma alegação pontua apenas se o URL citado aparecer no registo real de fetch do agente E a página obtida contiver o facto, medido contra uma chave de respostas verificada. Classificação comportamental: um juiz LLM leu a transcrição completa de cada agente e atribuiu-o 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 a sua revisão de âncora humana.

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

Metodologia de compactação de contexto

Os agentes receberam aproximadamente 112.000 tokens de documentos de enchimento contendo 13 factos de infraestrutura inventados. Após o agente ler os documentos e compactar o seu contexto, eliminámos os ficheiros 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 facto. N=3.

Agentes que pontuaram 13/13 com ficheiros presentes e 0/13 com ficheiros eliminados são classificados como releitores. Agentes que pontuaram 13/13 com ficheiros eliminados são classificados como verdadeiros retentores. A eliminação de ficheiros exclui a releitura; factos inventados excluem a recordação de dados de treino.

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 agênticas, aqui estão os 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{kaleliolu2026,
  author = {Kalelioğlu, Berk and Dilmegani, Cem},
  title  = {{A-CODE-CLI Bench: Benchmark de CLI Agênticas}},
  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

Berk Kalelioğlu

Pesquisador de IA

Siga-nosVer 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