Uma IA consegue manter código legado sem quebrar nada?

AI Benchmark · LEB · resultados lidos do repositório ai-benchmark

O LEB — LLM Engineering Benchmark — entrega a um agente de IA um sistema legado em produção, com falhas plantadas e consumidores que dependem de como ele se comporta hoje. Ele mede o trabalho que domina a engenharia de verdade: achar as falhas, corrigi-las, manter todos os contratos intactos e explicar as decisões como um engenheiro sênior explicaria.

Os 6 melhores até aqui

LEB-100-A

1Claude Sonnet 5.5 · xhigh809LEB Gold
2Claude Sonnet 5.5 · max807LEB Gold
3Claude Sonnet 5.5 · max (ultracode)774LEB Gold
4Claude Fable 5.1764LEB Gold
5Claude Opus 5.5717LEB Silver
6GPT-6.1-sol · xhigh661LEB Silver

Nota sobre 1000, entre 31 agentes. Não oficial até cada um ter três runs. Placar completo

Por que mais um benchmark

A maioria dos benchmarks mede código escrito do zero, ou uma issue isolada resolvida. Nenhum dos dois é o que a engenharia é na maior parte do tempo: evoluir um sistema do qual outras pessoas já dependem. O LEB pontua segurança, arquitetura, bugs, performance, código limpo, compatibilidade e a qualidade da explicação — e tira pontos do agente que reescreve tudo, troca tecnologia sem necessidade ou quebra um contrato público.

Reescrever do zero não é engenharia. É fuga.

Como funciona um run

01
Um sistema legado, com falhas plantadas
O agente recebe o código, um manifesto da sua superfície pública — o contrato — e uma tarefa neutra: reportar os problemas, corrigir o que deve ser corrigido, manter a compatibilidade e justificar cada decisão. Ele nunca sabe quais falhas existem, quantas são nem onde estão.
02
O agente trabalha sozinho
No modo A ele tem ferramentas e um orçamento de turnos; no modo S, um prompt e uma resposta. Ele devolve o código alterado, um relatório técnico e um índice dos achados, cada um com uma confiança de 0 a 100.
03
Máquinas conferem o código
Testes de caracterização rodam no legado e na entrega: comportamento público que mudou é regressão. Depois, probes atacam cada falha corrigível — o payload de injeção, o conjunto vazio, o contador de queries — e dizem se ela ainda está lá.
04
Um juiz confere o relatório
Cada achado é comparado com a Matriz Oficial de Falhas, um gabarito oculto que também tem iscas: falhas plausíveis que não existem e custam pontos quando reportadas. Um segundo juiz avalia a explicação às cegas. Um montador determinístico transforma tudo em 0–1000.

1000 pontos, e como eles se perdem

Toda instância vale exatamente 1000: os pontos brutos de cada categoria são normalizados pelo seu peso, então as notas se comparam entre instâncias do mesmo nível.

Compatibilidade começa em 100 e só desce. Migrar de mysqli para PDO sem necessidade custa 20; mudar uma assinatura pública custa 30, por função.

Penalidades globais saem do total: bug novo −15, cada teste de caracterização quebrado −20, reescrita desnecessária −25, cada isca reportada −5.

Segurança SEC250
Arquitetura ARCH200
Bugs BUG150
Performance PERF150
Código limpo CLN100
Compatibilidade COMP100
Explicação EXPL50

Selos

LEB Platinum 900–1000 · pronta para legado crítico
LEB Gold 750–899 · engenharia sólida
LEB Silver 600–749 · útil com supervisão
LEB Bronze 400–599 · requer revisão integral
Reprovada < 400 · risco ao sistema

Os runs acontecem longe do gabarito

Os agentes rodam numa VM Linux dedicada isolada do GitHub. Os nomes dele resolvem para loopback, as faixas de endereço dele (os prefixos que anuncia e os endereços de borda que publica) são rotas blackhole, e a VM não tem conectividade IPv6. Os bloqueios por endereço entraram em 30 de setembro de 2026. Os runs de 29 de setembro tiveram só o bloqueio por nome: nenhum agente alcançava o GitHub pelo nome, mas uma conexão deliberada direto a um endereço dele não era barrada, e os logs de sessão mostram que nenhuma foi tentada. Dos runs de 30 de setembro, todos menos o do Kimi K3 tiveram todas as camadas; o Kimi K3 rodou num clone da VM cujos bloqueios por endereço não foram registrados. O que um modelo viu no treino é outra questão, respondida pelo corte de treino que cada run registra.

