OpenAI Diz Ter Resolvido Navier-Stokes: 10 Mil Agentes, 88 Horas e a Briga Pelo Crédito do Problema do Milênio

Olá HaWkers, na terça-feira, 8 de setembro de 2026, a OpenAI publicou o que chama de resolução do problema de existência e suavidade de Navier-Stokes, um dos sete Problemas do Milênio do Clay Mathematics Institute, cada um com prêmio de US$ 1 milhão. Segundo a empresa, um modelo interno ainda não lançado, operando como um enxame de cerca de 10 mil agentes, chegou ao resultado em 88 horas e a prova foi verificada formalmente em Lean. Doze horas antes, o matemático Tristan Buckmaster, da NYU, tinha publicado uma nota de quatro páginas acusando a OpenAI de correr atrás do mesmo caminho depois de saber do trabalho dele com Levent Alpöge, matemático da Anthropic.

Vale a pergunta direta: o que exatamente foi provado, o que isso tem a ver com quem escreve software, e por que a comunidade matemática está mais preocupada com a forma do que com o resultado? Neste artigo você vai entender o problema em linguagem de engenheiro, o que significa uma prova verificada em Lean, os números reais divulgados até agora, a cronologia da disputa e o que ainda falta para alguém receber o prêmio.

O Que É o Problema de Navier-Stokes

As equações de Navier-Stokes descrevem o movimento de fluidos: água num cano, ar em volta de uma asa, fumaça subindo de uma chaminé. Engenheiros as resolvem numericamente todo dia em simulações de CFD. O problema do Clay Institute, formulado em 2000 por Charles Fefferman, de Princeton, é outro: ele pergunta se, em três dimensões, uma solução que começa suave pode desenvolver uma singularidade em tempo finito, o que os matemáticos chamam de blowup. Em termos práticos, se a velocidade ou a vorticidade do fluido pode ir para o infinito num ponto, num instante específico, mesmo com energia total limitada.

Durante quase 90 anos ninguém conseguiu provar nem que isso acontece nem que não acontece. O enunciado oficial de Fefferman oferece quatro variantes, identificadas como (a), (b), (c) e (d). As duas primeiras tratam do fluido sem força externa; as duas últimas, (c) e (d), permitem uma força externa suave atuando sobre o fluido. Provar blowup em qualquer uma delas resolve o problema. O resultado da OpenAI, segundo a empresa, é justamente um blowup em tempo finito com forçamento suave, no espaço tridimensional inteiro e no toro, ou seja, as opções (c) e (d).

Por Que "Forçamento Suave" É a Palavra-Chave

Aqui está o detalhe que explica toda a disputa. Existe um programa de pesquisa, aberto pelos espanhóis Diego Córdoba, do ICMAT em Madri, e Luis Martínez-Zoroa, da CUNEF, que constrói singularidades empilhando camadas de soluções não singulares numa cascata infinita. Por volta de 2023 eles já tinham blowup para Euler com forçamento irregular. O que faltava era fazer a mesma cascata produzir uma singularidade e, ao mesmo tempo, manter a força externa suave. Esse era o último obstáculo, e quase ninguém no mundo trabalhava nele. Fefferman, autor do enunciado do prêmio, chamou os dois de "os heróis" da história ao falar com a Quanta Magazine.

O Que a OpenAI Afirma Ter Feito

O post da OpenAI descreve um processo em duas fases. Primeiro, cerca de 100 agentes trabalharam por 50 horas nas equações de Euler, a versão sem viscosidade do problema. Depois, aproximadamente 10 mil agentes passaram 88 horas atacando Navier-Stokes propriamente dito, com o resultado alcançado no sábado, 5 de setembro. Segundo o próprio post, foram cerca de 130 bilhões de tokens de saída só na parte de Navier-Stokes e 2,7 milhões de mensagens trocadas entre agentes, chegando a 4,9 milhões contando os outros problemas. Em seguida, 17 horas adicionais com o modelo GPT-6 Astra produziram a formalização em Lean.

