Ox Alpha quebra código existente? O que os testes de regressão realmente mostram

O medo de quem solta IA numa base madura não é "será que ela resolve a tarefa?"

É "será que ela quebra o que já estava funcionando?"

Fala aí, beleza? O Ox Alpha apareceu como modelo stealth no OpenRouter em 20 de agosto de 2026, sob o identificador stealth/ox-alpha, e virou assunto numa velocidade absurda

O detalhe é que o provedor por trás dele segue anônimo, nenhum laboratório assumiu o modelo até 24 de agosto de 2026, e mesmo assim os prints de benchmark já estavam rodando em todo lugar

Só que a nota do benchmark é a parte menos útil da conversa pra quem mantém código legado

O que importa mesmo é o indicador de regressão: quantos testes que já passavam continuaram passando depois que o modelo mexeu no repositório

E é aí que a história do Ox Alpha fica muito mais interessante (e bem mais torta) do que o hype vendeu

O que é o DeepSWE e por que 51.469 não é o benchmark inteiro:

Bora desfazer a confusão antes de olhar qualquer número

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

O DeepSWE é um benchmark de engenharia de software de horizonte longo, lançado pela Datacurve em 26 de maio de 2026, com leaderboard público

Horizonte longo? É tarefa que não se resolve numa tacada só: o modelo precisa navegar o repositório, entender o que está acontecendo, editar arquivos e sustentar o raciocínio por muitos passos

A composição dele é o que dá peso ao teste: 113 tarefas originais, em 91 repositórios open source e 5 linguagens, com verificadores escritos à mão e sem soluções copiadas de pull requests públicos

Esse último ponto é ULTRA importante

Verificador escrito à mão significa que alguém sentou e definiu o que é "certo", em vez de deixar o critério nascer do mesmo lugar que a solução

É o mesmo problema de deixar a IA escrever teste e código juntos: quando as duas pontas saem da mesma cabeça, a verificação vira teatro

Fail-to-pass e pass-to-pass: a diferença que muda tudo

Cada tarefa do DeepSWE tem dois grupos de teste, e eles medem coisas opostas

Fail-to-pass é o que está quebrado e a tarefa pede pra consertar

Eles falham antes, e precisam passar depois

Pass-to-pass é o resto da suíte: o que já passava e NÃO pode quebrar

Esse segundo grupo é o teste de regressão propriamente dito

Se você conhece a sensação de rodar a suíte inteira depois de um refactor grande só pra ver se não explodiu nada, é literalmente isso, automatizado e contado

E o famoso 51.469?

Aqui mora o mal-entendido que circulou

51.469 é a contagem de testes pass-to-pass de UMA tarefa específica do DeepSWE, a meriyah-explicit-resource-declarations

Não é o benchmark inteiro, não é a soma de tudo, é uma tarefa só, num projeto com suíte gigante

O resultado publicado nessa tarefa foi 48/49 nos fail-to-pass e 51.468/51.469 nos pass-to-pass

Ou seja: o modelo consertou quase tudo que devia consertar e deixou quase toda a suíte existente de pé

Mas "quase" tem consequência, e já já a gente chega nela

O run completo das 113 tarefas, que está documentado no repositório MatchaOnMuffins/oxalpha, rodou com o harness mini-swe-agent usando a configuração padrão mini.yaml

Guarde esse detalhe: harness padrão vai explicar uma fatia grande das falhas lá na frente

Ox Alpha x Claude Fable 5 x GLM-5.3 x GPT-5.6-sol: o que cada número mede

Tem três recortes diferentes rodando na internet como se fossem a mesma coisa, e eles não são

O primeiro é o recorte independente de 10 tarefas, conduzido pelo desenvolvedor Ben Davis

É daí que saiu o número viral de 80%

Não do leaderboard oficial, e sim de um teste independente com dez tarefas

Agora os três recortes lado a lado, que é o que realmente resolve a discussão:

Repara na terceira linha, porque ela é o coração do post

Com apenas 2 asserções falhando em cerca de 51.500, o Ox Alpha recebeu nota zero naquela tarefa

A pontuação do benchmark é binária: passou tudo ou não passou

Na prática, ele pontuou igual a um modelo que não fez absolutamente nada

E não é que a tarefa fosse fácil pros outros: nessa mesma meriyah, outros modelos de fronteira já tinham falhado por completo, entre eles o GLM-5.3, o GPT-5.6-sol e também o Grok 4.6, que nem aparecia no recorte de 10 tarefas lá de cima

Por fim, o registro honesto: até 24 de agosto de 2026 o Ox Alpha não tem entrada no leaderboard oficial do DeepSWE nem índice no Artificial Analysis

Tudo que existe é teste de terceiro, com harness de terceiro 🙂

Quando esse indicador importa (e quando ele não te salva)

Beleza, e como isso vira decisão prática?

Onde o sinal de regressão pesa muito:

