A-CODE-LLM Bench: Benchmark de Codificação Agentic
Comparamos 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 automatizadas por modelo em ambas as camadas de API e UI.
A-CODE-LLM Bench resultados
Cada alias foi executado 3 vezes em 10 tarefas (30 amostras por alias, 400 células por iteração em 40 aliases). Veja mais detalhes sobre a metodologia.
- Sonnet de nível médio supera o Opus principal. Ambas as versões do Sonnet superam todos os Opus, incluindo Opus 4.8 (0.702). O nível mais caro da Anthropic não é o seu melhor programador.
- O topo não é mais exclusivo da Anthropic: Grok 4.5 (0.732) supera todas as variantes do Opus. O novo carro-chefe da OpenAI, GPT 5.6 Sol, apresenta a melhor pontuação da empresa (0.615), ainda 0.157 abaixo do Sonnet 5, e suas variantes pro de computação mais alta ficam em sua maioria abaixo de suas próprias bases (Sol Pro 0.543, Terra Pro 0.568; apenas Luna Pro melhora, 0.603 vs 0.579).
- Os especialistas em código não venceram o benchmark de codificação. GPT 5.3 Codex, a variante ajustada para código da OpenAI, pontua 0.572, no meio do pelotão e abaixo do GPT 5.4 Mini geral da própria OpenAI (0.594). O Kimi K2.7 Code da Moonshot é o especialista mais forte com 0.611.
- Kimi K3, um modelo geral, assume a liderança em pesos abertos do especialista em código da própria Moonshot: 0.725, sexto lugar geral, 0.114 acima do K2.7 Code. Seu backend de 0.632 fica em quinto, acima de todos os aliases Opus e GPT.
- Inkling, o primeiro modelo da Thinking Machines, estreia com 0.575, terceiro entre as entradas de pesos abertos. Seu frontend de 0.747 supera todos os aliases GPT 5.6; o backend de 0.501 limita sua classificação.
- Nenhum modelo é confiável no backend: o teto é 0.701 (Sonnet 5), então mesmo o vencedor falha em cerca de um terço das verificações de lógica de negócio e contrato. Grok 4.5 chega mais perto 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 ele define a classificação. Claude Haiku 4.5 renderiza bem (0.731), mas um backend de 0.277 o mantém em 0.413.
- O ponto fraco do GPT é o frontend. GPT 5.4 e 5.5 igualam 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 muito abaixo dos mais de 0.91 da linha Sonnet.
Custo & comparação de sucesso
- Os modelos com preço de carro-chefe têm o pior custo-benefício. Opus 4.7 é o mais caro ($3.08/célula) e pontua 0.610, abaixo do Sonnet 4.6 a $1.33.
- O topo cobra um alto prêmio por pouco ganho: Sonnet 5 pontua 0.024 acima do Sonnet 4.6 por 70% mais custo por célula.
- Grok 4.5 é o novo melhor custo-benefício: 0.732, a 0.040 do vencedor, a $0.46 por célula, comparado aos $2.23 do Sonnet 5. Dentro da família GPT 5.6, o preço não traz nada: $0.18 (Luna) a $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.
- Kimi K3 alcança sua sexta colocação por um preço de nível médio: $1.47 por célula, perto dos $1.33 do Sonnet 4.6 mas 0.007 a mais na pontuação, e bem abaixo dos $2.23 do Sonnet 5. Inkling custa $1.64 por célula a preço de tabela por 0.575, acima do Sonnet 4.6 por uma pontuação menor.
Comparação de tempo de conclusão de tarefa & sucesso
- A melhor pontuação está entre as mais lentas. Sonnet 5 leva cerca de 30 minutos por tarefa, 3x o Sonnet 4.6 por 0.024 a mais; Sonnet 4.6 oferece quase a mesma pontuação em um terço do tempo.
- Uma execução longa geralmente indica um modelo travado, não um minucioso: os piores pontuadores, ambas as variantes Qwen, GLM 5.1 base e Deepseek V4 Pro, cada uma rodou mais de 1,700 segundos por excesso de iteração para pontuações abaixo de 0.45.
- Grok 4.3 foi rápido porque desistiu cedo: 142 segundos e 18 chamadas de ferramenta por 0.431. Grok 4.5 mantém a velocidade e abandona a desistência: cerca de 9 minutos por tarefa, menos de um terço do tempo do Sonnet 5, por 0.732.
- Kimi K3 está no extremo oposto: pontuação de elite, pior velocidade. Ele tem média de cerca de 55 minutos por tarefa, o mais lento no campo e aproximadamente o dobro do Sonnet 5, por um 0.725 de sexto lugar. Sua precisão é real, mas é o caminho menos prático para a elite.
Chamadas de ferramenta por tarefa
- A contagem de chamadas de ferramenta não mede capacidade nem esforço comparável. Sonnet 5 fez o maior número de chamadas (125) e pontuou mais alto; MiniMax M3 fez 108 para um 0.583 no meio do pelotão; Grok 4.5 alcançou 0.732 com 40; os baixos números da OpenAI, de 16 a 36, vêm do apply_patch que agrupa um arquivo inteiro em uma única chamada. Sol Pro e Terra Pro chamam um quarto a um terço menos ferramentas do que suas bases e pontuam menos: mais raciocínio, menos execução. Não classifique agentes por volume de ferramentas.
- Dois caminhos chegam à mesma pontuação: Sonnet 5 itera pesadamente (125 chamadas), Sonnet 4.6 quase não (cerca de 50), 0.024 de diferença.
LLM desempenho 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 pode concluir: quatro endpoints CRUD, validação básica, sem autenticação e sem banco de dados.
Comparação de custo & linhas de código
- Tarefas simples não podem classificar modelos, então avaliações de brinquedo enganam. Na linha de base em que todos os modelos passam, o código converge para 40 a 64 linhas e o custo cai para centavos; as diferenças aparecem apenas em trabalhos longos e com vários arquivos.
- O nível “rápido e leve” foi o mais caro aqui: Gemini 3.5 Flash base escreveu 131 linhas para a tarefa trivial, duas a três vezes o campo, tornando-se a linha de base mais cara, contra seu próprio posicionamento.
- A iteração pesada do Sonnet 5 é orientada pela tarefa, não um hábito: 9 chamadas e $0.09 aqui versus 125 chamadas no benchmark.
Veja mais detalhes no artigo de LLM Preços.
Comparação de tempo de conclusão & uso de tokens
- A previsibilidade de custos divide os modelos em dois. Modelos adaptativos gastam apenas quando necessário (Opus 4.8: 34s linha de base, 1,072s benchmark); modelos de ritmo fixo rodam lentos e caros até em trabalho trivial (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 agênticos?
Construir software é iterativo: escreva código, execute-o, leia os erros, corrija-os, repita. Sistemas de IA agêntica permitem que os LLMs sigam este mesmo ciclo. O modelo opera dentro de um ambiente de desenvolvimento onde 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 requer testes e refinamento iterativos, o que é exatamente o que a arquitetura agêntica possibilita.
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 incrementalmente. 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 uma única vez. Em configurações de tiro único, o modelo gera uma base de código inteira às cegas, sem como verificar se funciona. Em sistemas LLM agênticos, o modelo vê as consequências de cada ação e corrige o curso. 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, que é onde as diferenças de desempenho realmente surgem.
Adicionar como fonte preferencialMetodologia do benchmark de LLM agêntico
Usamos Opencode como o harness agente para todos os modelos e os conectamos através do OpenRouter, com duas exceções: Claude Fable 5 rodou no Claude Code CLI na assinatura Claude, e Inkling rodou através da API compatível com OpenAI da própria Thinking Machines porque o modelo não está disponível no OpenRouter. Cada célula foi executada 3 vezes para medir a variância por célula e estabilizar a tabela de classificação. Avaliamos sua capacidade de trabalhar autonomamente em 10 tarefas de desenvolvimento de software (T-1 a T-10), variando de sistemas de reserva a painéis interativos. Essas tarefas exigem que os agentes gerenciem projetos com vários 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 da OpenAI para o Sol usam modos de computação mais alta.1 Quatro células Sol Pro e uma célula Terra Pro terminaram em falhas repetidas de fluxo de API silenciosas, em vez de erros do modelo, e são pontuadas como falhas.
Kimi K3 e Inkling foram adicionados em 18 de julho com configurações padrão da API; Inkling rodou com seu esforço de pensamento padrão de 0.9. A coluna de custo do Inkling usa os preços de tabela da Thinking Machines de $3.74 por milhão de tokens de entrada e $9.36 por milhão de tokens de saída; o provedor cobrou cerca de metade disso sob um desconto de lançamento por tempo limitado.2 Ambos os modelos rodaram com um limite de 150 minutos por célula em vez dos 45 minutos anteriores, porque o fluxo de tokens do Kimi K3 é lento o suficiente para atingir o limite menor durante a construção; o tempo de conclusão é relatado separadamente no gráfico de tempo. A capacidade upstream compartilhada do Kimi K3 retornou erros frequentes de limite de taxa e timeout durante a janela de execução; as células afetadas foram reexecutadas uma vez contra o mesmo limite, a mesma política aplicada às falhas de fluxo do Sol Pro e Terra Pro acima.
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 lançamento. Durante esta fase, registramos os códigos de saída, o tempo de execução e se os arquivos de backend e frontend foram criados. Também rastreamos o uso de tokens em tempo real nas categorias de entrada, saída e cache.
Validação do 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 requer aderência exata ao contrato.
A pontuação geral do backend é calculada 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 funcione sem travar.
A pontuação de UI divide oito etapas em dois grupos. As etapas de infraestrutura (backend preflight, renderização do frontend, formulário de login visível, envio de login, login 2xx, sem crash em tempo de execução) medem se o aplicativo funciona. As etapas de comportamento (sinal de autenticação pós-login, sinal de comportamento pós-login) avaliam se o aplicativo executa sua função pretendida uma vez em execução.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
Etapas de comportamento bloqueadas são excluídas do denominador de comportamento, para que uma célula não seja penalizada duplamente quando o aplicativo falha ao carregar.
Cálculo de tokens
As contagens de tokens são extraídas da resposta da LLM API. Subtraímos os tokens de entrada em cache do total de tokens de entrada para obter a entrada efetiva, que reflete apenas os tokens recém-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 faça a mediação da comunicação entre clientes e agentes de suporte, aplicando rigorosamente regras de negócios e limites de segurança. Esta tarefa avalia a capacidade de um agente 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 as seguintes características:
- Permissões distintas para Clientes (emissão/resposta) e Agentes (gerenciamento/resolução).
- Um fluxo de trabalho de status rígido que impede transições ilegais e impõe ações específicas de função.
- Isolamento avançado de dados onde solicitações de recursos não autorizadas retornam 404 em vez de 403 para proteger a integridade do sistema.
- Um sistema de resposta cronológica para interação perfeita entre agente e cliente.
- Um backend FastAPI combinado com um frontend responsivo alimentado por Vite (React/Vue/Svelte).
- Configuração reproduzível por meio de comandos de shell específicos para ativação imediata do sistema.
Você pode ver 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{kalelioglu2026,
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 23 Julho 2026}
}Resultados e carimbos de data/hora de 429 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.