Claude Mythos 5 Lidera O SWE-Bench Pro Com 80,3% — Mas O Benchmark Ainda Mede O Que Promete?

Estava comparando três modelos da Anthropic para um relatório interno — alguém queria saber "qual usar" antes de fechar contrato de uma ferramenta de coding agent — quando parei numa linha que parecia trivial e não era. No leaderboard de agosto de 2026 do SWE-bench Pro, mantido pelo BenchLM, o Claude Mythos 5 aparece em primeiro lugar com 80,3%. Logo atrás, o Claude Fable 5 com 80%. Um degrau abaixo, o Claude Opus 5 com 79,2%. Três modelos do mesmo fornecedor, diferença de pouco mais de um ponto percentual entre o primeiro e o terceiro colocado.

A tentação óbvia — e imagino que comum em qualquer time nessa posição — é ler essa tabela como veredito: o modelo do topo é "o melhor", ponto final, próxima pauta. Só que a própria página do BenchLM que hospeda o ranking carrega uma nota editorial que quase ninguém lê até o fim: uma auditoria da OpenAI, publicada em julho de 2026, estimou que cerca de 30% das tarefas do split público do SWE-bench Pro estão quebradas, e a OpenAI retirou a recomendação que ela mesma tinha feito meses antes de adotar esse benchmark como referência. Fiquei olhando para aquele parágrafo por mais tempo do que para o ranking em si.

Foi esse parágrafo que me levou a um paper aceito no ICSE 2026 — o principal congresso de engenharia de software do mundo, que este ano acontece no Rio de Janeiro — chamado "The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason". Não é sobre o SWE-bench Pro especificamente; é sobre o antecessor dele, o SWE-bench Verified. Mas o que ele mostra é incômodo o bastante para mudar como eu leria qualquer ranking de benchmark de coding daqui para frente, Pro incluído.

Este post não é um teste dos três modelos — não rodei nenhum deles contra o SWE-bench Pro, nem tenho como auditar a metodologia do BenchLM linha por linha. É uma leitura do que o ranking de agosto diz, do que a pesquisa recente sobre esses benchmarks revela, e de como alguém na cadeira de quem decide ferramenta poderia separar sinal de ruído antes de citar "80,3%" numa reunião como se isso encerrasse a discussão.

---

O Que O Ranking De Agosto Mostra, Número Por Número

Os dados são do BenchLM, atualizados em 22 de agosto de 2026, cobrindo 63 modelos rastreados na categoria de coding. A ordem no topo é a seguinte:

Posição	Modelo	Score SWE-bench Pro	Fornecedor
1º	Claude Mythos 5	80,3%	Anthropic
2º	Claude Fable 5	80%	Anthropic
3º	Claude Opus 5	79,2%	Anthropic
4º	Sakana Fugu-Ultra	73,7%	Sakana AI

O próprio BenchLM descreve essa situação com uma frase que vale reproduzir: os três primeiros colocados estão "clustered within 1.1 points", o que sugere que o benchmark está próximo da saturação para modelos de fronteira. Dito de outro modo, a distância entre o primeiro e o terceiro lugar é menor que a margem de erro que qualquer um esperaria de uma avaliação com múltiplas rodadas, harnesses distintos e orçamentos de ferramentas diferentes por provedor. E entre o terceiro colocado (Opus 5, 79,2%) e o quarto (Sakana Fugu-Ultra, 73,7%) existe um salto de 5,5 pontos — maior do que toda a distância que separa o primeiro do terceiro lugar dentro do próprio pódio.

Para entender por que esse número importa, vale explicar o que o SWE-bench Pro mede. Lançado em agosto de 2025 pela Scale AI e publicado no ICLR 2026, ele contém 1.865 tarefas extraídas de 41 repositórios ativamente mantidos, cobrindo 123 linguagens de programação, divididas em três splits: 731 tarefas num conjunto público (que qualquer um pode avaliar e publicar), 858 num conjunto held-out (não divulgado, usado para detectar overfitting) e 276 num conjunto comercial, vindo de código proprietário de startups parceiras. Cada tarefa é um par de commits reais: um problema relatado, uma correção que fez os testes que antes falhavam passarem a passar sem quebrar os que já passavam.