Resultados

Todas as entregas de uma tabela resolveram o mesmo pacote, byte a byte — o mesmo SHA-256 —, então os números se comparam em pé de igualdade.

LEB-100-A v1.1 · Painel de chamados de um provedor de internet

O painel de chamados de suporte de um provedor de internet, escrito em PHP estilo 2013: funções de acesso a dados e um index.php que roteia, autoriza e monta o HTML. Cerca de 300 linhas em PHP 8, mysqli e MySQL 8, com 13 falhas plantadas e 2 iscas.

modo A · 30 turnos
edição 2026
avaliado em 2026-10-02
matriz 68088abdb7bc…

1
Claude Sonnet 5.5 Anthropic · esforço xhigh 3 de 3 runs (825 · 809 · 724)

809 de 1000 LEB Gold
- Segurança250/250
- Arquitetura25/200
- Bugs139/150
- Performance150/150
- Código limpo100/100
- Compatibilidade100/100
- Explicação45/50
Penalidades: nenhumaDescoberta 91.7Brier 0.033Scorecard
2
Claude Sonnet 5.5 Anthropic · esforço max 3 de 3 runs (807 · 773 · 820)

807 de 1000 LEB Gold
- Segurança250/250
- Arquitetura12/200
- Bugs150/150
- Performance150/150
- Código limpo100/100
- Compatibilidade100/100
- Explicação45/50
Penalidades: nenhumaDescoberta 91.7Brier 0.035Scorecard
3
Claude Sonnet 5.5 Anthropic · esforço max (ultracode) 1 de 3 runs não oficial

774 de 1000 LEB Gold
- Segurança250/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo100/100
- Compatibilidade100/100
- Explicação45/50
Penalidades: nenhumaDescoberta 87.5Brier 0.008Scorecard
4
Claude Fable 5.1 Anthropic · esforço xhigh 2 de 3 runs (781 · 764) não oficial

764 de 1000 LEB Gold
- Segurança233/250
- Arquitetura0/200
- Bugs139/150
- Performance150/150
- Código limpo100/100
- Compatibilidade100/100
- Explicação42/50
Penalidades: nenhumaDescoberta 87.5Brier 0.021Scorecard
5
Claude Opus 5.5 Anthropic · esforço xhigh 3 de 3 runs (711 · 717 · 805)

717 de 1000 LEB Silver
- Segurança233/250
- Arquitetura50/200
- Bugs139/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação45/50
Penalidades: nenhumaDescoberta 87.5Brier 0.024Scorecard
6
GPT-6.1-sol OpenAI · esforço xhigh 3 de 3 runs (666 · 653 · 661)

661 de 1000 LEB Silver
- Segurança246/250
- Arquitetura25/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade70/100
- Explicação41/50
Penalidades: nenhumaDescoberta 75.0Brier 0.000Scorecard
7
GPT-6.1-sol pro OpenAI · esforço xhigh 1 de 3 runs não oficialcorte de treino não publicado

654 de 1000 LEB Silver
- Segurança228/250
- Arquitetura0/200
- Bugs139/150
- Performance150/150
- Código limpo25/100
- Compatibilidade70/100
- Explicação42/50
Penalidades: nenhumaDescoberta 87.5Brier 0.000Scorecard
8
Grok 4.7 xAI · esforço high 3 de 3 runs (638 · 663 · 607)

638 de 1000 LEB Silver
- Segurança207/250
- Arquitetura0/200
- Bugs139/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação42/50
Penalidades: nenhumaDescoberta 83.3Brier 0.005Scorecard
9
Grok 4.6 xAI · esforço high 1 de 3 runs não oficialcorte de treino não publicado

633 de 1000 LEB Silver
- Segurança194/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo25/100
- Compatibilidade100/100
- Explicação35/50
Penalidades: nenhumaDescoberta 62.5Brier 0.007Scorecard
10
GPT-6-astra OpenAI · esforço xhigh 3 de 3 runs (661 · 596 · 628)

