Sakana Fugu Ultra: Eu Vi Ele Vencer o Stockfish

Sakana Fugu Ultra: Eu Vi Ele Vencer o Stockfish

O detalhe que me parou não foi um benchmark. Foi uma partida de xadrez jogada sem tabuleiro.

Sem imagem das peças. Sem grade de coordenadas. Apenas um modelo mantendo todo o estado do jogo na cabeça, lance após lance, contra um motor Stockfish classificado em torno de 2.100 ELO — o tipo de força que vence quase qualquer jogador de clube humano que você encontrará. E o Sakana Fugu Ultra não apenas sobreviveu. Ele venceu quatro partidas consecutivas, todas terminando em xeque-mate, contra três modelos de fronteira e o motor.

Esse foi o momento em que percebi que estava pensando em tudo isso da maneira errada. Entrei no vídeo sobre o Sakana Fugu Ultra esperando mais um reel de hype "novo modelo vence o GPT", do tipo que aprendi a descartar à primeira vista. O que recebi em vez disso foi um argumento silenciosamente radical: talvez o próximo salto em capacidade de IA não venha de um cérebro maior. Talvez venha de um comitê mais inteligente.

Quero ser direto sobre o que esta publicação é, porque a honestidade importa mais que o clique. Eu não executei a API do Fugu pessoalmente — o acesso é restrito, e no lançamento está bloqueado na UE/EEE enquanto a Sakana trabalha no RGPD. Então não vou fingir que implantei isso em um projeto de cliente na terça-feira passada. O que eu posso fazer é algo mais útil: pegar os resultados de testes que existem, verificá-los cruzando com a pesquisa publicada da Sakana, e dizer o que eles realmente significam para como você escolhe ferramentas em 2026. Os números abaixo vêm dos testes-fonte e dos materiais próprios da Sakana. O julgamento é meu.

Deixe-me mostrar por que "é melhor que o GPT-5.5?" acaba sendo a pergunta completamente errada.

O que é o Sakana Fugu Ultra e por que não é um modelo normal?

Sakana Fugu Ultra não é um modelo fundacional — é um sistema de orquestração multi-agente que decompõe uma tarefa, roteia as subtarefas para diferentes LLMs especializados, e então critica, verifica e sintetiza suas saídas em uma única resposta. Quando você o chama através de seu único endpoint de API, você não está falando com um conjunto de pesos como faz com o Opus 4.8 ou GPT-5.5. Você está falando com um maestro que sabe quais músicos chamar para cada passagem.

Sakana AI é um laboratório de pesquisa em Tóquio, e o Fugu foi lançado em 22 de junho de 2026. O rótulo de "modelo" não faz justiça. Aqui está a arquitetura em termos simples: Fugu pega seu prompt, divide em pedaços e atribui papéis através de um pool intercambiável de modelos de fronteira — pense em Pensador, Trabalhador, Verificador. Um modelo elabora um plano. Outro executa uma parte dele. Um terceiro verifica o trabalho. O Fugu costura os resultados e entrega a saída finalizada.

A palavra "intercambiável" está fazendo trabalho pesado aí. Porque o Fugu roteia para modelos em vez de ser um, o pool pode crescer à medida que novos modelos de fronteira aparecem — sem retreinamento. Essa é uma aposta genuinamente diferente sobre de onde vem o valor da IA. A maioria dos laboratórios está correndo para construir o cérebro único mais inteligente. A Sakana aposta que coordenar os cérebros que já temos é o caminho mais barato e rápido para mais vitórias.

Aqui está a parte que a maioria da cobertura erra, e muda tudo: a orquestração do Fugu é aprendida, não codificada. Isso não é um roteador construído com lógica if/else e um comparador de palavras-chave. De acordo com a pesquisa da Sakana, o Fugu é ele mesmo um modelo de linguagem treinado cujo trabalho é chamar outros LLMs — e aprendeu como coordená-los a partir de dois artigos do ICLR 2026: Trinity (um coordenador evoluído que atribui os papéis de Pensador/Trabalhador/Verificador) e The Conductor (treinado com aprendizado por reforço para descobrir estratégias de coordenação em linguagem natural). O sistema aprendeu o que dizer a cada modelo para fazer um pool diverso superar qualquer trabalhador individual.