Os números de custo variam conforme a fonte. Sébastien Bubeck, pesquisador da OpenAI, falou em "vários milhões de dólares" à Quanta; a Fortune estimou em torno de US$ 2 milhões a partir de uma comparação com desafios anteriores; a TechCrunch citou um valor bem maior. Não há número oficial, então o mais honesto é dizer que foi um esforço de milhões de dólares em computação concentrado em menos de duas semanas. O prazo também é confirmado pela empresa: o trabalho começou em 1º de setembro, motivado por rumores de que a Anthropic estaria perto de resolver o problema.

Um ponto raramente destacado nas manchetes: a OpenAI afirmou no post que não pretende reivindicar o prêmio de US$ 1 milhão. O objetivo declarado é demonstrar a capacidade do modelo, que a empresa descreve como um sistema interno com desempenho inédito em benchmarks de matemática.

Prova Verificada em Lean: O Que Isso Significa Para Você

Quem programa entende Lean melhor que a maioria dos jornalistas. Lean é uma linguagem de programação com um sistema de tipos tão expressivo que uma proposição matemática vira um tipo, e uma prova vira um termo desse tipo. Se o código compila, a prova está correta em relação aos axiomas e às definições usadas. É o mesmo princípio que faz um compilador rejeitar um string onde se esperava um number, só que aplicado a teoremas.

-- Lean 4: uma proposição é um tipo, uma prova é um valor desse tipo.
-- Se este arquivo compila, o teorema está provado.
theorem soma_comutativa (a b : Nat) : a + b = b + a := by
  -- 'omega' resolve aritmética linear sobre naturais e inteiros
  omega

-- Definições erradas compilam também: a verificação garante
-- coerência com o enunciado escrito, não com a intenção do autor.
theorem exemplo_de_alerta (n : Nat) : n + 0 = n := by
  rfl

A ressalva do segundo bloco importa. Uma prova em Lean garante que o enunciado formalizado segue dos axiomas. Ela não garante que o enunciado formalizado é o mesmo enunciado do prêmio Clay. É por isso que a comunidade quer ler os cerca de 100 páginas da prova em linguagem humana: alguém precisa conferir que as definições de "solução suave", "forçamento suave" e "energia limitada" batem com as de Fefferman. Buckmaster escreveu na nota dele que se recusou a publicar apenas um certificado Lean junto de um preprint sem polimento, porque "a primeira coisa que alguém lê deveria ser um argumento matemático apresentado da forma normal".

Visualizando um Blowup em Código

Não dá para simular Navier-Stokes 3D num post, mas dá para ver o fenômeno em uma dimensão com a equação de Burgers sem viscosidade, que é o exemplo clássico de singularidade em tempo finito. A velocidade se transporta a si mesma, as partes rápidas alcançam as lentas e o gradiente vai para o infinito em um tempo previsível.

# Equação de Burgers invíscida: u_t + u * u_x = 0
# Solução via método das características: cada ponto anda com velocidade u.
# O gradiente diverge em t* = -1 / min(u0'(x)), o "blowup" em tempo finito.
import numpy as np

x0 = np.linspace(-np.pi, np.pi, 2001)
u0 = -np.sin(x0)                      # perfil inicial suave
du0 = -np.cos(x0)                     # derivada analítica do perfil
t_star = -1.0 / du0.min()             # instante teórico da singularidade

for t in [0.0, 0.5 * t_star, 0.9 * t_star, 0.99 * t_star]:
    x = x0 + u0 * t                   # características: x(t) = x0 + u0 * t
    # gradiente ao longo das características: u_x = u0' / (1 + u0' * t)
    grad = du0 / (1.0 + du0 * t)
    print(f"t = {t:.3f}  |u_x| máximo = {np.abs(grad).max():.1f}")

print(f"blowup previsto em t* = {t_star:.3f}")

Rode isso e o gradiente máximo cresce de 1 para dezenas, centenas, e explode ao se aproximar de t* = 1. Em Burgers isso é fácil porque a equação é escalar e sem pressão. Em Navier-Stokes 3D a pressão é não local, a viscosidade suaviza e a incompressibilidade acopla as três componentes. É por isso que o problema resistiu por décadas e por que a rota do forçamento suave, que dá ao matemático um grau extra de controle, foi a que abriu caminho.

A Cronologia da Disputa

Os fatos abaixo vêm da nota pública de Buckmaster, das reportagens da Quanta, TechCrunch, Fortune e Axios, e da resposta da OpenAI. Onde há contradição, marquei.