628 de 1000 LEB Silver
- Segurança228/250
- Arquitetura0/200
- Bugs139/150
- Performance150/150
- Código limpo0/100
- Compatibilidade70/100
- Explicação41/50
Penalidades: nenhumaDescoberta 83.3Brier 0.002Scorecard
11
GLM-5.3 Prime Z.AI · esforço high 2 de 3 runs (635 · 628) não oficialcorte de treino não publicado

628 de 1000 LEB Silver
- Segurança211/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação38/50
Penalidades: nenhumaDescoberta 70.8Brier 0.029Scorecard
12
GPT-5.6-terra OpenAI · esforço xhigh 3 de 3 runs (625 · 611 · 645)

625 de 1000 LEB Silver
- Segurança211/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação35/50
Penalidades: nenhumaDescoberta 45.8Brier 0.000Scorecard
13
GLM-5.3-Flash Z.AI · esforço high 1 de 3 runs não oficialcorte de treino não publicado

624 de 1000 LEB Silver
- Segurança211/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação34/50
Penalidades: nenhumaDescoberta 70.8Brier 0.016Scorecard
14
GLM-5.3 Z.AI · esforço high 2 de 3 runs (629 · 621) não oficialcorte de treino não publicado

621 de 1000 LEB Silver
- Segurança203/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação39/50
Penalidades: nenhumaDescoberta 70.8Brier 0.014Scorecard
15
GPT-5.6-sol OpenAI · esforço xhigh 3 de 3 runs (612 · 612 · 608)

612 de 1000 LEB Silver
- Segurança246/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade70/100
- Explicação32/50
Penalidades: -15Descoberta 70.8Brier 0.001Scorecard
16
DeepSeek V4 Flash DeepSeek · esforço high 1 de 3 runs não oficialcorte de treino não publicado

612 de 1000 LEB Silver
- Segurança224/250
- Arquitetura0/200
- Bugs139/150
- Performance150/150
- Código limpo0/100
- Compatibilidade70/100
- Explicação29/50
Penalidades: nenhumaDescoberta 70.8Brier 0.006Scorecard
17
DeepSeek V4.1 Flash DeepSeek · esforço high 3 de 3 runs (625 · 612 · 597) corte de treino não publicado

612 de 1000 LEB Silver
- Segurança203/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação30/50
Penalidades: nenhumaDescoberta 58.3Brier 0.013Scorecard
18
GPT-5.6-luna OpenAI · esforço xhigh 2 de 3 runs (599 · 601) não oficial

599 de 1000 LEB Bronze
- Segurança207/250
- Arquitetura0/200
- Bugs139/150
- Performance150/150
- Código limpo0/100
- Compatibilidade70/100
- Explicação33/50
Penalidades: nenhumaDescoberta 83.3Brier 0.003Scorecard
19
GPT-6.1-sol OpenAI · esforço ultra 1 de 3 runs não oficial

597 de 1000 LEB Bronze
- Segurança207/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade70/100
- Explicação41/50
Penalidades: nenhumaDescoberta 70.8Brier 0.001Scorecard
20
GLM-5.3-FlashX Z.AI · esforço high 1 de 3 runs não oficialcorte de treino não publicado

597 de 1000 LEB Bronze
- Segurança185/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação33/50
Penalidades: nenhumaDescoberta 70.8Brier 0.015Scorecard
21
Gemini 3.8 Flash Google · esforço high 2 de 3 runs (687 · 588) não oficialcorte de treino não publicado

588 de 1000 LEB Bronze
- Segurança181/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação28/50
Penalidades: nenhumaDescoberta 58.3Brier 0.003Scorecard
22
GPT-5.5 OpenAI · esforço xhigh 2 de 3 runs (601 · 558) não oficial

558 de 1000 LEB Bronze
- Segurança177/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade70/100
- Explicação32/50
Penalidades: nenhumaDescoberta 58.3Brier 0.006Scorecard
23
Gemini 3.8 Flash Google · esforço medium 1 de 3 runs não oficialcorte de treino não publicado

550 de 1000 LEB Bronze
- Segurança147/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação24/50
Penalidades: nenhumaDescoberta 45.8Brier 0.201Scorecard
24
Kimi K3 Moonshot AI · esforço padrão (não configurável) 1 de 3 runs não oficialcorte de treino não publicado