E há um detalhe surpreendente enterrado aí. O Fugu pode chamar a si mesmo recursivamente — ler sua própria saída anterior, decidir se sua primeira tentativa de coordenação ficou aquém, e iniciar um fluxo de trabalho corretivo. A profundidade dessa recursão se torna um eixo computacional ajustável em tempo de inferência. Você pode gastar mais pensamento indo mais fundo, sem retreinar nada. Isso é um novo tipo de escalamento em tempo de teste, e é o tipo de ideia que é óbvia em retrospecto e que quase ninguém entregou primeiro.

Então, quando você vir o Fugu "vencer" um modelo de fronteira em um benchmark, segure esse resultado contra a luz. É claro que um sistema que decompõe, delega e verifica se sai bem em tarefas que recompensam a resolução cuidadosa de problemas. É literalmente para isso que foi construído. A pergunta interessante não é se ele vence — é onde ele vence, e quanto custa para você chegar lá.

Essa questão de custo é onde a história fica desconfortável.

O teste do trader desk: para onde o dinheiro realmente vai

Quero começar com o teste menos dramático, porque é o mais honesto. O briefing: construir um "trader desk ao vivo" — um front-end mais back-end, o tipo de aplicativo multicomponente que pessoas reais realmente constroem. Quatro sistemas receberam o mesmo prompt. Aqui está o que usaram, como reportado na fonte:

Leia essa tabela devagar, porque há duas histórias nela.

A primeira história é a que a Sakana quer que você veja: o Fugu produziu a UI mais bonita e completa. Se "faça impressionante de primeira" é o trabalho, o Fugu entregou. A orquestração se pagou em polimento — múltiplos modelos verificando uns aos outros tendem a captar as lacunas que uma única passagem deixa para trás.

A segunda história é a que importa para seu orçamento. O Fugu custou $0,51 — cerca de 17 vezes o que o Chinchilla 5.2 cobrou por uma versão funcional da mesma coisa. Também queimou a maior quantidade de tokens. Isso não é um bug. É a arquitetura. Toda vez que o Fugu decompõe uma tarefa, roteia e verifica o resultado, ele faz mais chamadas de modelo do que um modelo individual faria. Coordenação tem overhead, e você paga por isso em tokens, reais e latência.

Aqui é onde eu chego, e não é onde o marketing me quer: para uma construção direta, esse prêmio é difícil de justificar. O Chinchilla 5.2 te deu um trader desk funcional por três centavos. Se você precisa bonito, o Opus 4.8 dividiu a diferença em $0,31 com um resultado limpo. Os 64 centavos extras do Fugu sobre o Chinchilla compram polimento — e em muitas ferramentas internas, ninguém avalia o polimento.

Mas "muitas ferramentas internas" não é todo trabalho. O teste do trader desk recompensa eficiência, então as ferramentas eficientes parecem espertas. Mude a tarefa para uma que recompense coordenação, e o quadro vira drasticamente.

O teste do Crossy Road: quando mais rápido e mais barato produz pior resultado

Este é o teste que reenquadrou tudo para mim, e não tem nada a ver com qual sistema é "mais inteligente".

A tarefa: construir um jogo 3D estilo Crossy Road. Mesmo briefing, cara a cara — Fugu Ultra contra Opus 4.8. Aqui estão os números reportados, e eu os apresento exatamente como a fonte os reportou, não como números que eu mesmo verifiquei:

O Fugu foi aproximadamente 3,5 vezes mais rápido, usou cerca de 10 vezes menos tokens e custou aproximadamente 5 vezes menos. Pare e absorva isso, porque contradiz o resultado do trader desk que você acabou de ler. Aqui, o sistema orquestrado foi o frugal.