Isso é uma ruptura de escala em relação ao antecessor. O SWE-bench Verified, lançado pela OpenAI em 2024, tinha 500 tarefas, todas em Python, extraídas de apenas 12 repositórios — mais de 200 delas vinham só do Django. A mediana de linhas alteradas por tarefa no Verified era de 4 linhas, tipicamente num único arquivo. No Pro, a mediana sobe para 107 linhas, tocando em 4,1 arquivos em média. Não é o mesmo tipo de tarefa: um mede correção pontual de bug num ecossistema estreito, o outro tenta simular o trabalho de engenharia mais próximo do que um time real enfrenta — múltiplos arquivos, múltiplas linguagens, mudanças que exigem entender a arquitetura ao redor do bug, não só a linha que falhou.

---

Por Que O SWE-bench Pro Precisou Existir

A trajetória começa em outubro de 2023, quando pesquisadores de Princeton, Stanford e CMU lançaram o SWE-bench original: 2.294 issues reais do GitHub pareadas com suas correções, vindas de 12 repositórios Python populares. O GPT-4 da época resolveu 1,7% delas. Foi descrito, corretamente, como um choque de realidade para IA de código.

Em 2024, a própria OpenAI identificou um problema no benchmark original: muitas tarefas tinham descrições ambíguas ou soluções impossíveis de inferir só pelo relatório de bug. Financiou então uma curadoria com 93 engenheiros de software revisando 1.699 tarefas, cada uma avaliada por três especialistas independentes, resultando no SWE-bench Verified — 500 tarefas de alta qualidade. Esse conjunto virou o padrão do setor, e o progresso nele foi rápido: o GPT-4 saiu de 1,7% no original para 48,5% no Verified. O Claude 3.5 Sonnet chegou a 49%.

O problema é que "rápido demais" é, em avaliação de modelo, sinal de alerta e não boa notícia. Em fevereiro de 2026, num post técnico chamado "Why SWE-bench Verified no longer measures frontier coding capabilities", a própria OpenAI anunciou que parou de reportar esse benchmark. O motivo tem duas pernas. A primeira: numa auditoria de 138 problemas difíceis — que modelos como o o3 não resolviam de forma consistente em 64 rodadas —, pelo menos 59,4% continham falhas de desenho, entre testes específicos demais (rejeitando soluções corretas) e testes amplos demais (cobrindo funcionalidade que a issue nem mencionava). A segunda: contaminação. Um esquema de red-teaming automatizado encontrou o GPT-5.2, o Claude Opus 4.5 e o Gemini 3 Flash reproduzindo verbatim o patch de referência de tarefas específicas — nomes exatos de função, comentários inline, diffs completos — a partir só do ID da tarefa.

O texto da OpenAI cita um número que resume o problema sozinho: o progresso no SWE-bench Verified, "improving from 74.9% to 80.9% in the last 6 months", desacelerou — levantando a pergunta que dá título a este post, adaptada para o benchmark anterior: as falhas restantes refletem limite do modelo ou propriedade do próprio dataset? A resposta da OpenAI foi recomendar o SWE-bench Pro como substituto, por usar splits held-out e comerciais que reduzem a exposição aos dados de treino. É por isso que hoje é o ranking do Pro que circula como referência, e não mais o do Verified. Já escrevi sobre o DeepSeek V4 batendo 80,6% no SWE-bench Verified como um marco — e é exatamente esse tipo de número que a indústria aprendeu a descontar: no SWE-bench Pro, o mesmo modelo marca 55,4%, uma queda de mais de 25 pontos.