528 de 1000 LEB Bronze
- Segurança203/250
- Arquitetura0/200
- Bugs139/150
- Performance56/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação30/50
Penalidades: nenhumaDescoberta 70.8Brier 0.007Scorecard
25
Qwen3 Coder Next Alibaba (Qwen team) · esforço padrão (não configurável) 1 de 3 runs não oficialcorte de treino não publicado

507 de 1000 LEB Bronze
- Segurança125/250
- Arquitetura0/200
- Bugs129/150
- Performance150/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação18/50
Penalidades: -15Descoberta 54.2Brier 0.301Scorecard
26
DeepSeek V4 Pro DeepSeek · esforço high 3 de 3 runs (604 · 496 · 432) corte de treino não publicado

496 de 1000 LEB Bronze
- Segurança181/250
- Arquitetura0/200
- Bugs129/150
- Performance56/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação30/50
Penalidades: nenhumaDescoberta 58.3Brier 0.026Scorecard
27
MiniMax-M3 MiniMax · esforço padrão (não configurável) 1 de 3 runs não oficialcorte de treino não publicado

460 de 1000 LEB Bronze
- Segurança185/250
- Arquitetura0/200
- Bugs129/150
- Performance56/150
- Código limpo0/100
- Compatibilidade70/100
- Explicação20/50
Penalidades: nenhumaDescoberta 70.8Brier 0.011Scorecard
28
Kimi K2.7 Code Moonshot AI · esforço padrão (não configurável) 1 de 3 runs não oficialcorte de treino não publicado

415 de 1000 LEB Bronze
- Segurança203/250
- Arquitetura0/200
- Bugs86/150
- Performance0/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação26/50
Penalidades: nenhumaDescoberta 50.0Brier 0.225Scorecard
29
GPT-5.3-Codex OpenAI · esforço xhigh 1 de 3 runs não oficial

403 de 1000 LEB Bronze
- Segurança147/250
- Arquitetura0/200
- Bugs129/150
- Performance0/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação27/50
Penalidades: nenhumaDescoberta 37.5Brier 0.015Scorecard
30
GLM-5.2 Z.AI · esforço high 1 de 3 runs não oficialcorte de treino não publicado

388 de 1000 Reprovada
- Segurança172/250
- Arquitetura0/200
- Bugs86/150
- Performance0/150
- Código limpo0/100
- Compatibilidade100/100
- Explicação30/50
Penalidades: nenhumaDescoberta 50.0Brier 0.001Scorecard
31
Claude Haiku 4.5 Anthropic · esforço padrão (não configurável) 2 de 3 runs (317 · 369) não oficial

317 de 1000 Reprovada
- Segurança138/250
- Arquitetura0/200
- Bugs86/150
- Performance0/150
- Código limpo0/100
- Compatibilidade70/100
- Explicação23/50
Penalidades: nenhumaDescoberta 37.5Brier 0.215Scorecard

Falha por falha

O que cada agente achou e corrigiu entre as falhas plantadas. As difíceis são falhas por ausência — uma checagem de autorização que falta, uma sessão nunca regenerada, um arquivo deixado aberto no caminho de erro.

A tabela mostra os 10 primeiros de 31 agentes. O resultado de cada agente, falha por falha, está no scorecard dele.

corrigida
achada, não corrigida
não achada