• Refatoração ampla, aquela que toca dezenas de arquivos e depende da suíte inteira pra provar que nada mudou de comportamento
• Migração de API interna, onde o risco não está na mudança em si, e sim no efeito colateral três camadas abaixo
• Base com suíte grande e madura, o cenário exato da meriyah: 51 mil e poucos testes existentes, e o modelo derrubando 2

Tem outro dado do run completo que conta a mesma história: 80% das tarefas, ou seja 90 de 113, passaram ao menos 90% dos seus testes fail-to-pass

Traduzindo: quando ele erra, na maioria das vezes ele erra por pouco, em vez de sair estragando o resto

Esse padrão é bem diferente de um modelo que "resolve" a tarefa arrancando código pelo caminho

Tem também o comportamento em fluxo agêntico longo, que é onde muita coisa desanda: num fluxo documentado, foram 69 chamadas de ferramenta com 1 erro e sem loops de retry

Consistência ao longo de muitas chamadas é o que separa um agente que trabalha de um que fica girando em falso queimando token

Onde o número NÃO te salva:

Primeiro problema, e ele é grande: 9,7% do benchmark foi perdido porque o modelo devolveu resposta sem nenhuma tool call três vezes seguidas, o que aborta o episódio

Isso não é falha de raciocínio

É falha de formato de chamada de ferramenta, e depende diretamente do harness que você usa (lembra do mini.yaml padrão lá de cima?)

Ou seja: parte do resultado ruim pode ser da cola entre modelo e ferramenta, não do modelo pensando errado

Segundo problema, e esse é sobre VOCÊ: teste de regressão só é sinal se existir suíte

Se o seu projeto tem cobertura fraca, ou tem teste que só reafirma o que o código já faz, o modelo pode passar 100% e ter quebrado meio sistema

Por isso vale tanto a pena pedir testes que realmente verificam antes de soltar qualquer modelo pra refatorar

Sem suíte decente, esse indicador todo vira zero informação

Vídeo: a evolução do vibe coding para a IA não quebrar nada

A lógica de "mede o que já passava, não só o que foi consertado" não nasceu com o Ox Alpha, ela é a base de qualquer fluxo sério de IA em código

Pra começar do zero nesse assunto de manter a base de pé enquanto a IA edita, este vídeo do canal mostra a ideia de Loop Engineering aplicada ao vibe coding:

Veredito: confiabilidade em refatoração ou só um número bonito?

Vou de posição honesta, com os dois lados

A favor: preservação de comportamento quase total na tarefa medida, e falha por margem estreita na maior parte do benchmark

Esse é exatamente o padrão que interessa em base legada: eu prefiro um modelo que erra 2 asserções em 51 mil a um que "acerta a tarefa" e me devolve um efeito colateral escondido

Contra: a taxa real do run completo foi 58,4%, ou seja, bem longe dos 80% que viralizaram num recorte de apenas dez tarefas

Soma nisso os 9,7% do benchmark perdidos por falha de formato de chamada de ferramenta e a ausência de entrada oficial em qualquer leaderboard de referência

E a nota binária esconde a nuance nos DOIS sentidos: ela enterra o quase-acerto, mas também esconderia um acerto sortudo, e nenhum dos dois casos aparece na tabela do leaderboard

É indício, não é aprovação

E tem os riscos operacionais, que pesam bastante na decisão de usar hoje:

• Provedor anônimo: o modelo é desenvolvido e operado por um terceiro que optou por permanecer anônimo durante o preview
• Hipótese da comunidade: apontam a Zhipu AI (Z.ai) por pistas da camada de serviço, stack trace Java, código de erro 1214 idêntico e 30/30 correspondências de tokenizer com o GLM-5.3, mas a Zhipu não confirmou nem negou
• Política de dados: a página do modelo diz que prompts e respostas são retidos pelo provedor e não são usados para treino, com o restante do uso seguindo os Stealth Model Terms
• Preço: US$ 0,00 por milhão de tokens de entrada e US$ 0,00 por milhão de tokens de saída durante o preview, com a gratuidade anunciada como temporária (a nota de lançamento do OpenCode falava em cerca de uma semana a partir de 20 de agosto de 2026, sem data exata de corte)

Um fator prático que joga a favor em refatoração ampla: 1.048.576 tokens de contexto e até 131.072 tokens de saída

Isso é espaço pra colocar módulo inteiro na mesa em vez de fatiar o problema até ele perder o sentido

Mas contexto grande não é garantia de nada sozinho, é só a condição pra tentar

Conclusão

O indicador de regressão diz mais sobre confiabilidade do que qualquer nota isolada, e a lição do 51.469 é justamente essa: o mesmo run que mostra 51.468 testes de pé recebeu reward 0

O benchmark não tem como te contar isso, mas o seu repositório tem

Então o próximo passo é simples: use a sua própria base como benchmark

Meça a taxa de testes que já passavam e continuaram passando depois da edição do modelo, e trate nota de benchmark como indício, nunca como aprovação

Enquanto o preview estiver gratuito, o custo do experimento é baixo, e isso é raro

Só não conte com a janela: ela foi anunciada como temporária, e ninguém divulgou data exata de corte…

até o próximo post! 😀