Vale registrar, antes de seguir, que a criação do SWE-bench Pro não foi um exagero de cautela. É a resposta correta a um problema real e documentado: um benchmark amplamente usado, construído sobre repositórios públicos, é presa fácil de contaminação de treino simplesmente porque os mesmos dados que viram tarefa de avaliação também aparecem no material que treina os modelos avaliados nele. O que estou questionando não é a existência do Pro. É se a distância entre "o Pro resolve o problema do Verified" e "o Pro está livre de problema" é tão grande quanto parecia até pouco tempo atrás.

---

O Que A Pesquisa De Memorização Encontrou

O paper que me tirou do piloto automático da leitura de ranking se chama "The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason", de Shanchao Liang (Purdue), Spandan Garg e Roshanak Zilouchian Moghaddam (Microsoft). Foi aceito na trilha SE In Practice do ICSE 2026, com apresentação marcada para abril, no Rio de Janeiro.

A pergunta de pesquisa é direta: quando um modelo de fronteira resolve uma tarefa do SWE-bench Verified, ele está raciocinando sobre o bug ou reconhecendo o problema porque já viu esse repositório, essa issue ou essa correção durante o treino? Para separar as duas coisas, os autores desenharam duas tarefas de diagnóstico que isolam justamente o que um modelo "deveria" não conseguir fazer sem acesso ao repositório real. A primeira pede para o modelo identificar qual arquivo contém o bug, usando apenas a descrição da issue em texto — sem qualquer acesso à estrutura do repositório. A segunda pede para reproduzir, palavra por palavra, a função corrigida, dado apenas o arquivo atual e a descrição do problema.

Os resultados são o motivo de este post existir. Em tarefas do SWE-bench Verified, os modelos de fronteira testados atingiram até 76% de acerto identificando o arquivo com bug usando só o texto da issue — uma tarefa que, em teoria, deveria ser quase impossível sem navegar o repositório, já que a mesma descrição de bug poderia se referir a dezenas de arquivos plausíveis num projeto grande. Quando os pesquisadores rodaram o mesmo experimento em tarefas de repositórios que não fazem parte do SWE-bench, esse número caiu para apenas 53%. Uma queda de 23 pontos percentuais na mesma tarefa, com a mesma metodologia, mudando só a origem dos dados — a explicação mais direta é que o modelo carrega algum conhecimento memorizado sobre os repositórios específicos que compõem o SWE-bench, não uma habilidade geral de navegação de código transferível para qualquer repositório.

O segundo diagnóstico reforça o primeiro. Medindo a similaridade verbatim (sobreposição de 5-gramas consecutivos) entre a função gerada pelo modelo e a função de referência, os autores encontraram até 35% de acerto no SWE-bench Verified e no SWE-bench Full — contra apenas até 18% em benchmarks de codificação comparáveis, mas não relacionados ao SWE-bench. Quase o dobro de reprodução literal, exatamente nos conjuntos que os modelos tiveram mais chance de ter visto crus durante o treino. Os próprios autores são cuidadosos ao redigir a conclusão: eles não afirmam que todo o ganho de performance no SWE-bench Verified é memorização, mas que parte dele "pode ser parcialmente impulsionado por memorização em vez de resolução genuína de problemas" — o suficiente para colocar em dúvida a validade de comparações que tratam esses scores como medida direta de capacidade de raciocínio.

É importante ser preciso sobre o escopo: esse paper mede o SWE-bench Verified, não o SWE-bench Pro que lidera o ranking de agosto. O Pro foi desenhado com splits held-out e comerciais que reduzem exatamente esse vetor de contaminação — os autores do Pro sabiam do problema e tentaram endereçá-lo estruturalmente. Mas a lição do paper não é sobre um benchmark específico; é sobre uma categoria de risco que qualquer avaliação construída sobre repositórios públicos carrega em algum grau, porque o conjunto público do próprio Pro (731 das 1.865 tarefas) ainda usa código que pode circular na internet e, portanto, em dados de treino futuros. O mecanismo que a pesquisa descreve não desaparece porque o benchmark mudou de nome.