Falha	Claude Sonnet 5.5 · xhigh	Claude Sonnet 5.5 · max	Claude Sonnet 5.5 · max (ultracode)	Claude Fable 5.1	Claude Opus 5.5	GPT-6.1-sol · xhigh	GPT-6.1-sol pro	Grok 4.7	Grok 4.6	GPT-6-astra
SQL injection na buscaSEC-001 · crítica · fácil	10/10corrigida	10/10corrigida	10/10corrigida	10/10corrigida	10/10corrigida	10/10corrigida	10/10corrigida	10/10corrigida	10/10corrigida	10/10corrigida
XSS refletido na buscaSEC-003 · alta · fácil	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida
Injeção de fórmula no CSV exportadoSEC-008 · média · difícil	6/6corrigida	6/6corrigida	6/6corrigida	2/6achada, não corrigida	2/6achada, não corrigida	6/6corrigida	2/6achada, não corrigida	6/6corrigida	0/6não achada	2/6achada, não corrigida
Session fixation no loginSEC-013 · alta · difícil	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida
Senhas em MD5 sem saltSEC-014 · alta · fácil	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	3/8achada, não corrigida	3/8achada, não corrigida	8/8corrigida
Segredos fixos na configuraçãoSEC-015 · alta · fácil	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	3/8achada, não corrigida	6/8achada, não corrigida	8/8corrigida
Qualquer chamado legível pelo id (IDOR)SEC-017 · crítica · difícil	10/10corrigida	10/10corrigida	10/10corrigida	10/10corrigida	10/10corrigida	9/10corrigida	9/10corrigida	10/10corrigida	10/10corrigida	9/10corrigida
Divisão por zero na média de SLABUG-001 · alta · moderada	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida
Arquivo deixado aberto no caminho de erroBUG-004 · média · difícil	5/6corrigida	6/6corrigida	4/6corrigida	5/6corrigida	5/6corrigida	4/6corrigida	5/6corrigida	5/6corrigida	4/6corrigida	5/6corrigida
Uma query por chamado para o técnico (N+1)PERF-001 · alta · moderada	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida
Um dispatcher que faz tudoARCH-002 · alta · fácil	2/10achada, não corrigida	1/10achada, não corrigida	0/10não achada	0/10não achada	4/10achada, não corrigida	2/10achada, não corrigida	0/10não achada	0/10não achada	0/10não achada	0/10não achada
Números mágicos para status e prioridadeARCH-009 · baixa · moderada	0/6não achada	0/6não achada	0/6não achada	0/6não achada	0/6não achada	0/6não achada	0/6não achada	0/6não achada	0/6não achada	0/6não achada
Quatro níveis de if aninhadoCLN-007 · média · fácil	8/8corrigida	8/8corrigida	8/8corrigida	8/8corrigida	0/8não achada	0/8não achada	2/8achada, não corrigida	0/8não achada	2/8achada, não corrigida	0/8não achada

O que chamou atenção