Há cerca de um ano: Buckmaster e Alpöge começam a colaboração pessoal, sem acordo institucional. Usam Claude, da Anthropic, e Codex, da OpenAI, com os modelos GPT-5.6 Sol e, mais tarde, Astra. Buckmaster paga a conta com verba própria de pesquisa.
15 de agosto de 2026: os dois obtêm blowup com forçamento suave para Boussinesq e para Euler 3D. Buckmaster descreve a primeira prova gerada pelo modelo como "a mais horrenda que já li".
22 de agosto: a prova de Euler é verificada em Lean.
1º de setembro: segundo a própria OpenAI, começa o esforço interno, motivado por rumores de que a Anthropic estava perto de um resultado.
3 de setembro: Buckmaster escreve a um matemático da OpenAI avisando que o trabalho existe e será publicado em breve. A resposta oferece computação e pede detalhes "para evitar competir".
6 de setembro: em duas chamadas com Bubeck, Buckmaster é informado de que um modelo interno provou blowup forçado para Navier-Stokes. Segundo ele, foram oferecidas duas propostas, ambas condicionadas a remover Alpöge da autoria por trabalhar na Anthropic. Ele recusou. A nota atribui a Bubeck as frases "Por que você arruinaria sua carreira?" e "Se você não quer que eu seja legal, eu não preciso ser legal".
7 de setembro, meia-noite: Buckmaster publica a nota e três artigos: blowup com forçamento suave para meios porosos incompressíveis, Boussinesq e Euler 3D incompressível.
8 de setembro, manhã: a OpenAI publica a prova de Navier-Stokes.

A resposta da OpenAI tem duas frases centrais. A primeira: "Nós (os pesquisadores e os agentes) não vimos nenhum trabalho deles por nenhum meio até que fosse tornado público". A segunda, sobre dados de uso: "Embora improvável, não podemos descartar que dados desidentificados derivados do uso deles dos nossos produtos tenham ajudado a melhorar nossos modelos". Bubeck também afirmou que o resultado de Euler foi obtido por um método totalmente diferente do de Buckmaster e Alpöge, embora reconheça que o caminho para Navier-Stokes seguiu a mesma rota.

O Que Está em Jogo Para Quem Usa Ferramentas de IA

Deixe a matemática de lado por um minuto. Buckmaster e Alpöge fizeram todo o trabalho dentro de sessões do Codex, incluindo os rascunhos. Quando perguntou se o modelo tinha sido treinado nessas sessões, a resposta foi que o modelo "não consulta dados de usuário". Sobre treinamento, ele diz não ter recebido resposta. Se você usa um assistente de código num projeto que ainda não é público, a pergunta é a mesma: o que "usado para melhorar o modelo" significa na prática, e quem garante que o resultado do seu trabalho não reaparece do outro lado?

Isso não é paranoia de acadêmico. É a mesma discussão que apareceu quando a OpenAI lançou um ambiente de trabalho para cientistas, que cobri em OpenAI lança ambiente de trabalho para cientistas com Deep Research. Quanto mais pesquisa de fronteira roda dentro de ferramentas de uma empresa que também compete pela descoberta, mais peso têm as políticas de retenção e treinamento. Vale conferir, no seu plano, se as sessões são excluídas de treinamento por padrão e se existe modo de retenção zero.

Um padrão de engenharia que a história ensina, independente de quem estiver certo, é o do verificador independente. O enxame da OpenAI produz candidatos; o Lean rejeita o que não fecha. É um gate determinístico na frente de um gerador probabilístico, e serve para qualquer pipeline com agentes.

// Padrão gerador + verificador: agentes propõem, um checador
// determinístico decide. Nenhuma proposta passa sem aprovação.
type Proposta = { id: string; conteudo: string };
type Veredito = { ok: boolean; motivo?: string };