E ainda assim produziu o jogo pior. O clone de Crossy Road do Fugu tinha controles de direção invertidos — aperte direita, vá para a esquerda. A câmera lutava contra o jogador. Não havia som. O jogo estava incompleto. O Opus 4.8 gastou cinco vezes o dinheiro e quase quatro vezes o tempo real, e devolveu algo mais polido e funcional — embora ainda ligeiramente com bugs.

Então quem ganhou? Essa é a pergunta errada, e esse é exatamente o ponto. Se você está prototipando cinquenta conceitos de jogos para encontrar o que vale a pena construir, o perfil do Fugu é obviamente correto — você quer velocidade e baixo custo, e vai consertar a câmera na ideia que sobreviver. Se você está entregando o jogo pelo qual jogadores realmente vão pagar, o polimento do Opus 4.8 vale cada dólar extra.

Observe o que aconteceu em dois testes. No trader desk, o Fugu foi a opção cara. No Crossy Road, o Fugu foi a opção barata. O mesmo sistema. A variável não foi o Fugu — foi a tarefa. O overhead de orquestração é um imposto fixo que rende enormemente em alguns trabalhos e te sangra em outros, e você não pode saber qual sem combinar a tarefa com a arquitetura.

Essa é a habilidade que ninguém está ensinando ainda: ler uma tarefa e prever qual forma de sistema se encaixa. Deixe-me dar a regra geral que eu usaria.

Você deveria usar o Fugu Ultra ou simplesmente escolher um modelo de fronteira?

Use o Fugu Ultra quando a tarefa for multicomponente, de alto detalhe e se beneficiar de verificação — construções de UI, simulações, qualquer coisa onde a verificação cruzada capture erros que uma única passagem não detecta. Recorra a um modelo de fronteira individual como Opus 4.8 ou GPT-5.5 quando precisar de velocidade previsível, baixo custo e um ciclo de feedback ajustado. O fator decisivo não é a capacidade. É se a decomposição-e-verificação recupera seu overhead neste trabalho específico.

Aqui está a decisão que eu realmente executaria, em ordem:

1. Isso é um artefato impressionante de uma vez ou um ciclo de iteração ajustado? Polimento de uma vez favorece o ciclo de verificar-e-sintetizar do Fugu. Iteração rápida favorece um modelo individual — você não quer latência de orquestração entre cada tecla de feedback.
2. Quão longo prazo é a tarefa? Esta é importante. Os resultados reportados mostram que o Fugu às vezes fica para trás em trabalho amplo e de longo prazo — coisas como Sweep Bench Pro — precisamente porque o overhead de orquestração e os pontos de falha de coordenação se acumulam ao longo de muitos passos. Mais peças móveis significa mais lugares para quebrar.
3. Qual é seu teto de custo e seu piso de qualidade? Se você tem um orçamento rígido e um padrão de qualidade indulgente, um modelo eficiente individual gana quase sempre. Se polimento não é negociável e o orçamento é flexível, as chamadas extras do Fugu ganham seu custo.
4. Precisa rodar na UE? No lançamento, o Fugu não está disponível na UE/EEE enquanto a Sakana trabalha no RGPD. Se seu stack ou usuários vivem lá, a decisão está tomada por você.

Em benchmarks puros, a fonte reporta que o Fugu pontua bem em engenharia, raciocínio científico, codificação e tarefas agênticas — e frequentemente supera o Mythos 5 em benchmarks específicos como Live Code Bench e BBQ Evil, exatamente o tipo que recompensa decomposição cuidadosa e verificação. Mas fica aquém de modelos de fronteira verdadeiros como o Fable 5 em tarefas do mundo real mais bagunçadas. As vitórias em benchmarks são reais e são em parte um artefato daquilo para o qual a orquestração foi construída. Ambas as coisas são verdadeiras.