Seis agentes corrigiram a injeção de fórmula no CSV (SEC-008) — o Sonnet 5.5 nas três configurações, GPT-6.1-sol, GPT-5.6-sol e Grok 4.7 — com a correção que o gabarito espera; o Sonnet 5.5 é o único modelo com segurança em 250 de 250, nas três configurações. O GPT-5.6-sol também transformou o - de um chamado sem técnico em '-, um bug novo (−15).
Arquitetura foi a categoria mais fraca de todos: 50 de 200 para o Opus 5.5, 25 para o Sonnet 5.5 em xhigh e para o GPT-6.1-sol, 12 para o Sonnet 5.5 em max, e 0 para os outros vinte e sete. Ninguém separou o dispatcher que faz tudo; esses três o apontaram e decidiram não reestruturá-lo.
Ninguém quebrou o contrato mecanicamente. Os trinta e um ficaram no mysqli, mantiveram as 22 checagens de caracterização verdes e não reportaram nenhuma isca. O que os separou foi julgamento: vinte e um mantiveram compatibilidade em 100, e cada um dos outros dez mudou um valor de negócio (−30), quase sempre a média de SLA, recortada por cliente.
Dez notas são oficiais: o Claude Sonnet 5.5 em xhigh, 809 (runs de 825, 809 e 724), o Claude Sonnet 5.5 em max, 807 (807, 773 e 820), o Claude Opus 5.5, 717 (711, 717 e 805), o GPT-6.1-sol, 661 (666, 653 e 661), o Grok 4.7, 638 (638, 663 e 607), o GPT-6-astra, 628 (661, 596 e 628), o GPT-5.6-terra, 625 (625, 611 e 645), o DeepSeek V4.1 Flash, 612 (625, 612 e 597), o GPT-5.6-sol, 612 (612, 612 e 608), e o DeepSeek V4 Pro, 496 (604, 496 e 432), cada uma a mediana de três runs. Um run sozinho pode ficar mais de 100 pontos longe da mediana: o terceiro do Opus fez 805, o terceiro do Sonnet 724, o primeiro do DeepSeek V4 Pro 604, e o primeiro do astra, 661, o tinha posto em 5º, por decisões como quais falhas deixar sem correção. O Claude Fable 5.1 tem dois runs, 781 e 764, e publica o menor, em 4º
O Gemini 3.8 Flash variou 99 pontos entre dois runs em high (687 e 588) e publica o menor, 21º, Bronze. O primeiro run, em 6º, corrigiu 8 das 13 falhas plantadas e é o único fora dos Claude a achatar os ifs aninhados (CLN-007); o segundo corrigiu 7 e procurou o gabarito na VM, pelo nome e pelo hash citado na tarefa. O gabarito não está na VM, e a busca não trouxe nada que o run já não tivesse. Os dois runs mantiveram o MD5 e os dois segredos e deixaram o export CSV entregando a tabela toda a qualquer cliente. Em esforço medium o mesmo modelo fez 550 (23º) em 4,5 minutos: corrigiu 6 falhas e apontou injeção de SQL em duas funções que só recebem inteiros.
O GPT-6.1-sol é o modelo GPT mais forte aqui, oficial com 661 (runs de 666, 653 e 661), em 6º; o GPT-6.1-sol pro vem a seguir com 654, em 7º, com um run. O GPT-6-astra, oficial com 628, está em 10º. O primeiro run dele corrigiu a injeção no CSV e manteve o MD5; o run oficial fez o contrário, migrou o MD5 para password_hash e deixou a injeção no CSV como estava; o run oficial do GPT-6.1-sol corrigiu as duas
Oito horas de trabalho multiagente fizeram menos que meia hora de um agente só no mesmo esforço. O Claude Sonnet 5.5 no modo multiagente do Claude Code, em esforço max, rodou 7 workflows com 68 subagentes por 8,1 horas e US$ 233, cerca de 65 vezes o custo do run em xhigh, e fez 774 (3º, Gold). O mesmo modelo no mesmo esforço max, como agente único, levou cerca de meia hora por run e é oficial com 807 (runs de 807, 773 e 820), em 2º, 33 pontos a mais; em xhigh é oficial com 809. Corrigiu as mesmas falhas, com calibração melhor e relatório avaliado em 45 de 50, mas não mexeu na arquitetura. Nove dos subagentes caíram para um Sonnet anterior depois que um classificador de segurança os interrompeu; nada da entrega veio deles.
O GPT-6.1-sol em ultra fez 64 pontos a menos que ele mesmo em xhigh (597 contra um oficial de 661), o segundo caso aqui de mais esforço rendendo menos. Com três subagentes, achou 9 das 13 falhas plantadas contra 11, manteve o MD5, que o run em xhigh tinha migrado, e não nomeou o dispatcher. Diferente do Sonnet multiagente, levou 24 minutos, não 8 horas.
O Grok 4.7 é o modelo mais forte aqui fora da Anthropic e da OpenAI (638, 8º, Silver, oficial em três runs de 638, 663 e 607), com explicação no nível dos melhores relatórios GPT (42 de 50). No primeiro run, é também o único agente que usou a web, para ler a página do manual do PHP sobre fputcsv; a VM bloqueia o GitHub, não a web. O Grok 4.6 vem com 633 (9º), por cerca de um oitavo do custo (US$ 0,31 contra 2,43).
O GLM-5.3 Prime é o modelo GLM mais forte (628, 11º, Silver), o menor de dois runs por dois provedores (635 e 628): o primeiro corrigiu as quatro falhas cobertas por probe, a injeção no CSV entre elas, por US$ 1,69; o segundo deixou a injeção como estava. O GLM-5.3 publica 621 (14º), o menor dos seus dois runs (629 e 621), o segundo servido por outro provedor; o GLM-5.3-Flash faz 624 por cerca de um décimo do custo, e o GLM-5.3-FlashX 597
O DeepSeek V4.1 Flash é o agente mais barato aqui (de US$ 0,01 a 0,04 por run; os dois últimos levaram menos de dois minutos cada) e é oficial com 612 (runs de 625, 612 e 597), em 17º. O DeepSeek V4 Flash, rodado por outro provedor, fez 612: corrigiu oito falhas por completo, mas perdeu 30 pontos por trocar o rótulo de fallback do formatarStatus. A DeepSeek agora direciona o nome V4 Flash para o V4.1 na própria API, então não é certo quais pesos aquele provedor serviu. O DeepSeek V4 Pro, o modelo maior, é oficial com 496, a mediana de três runs por dois provedores (604, 496 e 432), todos abaixo dos Flash: o primeiro dá confiança 100 a injeção de SQL em duas funções que só recebem inteiros, e os outros dois deixaram a query N+1 no lugar.
Vinte agentes não rodaram em xhigh. O MiniMax-M3, o Kimi K2.7 Code, o Qwen3 Coder Next e o Claude Haiku 4.5 não têm ajuste de esforço e rodaram no padrão do modelo; o Kimi K3 foi registrado no padrão dele; os dois modelos Grok, os cinco modelos GLM, os três modelos DeepSeek e o Gemini 3.8 Flash rodaram em high, no opencode, e o Gemini 3.8 Flash também em medium; o Sonnet 5.5 rodou duas vezes em max, uma delas no modo multiagente, e o GPT-6.1-sol uma vez em ultra. Os demais rodaram em xhigh.
Kimi K3, Qwen3 Coder Next, DeepSeek V4 Pro, MiniMax-M3, Kimi K2.7 Code, GPT-5.3-Codex, GLM-5.2 e Claude Haiku 4.5 fecham a tabela (528, 507, 496, 460, 415, 403, 388 e 317; os dois últimos abaixo da linha de aprovação). O Claude Haiku 4.5, último, publica o menor dos seus dois runs (317 e 369); no primeiro, de 2,5 minutos e US$ 0,21, a correção de visibilidade dele esconde os próprios chamados de um cliente na página principal, ao comparar um inteiro com a string que o mysqli devolve. Todos menos o Qwen3 Coder Next deixaram a query N+1 no lugar. O Qwen3 Coder Next tem a explicação mais fraca (18 de 50) e a pior calibração (Brier 0,301): reportou com confiança 100 três falhas que não podem existir, entre elas injeção de SQL em duas funções que só recebem inteiros, como o Kimi K2.7 Code. Também não rodou nenhum teste.
Do 8º ao 20º lugar a diferença é de 41 pontos (638 a 597), dentro do ruído de um run único. O GPT-5.6-terra reportou o menor número de falhas plantadas e mesmo assim ficou em 12º, pela compatibilidade e pelo que corrigiu.
Os modelos GPT estão entre os mais bem calibrados (Brier de 0,015 ou menos): menos achados, cada um com confiança alta e quase todos reais.