async function enxame(
  gerar: (semente: number) => Promise<Proposta>,
  verificar: (p: Proposta) => Promise<Veredito>,
  tentativas: number,
): Promise<Proposta | null> {
  // dispara os geradores em paralelo; cada um recebe uma semente diferente
  const propostas = await Promise.all(
    Array.from({ length: tentativas }, (_, i) => gerar(i)),
  );

  for (const p of propostas) {
    const v = await verificar(p); // aqui entra o Lean, um test runner, um linter
    if (v.ok) return p;           // primeira proposta aprovada vence
    console.warn(`proposta ${p.id} rejeitada: ${v.motivo}`);
  }
  return null; // nenhuma passou: melhor falhar do que aceitar sem prova
}

Troque verificar por tsc --noEmit, por uma suíte de testes ou por um schema validator e você tem a versão de produção do que aconteceu com Navier-Stokes. A diferença é escala: 10 mil geradores, 88 horas e um verificador que não aceita "quase certo".

O Que Terence Tao e a Comunidade Estão Dizendo

Terence Tao, da UCLA, não entrou na disputa de crédito. A preocupação dele, citada pela Fortune, é sistêmica: a "mineração indiscriminada de problemas abertos em busca de soluções" pode "destruir o ecossistema do qual a próxima geração de técnicas, problemas e praticantes matemáticos teria se desenvolvido". Problemas abertos são o material de formação de doutorandos. Se cada um deles vira alvo de um enxame de agentes assim que um rumor circula, o que sobra para treinar a próxima geração?

Buckmaster faz um ponto parecido na nota. Ele diz que pretendia anunciar seus resultados dizendo que "os resultados não são a coisa importante"; o importante seria que um matemático e um modelo agora conseguem fazer tudo isso em um mês, um "momento Deep Blue versus Kasparov" para a área. Em vez disso, ele se viu escrevendo sobre quem ligou para quem. Ele também assume que os artigos dele saíram mal escritos pela pressa, chegando a chamar o texto de Euler de "AI slop", e pede desculpas por isso.

A Quanta chamou o resultado da OpenAI de "por uma margem significativa, a prova matemática mais importante já alcançada por um modelo de inteligência artificial até hoje". As duas coisas são verdadeiras ao mesmo tempo: pode ser o maior feito da IA em matemática pura e, ainda assim, ter sido anunciado de um jeito que a comunidade considera inaceitável.

O Que Falta Para Alguém Ganhar o Prêmio

As regras do Clay Mathematics Institute são públicas e lentas de propósito. Uma solução precisa ser publicada em um veículo qualificado, ficar disponível por pelo menos dois anos e alcançar aceitação geral na comunidade matemática antes que o comitê sequer considere a premiação. Até o fechamento deste artigo, o instituto continua listando Navier-Stokes como problema aberto. Mesmo que a prova esteja correta, o calendário mínimo joga qualquer decisão para depois de 2028.

Há ainda três verificações independentes em andamento. A primeira é matemática: especialistas em equações diferenciais parciais precisam ler as 100 páginas e confirmar que a formalização em Lean corresponde ao problema de Fefferman. A segunda é de prioridade: as datas de Buckmaster e Alpöge para Euler (15 e 22 de agosto) são anteriores ao início do esforço da OpenAI (1º de setembro), e a própria OpenAI credita a dupla pelo resultado de Euler; a questão aberta é o salto de Euler para Navier-Stokes. A terceira é de conduta: a OpenAI ainda não deu uma resposta direta sobre se as sessões do Codex entraram em treinamento.

Para quem constrói software, as lições são menos glamourosas e mais úteis. Um verificador determinístico na frente de agentes probabilísticos é o que transforma força bruta em resultado confiável. As políticas de retenção de dados da ferramenta que você usa fazem parte da sua arquitetura, não do jurídico. E o crédito, em ciência como em open source, é o que sustenta a próxima contribuição; tratá-lo como detalhe de negociação sai caro para todo mundo.

Bora pra cima! 🦅

📚 Quer Acompanhar o Que Vem Por Aí?

Este artigo cobriu a resolução de Navier-Stokes anunciada pela OpenAI e a disputa de crédito com Buckmaster e Alpöge, mas o ecossistema muda toda semana e nem tudo vira artigo aqui.

No X eu compartilho o que estou testando, os bastidores dos projetos e as novidades que aparecem antes de virarem post.

Me Segue Lá

👉 Seguir @jeffbruchado no X

💡 Conteúdo diário sobre desenvolvimento, carreira e as ferramentas que eu realmente uso