Mais uma ressalva honesta que não vou enterrar: a maioria das afirmações de benchmark das manchetes são números próprios da Sakana. Benchmarks auto-reportados da empresa que vende o produto são marketing até que avaliadores independentes os reproduzam. Não estou dizendo que estão errados — estou dizendo que o ônus da prova está com a Sakana, e neste momento está apenas parcialmente cumprido. Os resultados de testes de terceiros acima (trader desk, Crossy Road) são mais confiáveis precisamente porque não foram conduzidos pela Sakana.

Se toda a direção multi-modelo e de ensembles te interessa, tracei a versão inicial desse padrão na minha análise de ensembles de IA de código aberto, e cobri o lançamento do Fugu em contexto junto com os outros lançamentos de junho no meu resumo de modelos de IA para junho de 2026. Esta publicação é o mergulho profundo no Fugu sozinho; aquele resumo é o mapa mais amplo.

Agora — os testes onde o Fugu genuinamente me impressionou, e onde a arquitetura de orquestração para de ser um compromisso e começa a ser uma vantagem.

Onde a orquestração realmente brilha: simulações, terreno e um tabuleiro que não pode ver

Três resultados me levaram de cético a "ok, isso é real."

A simulação do buraco negro. O briefing era uma simulação surrealista de buraco negro — codinome "Singularity". O Fugu produziu uma visualização detalhada e bem renderizada que superou o GLM MiniMax e o Chinchilla 2.7 Code em precisão visual. Este é exatamente o tipo de tarefa onde a orquestração deveria vencer: renderizar corretamente uma cena com nuances físicas envolve vários subproblemas — a geometria, a iluminação, a física de distorção, o estilo surrealista — e um sistema que pode rotear cada um para um modelo capaz e verificar o composto tem uma vantagem estrutural sobre um modelo individual tentando manter tudo de uma vez.

O simulador de voo. Mesma história, domínio diferente. O Fugu gerou um simulador de voo de terreno infinito semi-preciso que superou o GLM 5.2 e o MiniMax, ambos com resultados limitados. "Terreno infinito" é um problema de decomposição disfarçado — geração de terreno, a física de voo, a câmera, o loop de renderização — e decomposição é o território do Fugu.

E então o xadrez. Eu continuo voltando a este porque é a demonstração mais limpa do que "manter estado através de coordenação" realmente te proporciona. Xadrez às cegas, de uma vez, sem tabuleiro visual — o sistema tem que rastrear toda a posição na memória de trabalho ao longo de toda a partida. O Fugu venceu quatro partidas consecutivas contra três modelos de fronteira e um motor Stockfish em torno de 2.100 ELO, terminando cada partida em xeque-mate. Manteve o estado do jogo e a precisão de lances melhor que oponentes que, no papel, são mais capazes.

Por que isso acontece? Porque um verificador no loop captura o erro antes de ser cometido. Um modelo individual jogando xadrez às cegas tem uma tentativa para rastrear o tabuleiro corretamente a cada lance. Um sistema orquestrado pode fazer um componente propor um lance e outro verificar a posição resultante contra o histórico de lances. Isso não é mágica — é o mesmo loop de decompor-e-verificar, aplicado a um problema onde um único deslize perde a partida. Toda a razão de existir da arquitetura é capturar o erro que o solista cometeria.

Se você leu até aqui, aqui está a mudança que quero que leve consigo: por anos perguntamos "qual modelo é o mais inteligente?" A pergunta mais útil de 2026 é "qual forma de sistema se encaixa neste trabalho?" E "um orquestrador que roteia entre muitos modelos" é agora uma resposta real e em produção para essa pergunta — não uma curiosidade de pesquisa.

O que errei sobre de onde vem o próximo salto

Hora de falar direto, porque uma análise de ferramenta que só lista recursos é uma ficha técnica, e isso você consegue em qualquer lugar.

