A Ornith lançou neste mês três modelos de código com pesos abertos — um flagship MoE de 397B, um 35B-A3B e um denso de 9B — treinados com um loop que nenhum lançamento público havia mostrado antes: o modelo gera suas próprias tarefas de treinamento, constrói seu próprio scaffolding de agente e executa suas próprias trajetórias de solução, tudo otimizado em conjunto por aprendizado por reforço. No Terminal-Bench 2.1, a pontuação auto-medida do flagship subiu de 77,5 para 86,1 em dois meses, acima dos 85,0 que a Ornith registrou para o Claude Opus 4.8 em sua própria configuração. Encare o número de destaque com contexto, mas o mecanismo por trás dele — automatizar o gargalo dos dados de treinamento — é a verdadeira história, e aponta onde a próxima disputa entre open e closed será travada: o banco de questões.
O gargalo não é computação. São as questões de treinamento
Treinar um modelo que realmente saiba fazer trabalho de código e de agentes custa mais que GPUs — custa tarefas de treinamento. Uma questão utilizável precisa de um ambiente executável, um verificador que julgue o certo do errado, proteções contra o modelo vasculhando submissões antigas, e dificuldade calibrada exatamente um degrau acima do que o modelo já sabe. Fácil demais, e o modelo não aprende nada; difícil demais, e nenhuma trajetória bem-sucedida sobrevive para ser reforçada. E ainda é preciso volume suficiente para realmente fazer diferença.
Humanos vêm fazendo esse trabalho, e simplesmente não conseguem acompanhar: quando um lote de tarefas é curado, o modelo já terminou de consumi-lo. Essa defasagem de oferta é uma das razões pelas quais dados de alta qualidade para treinamento de agentes são o insumo mais escasso da indústria hoje — argumentavelmente mais escassos que computação, num momento em que o preço da inferência está subindo, não caindo.
A resposta da Ornith: deixar o modelo definir seu próprio dever de casa.
Um loop fechado: gerar a tarefa, construir o scaffold, executar a trajetória
O lançamento de junho, o Ornith-1.0, já fazia algo incomum: transformava o scaffolding de agente — a bancada de trabalho que um modelo usa enquanto resolve uma tarefa — em um objeto aprendível. Cada etapa de aprendizado por reforço tinha dois estágios: primeiro mutar o scaffolding com base na tarefa e na versão anterior do scaffold, depois executar trajetórias de solução sobre ele. A recompensa fluía de volta para ambos os estágios. O modelo aprendeu a construir sua própria bancada, mas os humanos ainda forneciam as questões.
O Ornith-1.5 assume essa última tarefa humana. Dado um codebase, uma descrição de alto nível do tipo de tarefa e os próprios registros de soluções passadas do modelo, o sistema gera um lote de novas questões calibradas deliberadamente mais difíceis do que o que o modelo já resolveu — mirando suas próprias lacunas de capacidade. Em seguida, gera ou melhora o scaffolding específico da tarefa: instruções, ferramentas, estratégia de decomposição, lógica de orquestração. Por fim, executa trajetórias de solução sob a tarefa e o scaffold, e a recompensa se propaga de volta para os três estágios, atualizados em conjunto com GRPO. Geração de tarefas, construção da bancada e resolução de problemas agora formam um único loop fechado — e a curva de dificuldade sobe sozinha, sem knob de ajuste humano.
Vale contrastar isso com a disputa em curso sobre qual scaffolding de agente vencerá em produção: a mesma questão de scaffolding que os fornecedores brigam no campo, a Ornith moveu para dentro do próprio loop de treinamento.
Três sinais de recompensa — por que o modelo não pode corrigir o próprio dever de casa
A trapaça óbvia: gerar questões fáceis, inflar a pontuação, não aprender nada. A Ornith bloqueia isso multiplicando três sinais — validade × dificuldade de fronteira × novidade. A multiplicação é a escolha de design-chave: se qualquer termo se aproxima de zero, toda a recompensa pela questão desaba para zero.
Validade é um gate rígido. O scaffold realmente roda? Uma solução correta de alta confiança passa? Uma solução evidentemente errada falha? A lógica de julgamento corresponde à descrição da tarefa? Qualquer coisa que reprove no gate pontua zero — isso filtra o lixo do tipo “parece difícil, mas não pode de fato ser julgado”.
Dificuldade de fronteira é a parte inteligente. O sistema amostra várias trajetórias por questão e calcula a taxa de sucesso empírica; a recompensa atinge o pico perto de um alvo de 20%. Uma questão que o modelo resolve oito vezes em dez já foi aprendida — não tem valor de treinamento. Uma que nunca resolve não gera nenhuma trajetória bem-sucedida, então o aprendizado por reforço apenas gira em falso. O alvo é móvel: conforme uma classe de questões é dominada, a recompensa dessa classe decai automaticamente, e o gerador precisa continuar elevando a barra. O currículo se calibra sozinho contra a habilidade atual do modelo.
Novidade tem o menor peso e existe apenas para desduplicar quase-cópias de questões existentes — a equipe nota explicitamente que não é uma recompensa por questões estranhas.
Leia o 86,1 com cautela
O número de destaque é auto-medido: média de cinco execuções no ambiente e configuração da própria equipe, incluindo timeout de quatro horas, 32 núcleos, 48GB de RAM — e modificações em campos de configuração que o leaderboard oficial trava. O leaderboard oficial do Terminal-Bench 2.1 (17 entradas em 19 de agosto) nem inclui a Ornith. Nesse quadro, Claude Opus 4.8 com Claude Code está em 78,9 (5º lugar), e a entrada no topo é Claude Code + Fable 5, com 83,8. O mesmo Opus 4.8 pontua 85,0 na tabela da Ornith e 78,9 na oficial — uma diferença de 6,1 pontos. Benchmarks de agentes medem a combinação de modelo, scaffold, timeout, contexto e recursos; mude o aparato, e você muda o significado do número.
Os termos da licença merecem a mesma precisão. O rótulo MIT cobre os pesos. O repositório público no GitHub atualmente contém um README, a licença e materiais de vitrine — nenhuma implementação completa de treinamento, nenhum dataset de geração de tarefas, nenhum script de avaliação para reprodução. Pesos abertos não são o mesmo que tudo aberto.
As estrelas discretas do lançamento são os tamanhos intermediários. O 35B-A3B ativa apenas cerca de 3B de parâmetros por token, mas pontua 67,8 no Terminal-Bench 2.1 (Gemma 4-31B: 42,1, Muse Glimmer-30B: 51,7) e 79,0 no SWE-bench Verified (vs 52,0). O denso de 9B — 5,63GB comprimido, com build MLX para Apple Silicon — lidera sua classe de tamanho em código e raciocínio, mas perde em cadeias longas de ferramentas: MCP-Atlas 54,2 vs 55,0, Toolathlon-Verified 41,2 vs 52,8. O método de treinamento pode compensar a contagem de parâmetros em código puro; ainda não consegue compensar em chamadas de ferramentas em múltiplas etapas. Este é o mesmo padrão de eficiência computacional que está reformulando a economia da inferência em outros lugares, de chips customizados projetados para inferência a serving mais barato por token.
A próxima disputa é o banco de questões
Por dois anos, os modelos abertos perseguiram os flagships fechados por dois caminhos: escalar parâmetros e copiar receitas. Ambos são, na prática, copiar a folha de respostas de outra pessoa. A Ornith abriu um terceiro caminho — escrever a prova. Com a produção de dados movida para dentro do loop de aprendizado por reforço, o modelo que continua gerando questões melhores mantém seu próprio suprimento de combustível fluindo. O limite superior de um modelo não é mais apenas computação; é a qualidade do currículo com que ele treina.
Três conclusões práticas:
- Para quem lê benchmarks: trate pontuações auto-relatadas de agentes como direcionais, não comparáveis, até que apareçam em um leaderboard verificado de forma independente com configuração travada.
- Para laboratórios: a qualidade das tarefas está se tornando um ativo duradouro, do jeito que os dados de pré-treinamento foram — o currículo está se tornando o fosso competitivo.
- Para usuários: a escolha mais custo-efetiva hoje é a faixa 35B-A3B — habilidade de código quase flagship com ~3B de parâmetros ativados, barato de self-host.
O que resta aos humanos no loop é o programa: definir quais tipos de tarefa valem a prática, julgar validade e decidir o que o modelo deve aprender em seguida. O loop está fechado. O currículo, não.
FAQ
P: O Ornith 1.5 é realmente melhor que o Claude Opus 4.8 em código?
R: Não comprovado. O 86,1 é auto-medido com configuração modificada; o leaderboard oficial do Terminal-Bench 2.1 (17 entradas em 19 de agosto) não tem Ornith, e o Opus 4.8 + Claude Code está em 78,9 lá. Encare a alegação como direcional até que apareça uma execução independente.
P: O que “open source” significa para o Ornith 1.5?
R: Os pesos têm licença MIT, mas a implementação de treinamento, o dataset de geração de tarefas e os scripts de reprodução ainda não são públicos. Pesos abertos ≠ open source completo.
P: Por que a Ornith mira uma taxa de sucesso de 20% para as tarefas geradas?
R: Uma questão resolvida 8/10 vezes não ensina nada novo; uma resolvida 0/10 não produz nenhuma trajetória bem-sucedida para aprender. Por volta de 2/10 fica na borda informativa — e o alvo sobe automaticamente conforme o modelo melhora.
