A-CODE-LLM Bench: Benchmark de Codificação Agentic
Avaliamos os principais Large Language Models (LLMs) em 10 tarefas de desenvolvimento de software usando uma ferramenta CLI agentic. Executamos ~3,500 etapas de validação automatizada por modelo, tanto na camada de API quanto na de UI.
Resultados do A-CODE-LLM Bench
Cada alias foi executado 3 vezes em 10 tarefas (30 amostras por alias, 380 células por iteração em 38 aliases). Veja mais detalhes na metodologia.
- O Sonnet de nível médio supera o Opus, o carro-chefe. Ambas as versões do Sonnet pontuam acima de todos os Opus, incluindo o Opus 4.8 (0.702). A camada mais cara da Anthropic não é a sua melhor codificadora.
- O topo não é mais apenas da Anthropic: o Grok 4.5 (0.732) supera todas as variantes do Opus. O novo carro-chefe da OpenAI, o GPT 5.6 Sol, registra a melhor pontuação da empresa (0.615), ainda 0.157 abaixo do Sonnet 5, e suas variantes pro de maior computação, em sua maioria, ficam abaixo das próprias bases (Sol Pro 0.543, Terra Pro 0.568; apenas o Luna Pro melhora, 0.603 vs 0.579).
- Os especialistas em código não venceram o benchmark de codificação. O GPT 5.3 Codex, a variante ajustada para código da OpenAI, pontua 0.572, na faixa intermediária e abaixo do GPT 5.4 Mini, de propósito geral da própria OpenAI (0.594). O Kimi K2.7 Code da Moonshot é o especialista mais forte, com 0.611.
- Nenhum modelo é confiável no backend: o teto é 0.701 (Sonnet 5), portanto, até o vencedor falha em cerca de um terço das verificações de lógica de negócio e contratos. O Grok 4.5 é o que mais se aproxima entre as adições de julho, com 0.663. O frontend está quase resolvido entre os líderes (0.79 a 0.96), então o backend é o problema em aberto e define o ranking. O Claude Haiku 4.5 renderiza bem (0.731), mas um backend de 0.277 o limita a 0.413.
- O ponto fraco do GPT é o frontend. O GPT 5.4 e o 5.5 se igualam ao Opus 4.8 no backend (cerca de 0.6), mas pontuam de 0.53 a 0.55 no frontend; a família GPT 5.6 eleva isso para 0.63 a 0.71, ainda bem abaixo dos mais de 0.91 da linha Sonnet.
Comparação de custo e sucesso
- Os modelos com preço de carro-chefe são o pior custo-benefício. O Opus 4.7 é o mais caro (US$ 3,08/célula) e pontua 0.610, abaixo do Sonnet 4.6 a US$ 1,33.
- O topo cobra um alto prêmio por pouco ganho: o Sonnet 5 pontua 0.024 acima do Sonnet 4.6 com 70% a mais de custo por célula.
- Grok 4.5 é o novo melhor custo-benefício: 0.732, dentro de 0.040 do vencedor, a US$ 0,46 por célula, comparado aos US$ 2,23 do Sonnet 5. Dentro da família GPT 5.6, o preço não agrega nada: de US$ 0,18 (Luna) a US$ 2,76 (Sol Pro) por célula para pontuações entre 0.543 e 0.615, com o alias mais barato superando o mais caro.
Comparação de tempo de conclusão e sucesso da tarefa
- A pontuação máxima está entre as mais lentas. O Sonnet 5 leva cerca de 30 minutos por tarefa, o triplo do Sonnet 4.6 para 0.024 a mais; o Sonnet 4.6 oferece praticamente a mesma pontuação em um terço do tempo.
- Uma execução longa geralmente sinaliza um modelo travado, não um modelo minucioso: os piores pontuadores, ambas as variantes do Qwen, a base do GLM 5.1 e o Deepseek V4 Pro, rodaram mais de 1.700 segundos devido a iterações excessivas para pontuações abaixo de 0,45.
- Grok 4.3 foi rápido porque desistiu cedo: 142 segundos e 18 chamadas de ferramenta para 0.431. O Grok 4.5 mantém a velocidade e elimina a desistência: cerca de 9 minutos por tarefa, menos de um terço do tempo do Sonnet 5, para 0.732.
Chamadas de ferramenta por tarefa
- A contagem de chamadas de ferramenta não mede capacidade nem esforço que você possa comparar. O Sonnet 5 fez a maior quantidade de chamadas (125) e pontuou mais alto; o MiniMax M3 fez 108 para uma mediana 0.583; o Grok 4.5 alcançou 0.732 com 40; as baixas marcas da OpenAI, de 16 a 36, decorrem do apply_patch agrupar um arquivo inteiro em uma só chamada. O Sol Pro e o Terra Pro fazem de um quarto a um terço menos chamadas de ferramenta do que suas bases e pontuam menos: mais raciocínio, menos execução. Não classifique agentes pelo volume de ferramentas.
- Dois caminhos alcançam o mesmo escore: O Sonnet 5 itera pesadamente (125 chamadas), o Sonnet 4.6 o faz minimamente (cerca de 50), com 0.024 de distância.
Desempenho de LLM em uma única tarefa bem-sucedida
Nenhum modelo passou em todas as etapas do benchmark completo acima. Para comparar custo e velocidade em condições iguais, executamos uma tarefa de linha de base simples que todo modelo consegue completar: quatro endpoints CRUD, validação básica, sem autenticação e sem banco de dados.
Comparação de custo e linhas de código
- Tarefas simples não conseguem classificar modelos, portanto, avaliações de brinquedo enganam. Na linha de base que todo modelo passa, o código converge para 40 a 64 linhas, e o custo cai para centavos; as diferenças só aparecem em trabalhos longos e com múltiplos arquivos.
- O nível "rápido e leve" foi o mais caro nesse caso: a base do Gemini 3.5 Flash escreveu 131 linhas para a tarefa trivial, duas a três vezes mais que os demais, tornando-se a linha de base mais cara, contrariando seu próprio posicionamento.
- A iteração pesada do Sonnet 5 é impulsionada pela tarefa, não um hábito: 9 chamadas e US$ 0,09 aqui, contra 125 chamadas no benchmark.
Veja mais detalhes no artigo Precificação de LLM.
Tempo de conclusão e uso de tokens
- A previsibilidade de custo divide os modelos em dois. Os modelos adaptativos gastam apenas quando necessário (Opus 4.8: 34s na linha de base, 1.072s no benchmark); os modelos de ritmo fixo executam de forma lenta e custosa mesmo em trabalhos triviais (MiniMax M3: 475 vs 1.684s).
- O comprimento da saída é uma característica fixa do modelo, variando quase 10x para a mesma tarefa (787 a 7.508 tokens), alimentando diretamente o custo.
O que são sistemas LLM agentic?
Construir software é iterativo: escrever código, executá-lo, ler erros, corrigi-los, repetir. Sistemas de IA Agentic permitem que os LLMs sigam esse mesmo ciclo. O modelo opera dentro de um ambiente de desenvolvimento no qual pode escrever arquivos, executar comandos, ler saídas e fazer alterações com base no que vê, continuando até que a tarefa seja concluída.
Isso é importante porque aplicações reais não são arquivos únicos. Elas têm backends com rotas e modelos de banco de dados, frontends com componentes e chamadas de API, arquivos de configuração, dependências e testes. Fazer tudo isso funcionar em conjunto exige testes iterativos e refinamento, exatamente o que a arquitetura agentic proporciona.
Como funciona
O modelo fica dentro de um harness com acesso a um shell, sistema de arquivos e saída de execução. Quando solicitado a construir uma aplicação, ele escreve arquivos de forma incremental. Após cada etapa, o harness mostra ao modelo o que aconteceu: o servidor iniciou, os testes passaram, o linter sinalizou erros? Com base nesse feedback, o modelo decide o que escrever ou corrigir em seguida.
Isso difere fundamentalmente da geração de tiro único. Em configurações de único disparo, o modelo gera toda uma base de código às cegas, sem meios de verificar se funciona. Em sistemas de LLM agentic, o modelo vê as consequências de cada ação e corrige o rumo. No entanto, essa capacidade por si só não é suficiente. O modelo ainda precisa de forte raciocínio para implementar a lógica de negócios corretamente, e é aí que as diferenças de desempenho realmente aparecem.
Adicionar como fonte preferencialMetodologia do benchmark de LLM agentic
Usamos o Opencode como harness do agente para todos os modelos e os conectamos por meio do OpenRouter, com uma exceção: o Claude Fable 5 foi executado na CLI do Claude Code na assinatura do Claude. Cada célula foi executada três vezes para medir a variação por célula e estabilizar a tabela de classificação. Avaliamos a capacidade deles de trabalhar autonomamente em 10 tarefas de desenvolvimento de software (T-1 a T-10), que vão desde sistemas de reserva até painéis interativos. Essas tarefas exigem que os agentes gerenciem projetos de múltiplos arquivos e entreguem produtos funcionais. Os sete aliases adicionados em julho de 2026 (Grok 4.5 e a família GPT 5.6: Sol, Terra, Luna, cada um nos modos base e pro) rodaram no Opencode 1.15.13 com configurações padrão da API, o mesmo que todos os modelos aqui; os números de lançamento do Sol pela OpenAI usam modos de computação mais altos.1 Quatro células do Sol Pro e uma célula do Terra Pro terminaram em repetidas falhas silenciosas de fluxo da API, em vez de erros do modelo, e são pontuadas como falhas.
Execução e orquestração
Cada agente e tarefa começa em um ambiente limpo. As instruções são fornecidas como um arquivo TASK.md, e usamos um watchdog de heartbeat de 20 minutos para os scripts de inicialização. Durante essa fase, registramos códigos de saída, tempo de execução e se os arquivos de backend e frontend foram criados. Também monitoramos o uso de tokens em tempo real nas categorias de entrada, saída e cache.
Validação de backend: Implantamos os projetos gerados em ambientes isolados para testá-los contra um contrato YAML canônico. A validação cobre cenários de caminho feliz, tratamento de erros (400/403/409) e consistência de dados.
Testamos os resultados em dois modos:
O modo adaptativo valida a funcionalidade mesmo com nomes de rota diferentes, enquanto o modo estrito exige aderência exata ao contrato.
O escore geral do backend é calculado por célula como:
backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)
onde has_backend é 1 se a célula produziu um projeto de backend, 0 caso contrário. O adaptativo tem peso maior porque mede a correção comportamental; o estrito adiciona uma penalidade por desvio de contrato (rotas renomeadas, códigos de status substituídos, campos de resposta reestruturados).
Testes de UI e cenários de usuário
Usamos automação de navegador para simular fluxos reais de usuário, incluindo preflights, renderização e autenticação. Verificamos etapas funcionais como envio de login e comportamento pós-login para garantir que a aplicação execute sem travar.
A pontuação da UI divide oito etapas em dois grupos. As etapas de infraestrutura (preflight do backend, renderização do frontend, formulário de login visível, envio de login, login 2xx, sem falha em tempo de execução) medem se a aplicação sequer funciona. As etapas de comportamento (sinal de autenticação pós-login, sinal de comportamento pós-login) avaliam se a aplicação realiza sua função pretendida uma vez em execução.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
As etapas de comportamento bloqueadas são excluídas do denominador de comportamento, de modo que uma célula não é penalizada duplamente quando a aplicação falha ao carregar.
Cálculo de tokens
As contagens de tokens são extraídas da resposta da API do LLM. Subtraímos os tokens de entrada em cache do total de tokens de entrada para obter a entrada efetiva, que reflete apenas os tokens recentemente processados. Os tokens de saída nunca são armazenados em cache, portanto, permanecem inalterados.
Agregação final
A pontuação final do benchmark é calculada combinando os resultados das fases anteriores: Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Atribuímos um peso maior ao backend porque falhas de lógica no nível da API frequentemente invalidam qualquer sucesso no frontend.
Exemplo de tarefa
Tarefa 6: Sistema de tickets de helpdesk
A Tarefa 6 foca no desenvolvimento de um ecossistema complexo de suporte ao cliente. O objetivo principal é construir uma plataforma que medeie a comunicação entre clientes e agentes de suporte, aplicando rigorosamente regras de negócio e limites de segurança. Esta tarefa avalia a capacidade de um agente de lidar com máquinas de estado multiusuário, isolamento de dados e comunicação encadeada em um ambiente full-stack.
A tarefa exigia a construção de um sistema de helpdesk com:
- Permissões distintas para Clientes (emitir/responder) e Agentes (gerenciar/resolver).
- Um fluxo de trabalho rígido de status que impede transições ilegais e impõe ações específicas de cada função.
- Isolamento avançado de dados, onde requisições a recursos não autorizados retornam 404 em vez de 403 para proteger a integridade do sistema.
- Um sistema de respostas cronológicas para interação contínua entre agente e cliente.
- Um backend FastAPI combinado com um frontend responsivo desenvolvido em Vite (React/Vue/Svelte).
- Configuração reproduzível por meio de comandos shell específicos para ativação imediata do sistema.
Você pode consultar a documentação da Tarefa 6 no GitHub.
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-LLM Bench: Benchmark de Codificação Agentic}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Acessado em 10 Julho 2026}
}Resultados e carimbos de data/hora de 418 pontos de dados. Baixe os dados utilizados neste artigo como um arquivo ZIP contendo 2 arquivos CSV e um README.
Links de referência
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.