Primeiro, errei sobre a forma do progresso. Assumi que o próximo salto de capacidade viria de um modelo individual maior — mais parâmetros, mais treinamento, um cérebro mais gordo. Os resultados do Fugu sugerem que uma parcela significativa do progresso a curto prazo virá da coordenação em vez disso: extrair mais dos modelos que já temos roteando inteligentemente entre eles e verificando a saída. Essa é uma forma de progresso mais humilde, menos glamorosa. Não gera uma manchete chamativa de "novo modelo". Acho que foi subestimada exatamente por essa razão.

Segundo, o eixo do custo é agora tão importante quanto o eixo da capacidade, e a maioria da cobertura ainda o ignora. Todo mundo faz benchmark de inteligência. Quase ninguém faz benchmark de reais-por-tarefa-completada. As tabelas do trader desk e Crossy Road são a ilustração mais clara que vi de que "melhor" é agora uma palavra dependente do orçamento. Quando assessoro equipes, a primeira pergunta não é mais "qual modelo é o mais inteligente" — é "qual é sua tolerância para custo versus polimento neste trabalho." Na maioria dos dias, pego o resultado mais barato e conserto a câmera eu mesmo.

Terceiro — e esta é a limitação com a qual a Sakana não vai liderar — o overhead de orquestração é um imposto real e recorrente. Mais chamadas de modelo significam maior latência, maior custo e mais pontos de falha. Cada salto entre modelos é um lugar onde o fluxo de trabalho pode perder contexto ou rotear errado. Em tarefas de longo prazo, esses pontos de falha se acumulam, o que é exatamente por que o Fugu fica para trás nos benchmarks mais amplos. Um orquestrador é tão confiável quanto sua transferência mais fraca, e tem mais transferências que um modelo individual. Isso não é uma falha para corrigir — é o custo inerente do design.

Se o padrão de orquestração te deixou curioso para rodar um você mesmo, testei alguns desses sistemas — veja minha experiência prática com o orquestrador de agentes OpenAI Symphony, que aborda o mesmo problema de coordenar-muitos-modelos pela perspectiva do harness de código. E se você está considerando conectar uma camada de orquestração multi-agente em seu próprio stack — descobrir onde ela ganha seu overhead versus onde um modelo individual é a escolha mais sensata — esse é exatamente o tipo de decisão de arquitetura que assumo através do meu Fiverr. A resposta honesta geralmente é "use orquestração para os 20% das tarefas que genuinamente precisam, e um modelo individual rápido para o resto," e acertar essa divisão é a maior parte do valor.

Então, onde o Fugu realmente se encaixa? Deixe-me tornar isso concreto.

O que esperar se você adotar o Fugu Ultra hoje

Não vou inventar precisão que não tenho. Mas os testes reportados, lidos contra a arquitetura, apontam para uma forma consistente ao redor da qual você pode planejar.

Espere que o Fugu vença em artefatos multicomponente, de alto detalhe e de uma vez — a construção de UI polida, a simulação renderizada, a geração em múltiplas partes onde a verificação captura o que uma única passagem não detecta. A UI do trader desk, a simulação do buraco negro, o simulador de voo, o xadrez às cegas — todos compartilham esse DNA: vários subproblemas que se beneficiam de serem divididos, resolvidos e verificados.

Espere que o Fugu fique para trás em trabalho de longo prazo, aberto ou sensível a custo — tarefas agênticas amplas onde o overhead se acumula, e qualquer trabalho onde um modelo individual mais barato te leva 90% do caminho por uma fração do gasto. O trader desk de três centavos do Chinchilla 5.2 é a história de alerta: se você não precisa do polimento, está pagando um prêmio considerável por ele.

Espere pagar mais e esperar mais do que com GPT-5.5 ou Opus 4.8 em tarefas equivalentes, como regra. Esse é o custo estrutural da coordenação, e não vai desaparecer completamente — embora a ideia de profundidade recursiva da Sakana sugira que eles pelo menos têm um botão para trocar computação por qualidade deliberadamente em vez de às cegas.