---

Mesmo O Substituto Recomendado Tem Rachadura

E é aqui que o parágrafo que me tirou do piloto automático — aquele que citei na abertura — se conecta com o resto. A OpenAI recomendou o SWE-bench Pro como sucessor do Verified em fevereiro de 2026. Cinco meses depois, em julho de 2026, uma nova auditoria da própria OpenAI sobre a qualidade das tarefas do split público do Pro estimou que cerca de 30% delas apresentam problemas — o BenchLM resume isso como "about 30% of the 731-task public split is broken" — e a OpenAI retirou a recomendação que tinha feito meses antes.

Vale separar os dois problemas, porque confundi-los rebaixa a qualidade da própria análise. A pesquisa de memorização do ICSE 2026 é sobre contaminação: o modelo já viu (ou algo parecido com) a resposta durante o treino, e parece "raciocinar" quando está recuperando memória. A auditoria de julho da OpenAI sobre o Pro é sobre qualidade de tarefa: testes malformados, descrições que não batem com o verificador, ambientes que rejeitam soluções corretas — o mesmo tipo de falha que a OpenAI já tinha encontrado no Verified antes de recomendar o Pro. São bugs de engenharia de avaliação, não memorização.

Só que o efeito prático, para quem lê o número no leaderboard, é parecido nos dois casos: o score exibido não corresponde de forma confiável à capacidade real que promete medir. Se quase um terço das tarefas do split público tem defeito, uma diferença de 1,1 ponto entre o primeiro e o terceiro colocado — a distância exata entre Mythos 5 e Opus 5 — cabe dentro da margem de ruído que os problemas conhecidos do benchmark poderiam produzir, mesmo sem diferença real de capacidade. Isso não torna o ranking inútil. Torna-o uma resposta mais grosseira do que parece: não "qual desses três é melhor", mas "esses três estão numa faixa de competência acima da maioria do mercado" — o que o salto de 5,5 pontos até o quarto colocado sustenta bem.

---

Como Um Time Poderia Ler Esse Ranking Com Mais Ceticismo

Vale um exercício hipotético aqui, porque é fácil concordar em teoria com "não confie cegamente em benchmark" e continuar citando o número do topo na próxima reunião de qualquer jeito. Imagine um time de plataforma decidindo qual modelo vai ser o padrão do coding agent interno, com o ranking de agosto do SWE-bench Pro aberto numa aba e uma data de decisão marcada para sexta-feira.

A primeira pergunta que esse time deveria fazer não é "qual modelo lidera", e sim "qual split gerou esse número". Um score do conjunto público de 731 tarefas — o mesmo que a OpenAI estimou ter cerca de 30% de problemas — não carrega o mesmo peso de evidência que um score do conjunto held-out, que por definição não circulou publicamente. A segunda pergunta é sobre o setup: harness, orçamento de ferramentas, política de retry e número de rodadas mudam taxa de acerto, e o próprio BenchLM avisa que preserva "exact published rows from different providers" — nem sempre os três modelos do pódio foram avaliados sob as mesmas condições, o que torna qualquer gap pequeno mais frágil de interpretar.

A terceira pergunta, a mais desconfortável, é sobre magnitude: dado que a diferença entre o primeiro e o terceiro colocado é menor que a margem de erro conhecida do próprio benchmark, faz sentido decidir entre Mythos 5, Fable 5 e Opus 5 com base nesse 1,1 ponto? Ou a decisão deveria olhar para outros eixos — custo por tarefa, latência, comportamento em ferramentas específicas do stack do time — que o benchmark nem tenta medir? Já escrevi sobre esse tipo de armadilha ao revisitar o ciclo de expectativa em torno do Claude Mythos original: projeção e ranking de IA carregam incerteza estrutural que nenhuma tabela bonita esconde, e reconhecer essa incerteza publicamente costuma valer mais do que fingir precisão que não existe.

---