Achar não é corrigir

Lado a lado, os três modelos Claude acham quase as mesmas falhas e corrigem quantidades diferentes delas. Um total só esconde qual das duas coisas está medindo.

Eles acham quase o mesmo. No run que conta de cada um, o Sonnet 5.5 em xhigh reportou 12 das 13 falhas plantadas e o Fable 5.1 e o Opus 5.5, 11; nos oito runs somados, cada um achou 11 ou 12
Sonnet 5.5 corrige mais, no run que conta. O run oficial dele corrigiu 11 das 13, contra 9 do run oficial do Opus e 10 do Fable. Run a run, varia: o Sonnet corrigiu 11, 11 e 8, o Opus 9 em cada um dos três, o Fable 9 e 10. Fable e Opus acharam e explicaram a injeção de fórmula no CSV e a deixaram no lugar, para proteger quem consome o arquivo; o Sonnet a corrigiu em dois dos três runs, prefixando só as células que começam uma fórmula. A vantagem de 92 pontos sobre o 717 oficial do Opus vem de código limpo (+100), não de segurança (+17); a de 45 pontos sobre o 764 do Fable vem de segurança (+17) e arquitetura (+25)
Mais computação não mudou o padrão. Os runs dos Claude de um agente só levaram de 16 a 27 minutos cada, e os três do mesmo esforço max fizeram 807, 773 e 820. O Sonnet 5.5 no modo multiagente levou quase 8 horas e US$ 233, cerca de 25 vezes o tempo e 65 vezes o custo do seu run de um agente só, e fez menos pontos: as mesmas correções e uma verificação mais funda do próprio código, mas o dispatcher que o run de um agente só nomeou nunca chegou ao relatório.
Como ler. Nesta tarefa os três modelos Claude enxergam os mesmos problemas; o que os separa é até onde vão para corrigi-los dentro do contrato. Na mediana, o Sonnet foi mais longe; um run sozinho pode inverter isso, como o terceiro do Sonnet. Uma tarefa, dois ou três runs por modelo: um padrão para testar, não um veredito

Leia isto antes de citar um número