E espere que isso melhore. O Fugu foi lançado em 22 de junho de 2026; é cedo. O pool é intercambiável, então herda cada novo modelo de fronteira gratuitamente. A coordenação é aprendida, então treinamento contínuo pode afiá-la. A prova de conceito já é convincente. A questão é se a Sakana pode fechar a lacuna de overhead rápido o suficiente para tornar a orquestração o padrão em vez da escolha especialista.

Por enquanto, minha recomendação é sem glamour e, creio, correta: Fugu Ultra é uma ferramenta especialista, não um veículo do dia a dia. Para trabalho de aplicação geral, GPT-5.5 e Opus 4.8 atualmente te dão um melhor equilíbrio custo-velocidade-qualidade. Mantenha o Fugu no seu kit para os trabalhos específicos de alto detalhe e multicomponente onde decompor-e-verificar ganha seu custo — e observe a tendência de overhead, porque se ela cair, todo o cálculo muda.

Volte mais uma vez àquela partida de xadrez às cegas. Um sistema que não podia ver o tabuleiro venceu mesmo assim — não porque era o jogador mais inteligente na mesa, mas porque tinha um companheiro de equipe verificando seu trabalho antes de cada lance. Essa é a verdadeira lição do Fugu Ultra, e é maior que um produto. A próxima era da IA talvez não seja vencida pelo modelo mais inteligente. Talvez seja vencida pela equipe mais bem coordenada de modelos comuns.

Então a pergunta que eu te deixaria não é "o Fugu é melhor que o GPT-5.5?" É esta: dos trabalhos na sua mesa esta semana, quais você está resolvendo com um solista que na verdade precisam de um comitê?

Perguntas Frequentes

O Sakana Fugu Ultra é um modelo fundacional ou um orquestrador?

O Fugu Ultra é um orquestrador, não um modelo fundacional. Ele decompõe uma tarefa, roteia subtarefas para um pool intercambiável de LLMs de fronteira, e então verifica e sintetiza suas saídas através de uma única API. Diferente do Opus 4.8 ou GPT-5.5, não gera respostas a partir de seus próprios pesos — coordena outros modelos. Veja a análise da arquitetura acima para o quadro completo.

O Fugu Ultra é mais barato que o Opus 4.8 ou GPT-5.5?

Depende inteiramente da tarefa. Em uma construção de Crossy Road, o Fugu custou segundo reportes aproximadamente 5 vezes menos que o Opus 4.8; em uma construção de trader desk, foi o mais caro de quatro sistemas a $0,51. O overhead de orquestração é um imposto fixo que rende em alguns trabalhos e te sangra em outros. O framework de decisão acima explica como prever qual.

Em quais benchmarks o Fugu Ultra se sai bem?

O Fugu pontua bem segundo reportes em engenharia, raciocínio científico, codificação e benchmarks agênticos, e frequentemente supera o Mythos 5 em tarefas como Live Code Bench e BBQ Evil que recompensam decomposição e verificação. Fica para trás em benchmarks de longo prazo como Sweep Bench Pro, onde o overhead de orquestração se acumula.

Onde o Sakana Fugu Ultra está disponível?

O Fugu Ultra é acessível através de um provedor de API e foi lançado em 22 de junho de 2026. No lançamento não está disponível na UE/EEE enquanto a Sakana AI trabalha na conformidade com o RGPD. Se seus usuários ou stack vivem na Europa, essa restrição pode decidir a questão por você.

O Fugu Ultra realmente venceu o Stockfish no xadrez às cegas?

De acordo com os testes-fonte, sim — o Fugu venceu quatro partidas consecutivas às cegas (sem tabuleiro visual) contra três modelos de fronteira e um motor Stockfish classificado em torno de 2.100 ELO, terminando cada partida em xeque-mate. A razão provável é seu design de verificar-no-loop, que captura o erro de rastreamento de posição que um modelo individual cometeria.

Vamos Trabalhar Juntos

Procurando construir sistemas de IA, automatizar fluxos de trabalho ou escalar sua infraestrutura tecnológica? Adoraria ajudar.

• Fiverr (construções personalizadas e integrações): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e branding): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io