Onde Isso Se Encaixa Na Discussão Maior De Avaliar Agentes

Nada disso é exclusivo do SWE-bench. É a mesma questão de fundo que discuti quando escrevi sobre evals como o novo teste unitário para agentes de IA: um número de benchmark público mede uma coisa — desempenho médio num conjunto fixo de tarefas, sob um setup específico — e a decisão de produto normalmente precisa de outra: desempenho no seu código, com seus padrões, sob a carga real do seu time. Um golden dataset interno, por menor que seja, tem uma vantagem que nenhum leaderboard público consegue replicar: você sabe exatamente o que está nele, porque foi você quem escreveu.

Tem também uma conexão direta com o paradoxo que descrevi ao comparar métricas de produtividade além do DORA: a métrica mais fácil de reportar — velocity individual, ou aqui, score de benchmark — nem sempre é a que captura o que importa para o sistema como um todo. Um modelo que ganha por 1,1 ponto num benchmark com 30% de tarefas com problema conhecido pode, na prática, não ser mensuravelmente melhor para o seu caso de uso do que o modelo que ficou em terceiro. Se a decisão vier só do ranking, o time comemora o número errado.

A conclusão que tiro disso tudo não é "ignore benchmark". É que o SWE-bench Pro, com todos os seus problemas conhecidos e documentados pela própria OpenAI, ainda é bem mais confiável do que o Verified contaminado que ele substituiu — os 1.865 tarefas de 41 repositórios em 123 linguagens são um avanço real de rigor metodológico, mesmo com 30% de ruído no split público. O problema nunca foi o benchmark existir. É tratar a segunda casa decimal dele como se fosse um veredito, quando a pesquisa disponível hoje sugere que ela não é.

---

Conclusão

O que fica, para mim, depois de ler o leaderboard de agosto ao lado do paper do ICSE e da nota de rodapé sobre a auditoria de julho, é uma separação que eu não fazia com clareza suficiente antes: existe a pergunta "qual modelo resolve mais tarefas desse conjunto específico" e existe a pergunta "qual modelo raciocina melhor sobre código que nunca viu antes". O SWE-bench Pro, por desenho, tenta responder a segunda pergunta melhor que qualquer antecessor seu. Mas a pesquisa recente mostra que a distância entre as duas perguntas ainda não fechou — só ficou menor.

Não tenho como afirmar que o Claude Mythos 5 é ou não é, na prática, melhor que o Claude Opus 5 para o trabalho de um time real. O ranking de agosto diz que sim, por 1,1 ponto, num split que a própria OpenAI avisa ter falhas conhecidas em cerca de um terço das tarefas. Isso não invalida o número — invalida a certeza com que normalmente tratamos números assim. E suspeito que essa incerteza vai continuar existindo enquanto benchmarks forem construídos, ao menos em parte, sobre repositórios que também alimentam o treino dos modelos que eles tentam avaliar. É um problema estrutural, não um bug que a próxima versão do benchmark resolve de vez.

Fico com uma reflexão mais modesta do que eu esperava ter quando comecei a escrever este post. Um leaderboard continua sendo o melhor ponto de partida disponível publicamente — melhor do que marketing de fornecedor, melhor do que anedota de rede social. Só que "melhor ponto de partida" é uma frase bem diferente de "resposta final", e a diferença entre as duas é exatamente o trabalho que a pesquisa sobre memorização, contaminação e qualidade de tarefa está fazendo agora, tarefa por tarefa, questionando um número de cada vez.

Fontes:

• BenchLM — SWE-bench Pro Leaderboard (August 2026)
• CodingFleet — SWE-bench Pro Explained: The New Standard for AI Coding Benchmarks (2026)
• arXiv — The SWE-Bench Illusion: When State-of-the-Art LLMs Remember Instead of Reason
• ICSE 2026 — Programação da trilha SE In Practice (SEIP)
• OpenAI — Why SWE-bench Verified no longer measures frontier coding capabilities
• arXiv — SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?