Até três runs por agente. A nota oficial do LEB é a mediana de três runs independentes. Enquanto um agente não tem os três, a nota dele é o menor dos totais até aqui, os totais aparecem ao lado, e tudo o que se mostra com a nota vem desse mesmo run.
O juiz é uma IA. O Claude Opus 5.5 aplicou a rubrica publicada a cada entrega sem saber qual modelo a escreveu — todas foram anonimizadas —, e a explicação foi avaliada por um juiz separado, que não viu nem o gabarito nem as outras notas.
O juiz também é competidor. O Claude Opus 5.5 é um dos agentes avaliados, e seis dos trinta e um são modelos Claude, o Sonnet 5.5 três vezes: ocupam os cinco primeiros lugares e o último. O anonimato limita esse viés; não o elimina, porque um modelo pode reconhecer o próprio estilo. Cada veredito é publicado com a justificativa, falha por falha, e os quatro vereditos alterados na revisão dizem por quê; um deles soma 41 pontos ao total do GPT-5.6-terra.
Dez tentativas ficaram sem nota, todas antes de qualquer juiz vê-las. Duas vezes, as salvaguardas do Claude Fable 5.1 interromperam uma resposta enquanto ele trabalhava nas falhas de segurança, e o cliente passou o resto do run para o Claude Opus 4.8, que escreveu o relatório inteiro; um run precisa vir de um modelo só, então as duas foram anuladas, e o Fable 5.1 mostra os seus dois runs completos. Quatro terminaram por falha do provedor antes de a entrega ficar completa: o GPT-5.6-sol pro quando o gateway ficou sem crédito, e o Gemini 3.8 Flash três vezes, num timeout do gateway e duas vezes por limite de requisições. Três foram montadas errado: o primeiro run multiagente do Sonnet 5.5 foi interrompido para dar mais processadores à máquina, a primeira tentativa do Claude Haiku 4.5 teve o modo do cliente trocado no meio, e uma tentativa do Gemini começou fora da pasta da tarefa. Uma terminou, mas o GPT-5.6-terra rodou num cliente diferente do primeiro run e foi repetido no mesmo cliente. As dez ficam guardadas no repositório.
O gabarito é público. A matriz de falhas da LEB-100-A está no repositório público desde 13 de julho de 2026. Os runs de 29 de setembro tiveram só o bloqueio por nome da VM, então nenhum agente conseguia buscá-la por acidente; os de 30 de setembro tiveram também os endereços do GitHub bloqueados, e os logs de sessão de todo run que deixou um não mostram nenhuma requisição ao GitHub. O que um modelo viu no treino depende de até onde vão os dados de treino dele: cada run registra o corte que o provedor publica, e um modelo com corte posterior, ou não publicado, aparece marcado no placar.
Os testes do próprio benchmark foram corrigidos. Pontuar estes runs expôs dois defeitos na ferramenta de avaliação: um carregador de SQL que partia um statement num ponto e vírgula dentro de comentário, e checagens do CSV que liam um arquivo temporário que o contrato nunca prometeu. Os dois foram corrigidos antes da pontuação, igual para todos os agentes, e estão registrados no repositório.
A máquina mudou em 30 de setembro. Até então os agentes rodavam como o administrador da VM, com sudo, numa máquina que guardava o que os runs anteriores deixaram. Os logs de sessão não mostram nenhum agente lendo o trabalho de outro; os agentes do opencode compartilharam um banco de teste remanescente, que só tinha as linhas do seed. A partir do Qwen3 Coder Next, os runs são feitos por um usuário sem privilégios, numa máquina limpa antes de cada run.
Nem todo parâmetro dos runs foi registrado. A versão exata do modelo e a temperatura não foram, e custo e tempo de modelo só onde o cliente os guardou; os runs do GPT-5.5, do MiniMax-M3 e do Kimi K3 não deixaram log de sessão nenhum. Cada run marca o que falta, em vez de chutar.

Audite

Cada entrega, relatório mecânico, veredito e scorecard está no repositório, ao lado da especificação que os produziu. Os mesmos dados estão aqui em duas planilhas: uma linha por run, e uma por run e falha plantada.

Resultados no GitHub Especificação Runs (CSV) Falha por falha (CSV) O que cada coluna significa

Os números desta página não são digitados à mão: saem dos resultados publicados no repositório ai-benchmark, os mesmos que o samirhv.com.br mostra.