Como usar Fugu Max e Fugu Ultra v2 numa stack que já fala com a API da OpenAI?

Se a sua stack já fala com a API da OpenAI, você não precisa migrar nada pra rodar Fugu

Sério, é isso mesmo: mesma biblioteca cliente, mesmo formato de requisição, mesmo parser de resposta

Fugu Max e Fugu Ultra v2 foram anunciados pela Sakana AI como as duas novas variantes da família Fugu, no anúncio Introducing Fugu Max and Fugu Ultra v2: Orchestrating the Pareto Frontier, com lançamento indicado para 11/09/2026

As duas estão no ar hoje pela API compatível com OpenAI da própria Sakana

Então o que este post entrega é bem concreto: trocar base URL, chave e model id na stack que você já mantém, e alternar entre as duas variantes mudando um parâmetro só

Bora ver na prática? 🙂

O que você precisa antes de começar:

A lista é curta, e cada item aqui é checável antes de você escrever a primeira linha

• SDK oficial da OpenAI já instalado (Python ou JavaScript), porque é exatamente ele que você vai usar
• Uma chave da Sakana, que entra no lugar da sua chave atual, no mesmo campo <code>api_key</code> do cliente
• Estar fora da UE e do EEE, já que o Fugu não é oferecido em estados-membros da União Europeia nem do EEE enquanto a Sakana trabalha na conformidade com o GDPR para a arquitetura de roteamento entre modelos, sem data anunciada pra liberação

E tem um ponto que muita gente descobre tarde: não existem pesos abertos do Fugu

É API hospedada e ponto, não dá pra subir isso na sua máquina nem num servidor seu

E a decisão de cobrança?

Essa também é pré-requisito de conta, não detalhe pra depois

Você escolhe entre pagar por token ou assinar um plano: Standard US$ 20/mês, Pro US$ 100/mês (10x o uso do Standard) e Max US$ 200/mês (20x o uso do Standard)

Se o seu caso é rota de produção com volume previsível, o por token costuma ser mais fácil de projetar

Se é uso de dia inteiro com agente rodando tarefa longa, o plano tende a fazer mais sentido, e eu volto nesse ponto lá no final, na parte em que eu mostro o medidor de uso subindo enquanto o agente trabalha

Passo a passo: apontar sua stack para o Fugu

1. Confirme o model id com <code>GET /v1/models</code> antes de fixar qualquer string no código

O endpoint <code>/v1/models</code> retorna os model ids disponíveis na sua conta, e é a forma de confirmar o identificador exato

<pre><code>curl https://api.sakana.ai/v1/models \ -H "Authorization: Bearer $SAKANA_API_KEY" </code></pre>

O erro comum deste passo: chumbar o slug do OpenRouter no código

Lá as variantes aparecem como <code>sakana/fugu-max</code> e <code>sakana/fugu-ultra-v2</code>, com aquele prefixo de provedor, enquanto a API da Sakana espera <code>fugu-max</code> e <code>fugu-ultra-v2</code>

É só o prefixo do provedor de diferença, e um 404 garantido, então confere na sua conta antes

2. Troque <code>base_url</code> e <code>api_key</code> no cliente OpenAI que você já tem

Em Python:

<pre><code>from openai import OpenAI

client = OpenAI( base_url="https://api.sakana.ai/v1", api_key=os.environ["SAKANA_API_KEY"], ) </code></pre>

Em JavaScript:

<pre><code>import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://api.sakana.ai/v1", apiKey: process.env.SAKANA_API_KEY, }); </code></pre>

O erro comum deste passo: esquecer o <code>/v1</code> no fim da base URL, ou deixar a chave antiga viva no ambiente

O segundo é traiçoeiro: se o <code>OPENAI_API_KEY</code> continua setado e o seu código lê ele em algum ponto, você acha que está batendo na Sakana e está batendo em outro lugar

Tome cuidado! Já me ferrei com variável de ambiente esquecida mais de uma vez

3. Faça a primeira requisição pela Responses API

A Sakana recomenda a Responses API pra requisições de geração em builds novos, por causa do comportamento melhor em uso de ferramentas, entrada multimodal e gestão de estado de raciocínio e function calls

<pre><code>resp = client.responses.create( model="fugu-max", input="explique o que mudou neste diff e liste riscos", )

print(resp.output_text) </code></pre>

Repara que o <code>output_text</code> continua ali, do jeitinho que o seu código já lê

O erro comum deste passo: cair no Chat Completions por inércia, só porque é o que você já tinha copiado no projeto antigo

Funciona, ninguém vai te bloquear, mas se o build é novo você está deixando a superfície recomendada na mesa à toa

4. Ligue streaming e tool calling sem tocar no parser

Streaming é <code>stream: true</code> no formato chat completions, igualzinho

<pre><code>stream = client.chat.completions.create( model="fugu-max", messages=[{"role": "user", "content": "resuma este changelog"}], stream=True, )

for chunk in stream: print(chunk.choices[0].delta.content or "", end="") </code></pre>

Tool calling é o mesmo array <code>tools</code> com definições de function que você já escreve:

<pre><code>tools = [{ "type": "function", "function": { "name": "get_build_status", "description": "retorna o status do build atual", "parameters": { "type": "object", "properties": {"repo": {"type": "string"}}, "required": ["repo"], }, }, }] </code></pre>

O erro comum deste passo: reescrever o leitor de eventos achando que o formato é proprietário

Não é

Os envelopes seguem os formatos Responses e Chat Completions da OpenAI, então <code>output_text</code>, <code>choices</code> e as estruturas de tool call continuam sendo lidas sem alteração nenhuma

5. Troque de variante mudando só o parâmetro <code>model</code>

Todas as variantes Fugu ficam atrás do mesmo endpoint compatível com OpenAI

Mesma biblioteca, mesma chave, mesmo formato de requisição, muda uma string:

<pre><code>MODEL = os.getenv("FUGU_MODEL", "fugu-max") # ou "fugu-ultra-v2"

resp = client.responses.create(model=MODEL, input=prompt) </code></pre>

O erro comum deste passo: espalhar o model id hardcoded em dez arquivos

Deixa num lugar só, variável de ambiente ou config, porque o valor dessa integração é justamente poder alternar sem deploy de código novo

E se a sua stack é do lado Anthropic, se liga nisso: o Fugu também expõe uma Messages API compatível com Anthropic, além de Chat Completions, Responses e Models, como está na documentação de get started da Sakana

Fugu Max ou Fugu Ultra v2: qual model id colocar na requisição?

Sobre preço, a Sakana posiciona o Fugu Max entre 40% e 60% abaixo de Sonnet 5, GPT 5.6 Terra e Kimi K3

Guarda o contexto disso: é afirmação da própria empresa no anúncio, não medição de terceiro

E os benchmarks do Ultra v2?

Os números divulgados são: Chartography 48,3 (contra 27,3 do Opus 5 e 29,5 do Claude Fable 5), DeepSWE 74,3 e melhor ou empatado em primeiro em 5 de 8 benchmarks

Agora a ressalva que precisa vir junto, senão o número engana: essas pontuações vêm da avaliação da própria Sakana

Nenhuma foi reproduzida de forma independente, e até hoje não existe página de nenhum modelo Fugu no Artificial Analysis

Ou seja: serve como sinal do que a empresa está mirando, não como veredito

A prova que vale pra você é rodar as duas na sua rota real e comparar, que é justamente o que a troca de um parâmetro barateia

Quando vale trocar o parâmetro <code>model</code> na sua stack:

Antes dos cenários, uma coisa importante pra decisão fazer sentido

Fugu não é um modelo de fundação único

É um orquestrador aprendido que roteia a tarefa por um pool de outros modelos, atrás de uma única API, atribuindo papéis de Thinker, Worker e Verifier a agentes especialistas e sintetizando a resposta final

Por isso a conversa aqui não é só "qual é mais forte", é qual pool e qual custo fazem sentido pra cada rota

• Rota de alto volume: classificação, extração, resumo em lote, aquelas chamadas que rodam milhares de vezes por dia. Aqui US$ 2 de entrada e US$ 6 de saída pesam muito mais na sua fatura do que o topo de uma tabela de benchmark, então <code>fugu-max</code> é o candidato natural
• Raciocínio pesado ou análise longa: revisão de arquitetura, investigação de bug chato, análise de documento grande. Como o custo do Ultra v2 mora principalmente na saída (US$ 30 por 1M), ele se justifica quando a resposta é densa e o acerto vale mais que a economia
• Contexto gigante: a janela de 1.000.000 de tokens está nas duas, mas no Ultra v2 tem um degrau de preço acima de 272K, que sobe pra US$ 10 de entrada e US$ 45 de saída. Se a sua rota vive perto desse limite, esse degrau precisa entrar na conta antes, não no fim do mês
• Quando o pool é o fator de decisão: o pool do Ultra v2 não inclui Claude Fable 5, Claude Fable 5.1 nem GPT-6 Astra. Se a sua tarefa hoje depende desses modelos, isso muda a escolha e não aparece em nenhum gráfico de benchmark
• Teste A/B na mesma base de código: essa é a melhor parte. Como é um parâmetro, dá pra dividir o tráfego de uma rota entre as duas variantes e medir custo e qualidade com dado seu, não com dado de anúncio

A lógica é a mesma de escolher o nível certo para cada tarefa em qualquer ferramenta de IA: não existe "o melhor", existe o adequado pro tipo de trabalho que aquela rota faz

Erros comuns ao plugar o Fugu e como resolver:

Requisição rejeitada por <code>reasoning.effort</code> inválido

Sintoma: a chamada volta com erro assim que você manda um valor de esforço de raciocínio

Causa: a família Fugu só aceita valores específicos, e qualquer outro é rejeitado. A documentação lista <code>high</code> e <code>xhigh</code> para <code>fugu</code>, <code>fugu-ultra-v1.0</code> e <code>fugu-cyber</code>, e <code>max</code> também para <code>fugu-ultra-v1.1</code>

Solução: use um dos valores listados para a variante que você está chamando, ou tire o parâmetro da requisição e valide o comportamento padrão primeiro

Como prevenir: não presuma que o valor que funciona numa variante vale em todas. Eu não encontrei documentação confirmando quais níveis <code>fugu-max</code> e <code>fugu-ultra-v2</code> aceitam, então aqui é caso de testar na sua conta antes de colocar em produção

Esse tipo de escolha de "quanto esforço aplicar" é a mesma cabeça de quem precisa decidir entre dois modos na mesma tarefa: mais raciocínio não é automaticamente melhor resultado, é mais token queimado

Model id não encontrado

Sintoma: erro de modelo inexistente, mesmo você tendo copiado o nome de uma página que fala do Fugu

Causa: quase sempre é slug de agregador entrando onde a API espera o id puro, tipo <code>sakana/fugu-max</code> em vez de <code>fugu-max</code>

Solução: rode <code>GET /v1/models</code> e use exatamente a string que voltou

Como prevenir: valide o id na inicialização da sua aplicação, comparando o valor configurado com a lista do endpoint, e nunca chumbe slug de terceiro no código

Acesso bloqueado por região

Sintoma: você não consegue usar o serviço e nenhum ajuste de código resolve

Causa: o Fugu não é oferecido em estados-membros da UE nem do EEE, enquanto a Sakana trabalha na conformidade com o GDPR para a arquitetura de roteamento entre modelos

Solução: não tem solução técnica do seu lado, e não foi anunciada data de liberação

Como prevenir: checar disponibilidade regional antes de colocar o Fugu num roadmap de produto, principalmente se a sua infra ou o seu público estão nessa área

Tentativa de rodar local pra economizar

Sintoma: você procura o repositório de pesos pra subir num servidor seu e não acha

Causa: não existem pesos abertos do Fugu, é apenas API hospedada

Solução: planejar o custo como serviço, por token ou por assinatura, e não como infraestrutura própria

Como prevenir: essa é decisão de arquitetura, não de última hora. Se o seu requisito é self-host obrigatório, o Fugu está fora antes mesmo da primeira linha de código

Como foi na prática: o que o uso real mostrou

Aqui eu saio da documentação e falo do que eu vi com a mão na massa

No vídeo eu assinei o plano pago e rodei o Fugu dentro do harness do Codex, apontando a chave de API pro serviço, sem trocar a ferramenta que eu já uso no dia a dia

E é esse o caminho mais simples mesmo: chave no harness que você já tem, orquestrador rodando nos projetos existentes

Os slash commands do Codex, tipo compactar e limpar contexto, continuaram funcionando normalmente com o orquestrador selecionado, o que pra mim foi sinal de que a integração preservou as funções do harness

O primeiro teste foi uma landing page de produto, em pasta própria, arquivos separados, tema escuro, barra de progresso de leitura e rolagem suave entre as seções

E se liga no número: depois do primeiro prompt, o medidor já marcava 2% do limite semanal

Com a landing page pronta, 18%

Depois eu compactei e reiniciei a sessão de propósito, pra não carregar contexto velho, e parti pro segundo teste: um sistema web completo de gestão de tarefas estilo kanban, com cadastro e login, CRUD de quadros, colunas, cards com etiqueta, drag and drop, busca e persistência em banco local

Impus restrição de arquitetura de propósito (backend e frontend separados, nada de arquivo único, pastas organizadas) já sabendo que isso ia aumentar o gasto de token

No início desse projeto o medidor já estava em 23%

E aos 12 minutos o agente travou na etapa de instalação de dependências, só seguindo depois que eu aprovei manualmente

O comportamento em si foi bem responsivo: ele inspecionou a pasta, montou a estrutura e separou backend e frontend como pedido

Mas teve muita ida e volta de raciocínio e uma checagem final de arquivos que eu achei desnecessária pra uma página web, e boa parte da queima de token foi por aí

Amarrando com o tema deste post: o custo real da orquestração não é só o preço por 1M de token na tabela

É quanto de limite uma tarefa longa come, e é exatamente isso que decide se pra você faz mais sentido pagar por token na API ou assinar um plano

Meu incômodo maior continua sendo a caixa preta: você manda a solicitação, recebe código, e não sabe qual modelo rodou por trás

Por isso eu insisto tanto no teste A/B na sua rota: é o único jeito de você formar opinião com dado seu

No vídeo acima você vê os dois projetos rodando do zero, o medidor de uso subindo a cada etapa e o momento em que o agente trava na instalação de dependências

Conclusão

Adotar Fugu Max e Fugu Ultra v2 numa stack que já fala com a API da OpenAI é troca de três coisas: base URL, chave e model id

Nada de reescrever parser, nada de migração, nada de SDK novo

E alternar entre as duas variantes é um parâmetro, mesma biblioteca e mesmo formato de requisição

Próximo passo concreto, na ordem:

1. Rodar <code>GET /v1/models</code> na sua conta e anotar a string exata do id
2. Fazer a primeira chamada pela Responses API com <code>fugu-max</code>
3. Repetir a mesma chamada com <code>fugu-ultra-v2</code> na mesma rota e comparar custo e resultado antes de decidir qualquer coisa

Pra quem quiser ir mais fundo em como essa orquestração funciona por dentro, tem o Sakana Fugu Technical Report no arXiv (2606.21228)

E repetindo o que importa: os benchmarks divulgados são autoavaliação da Sakana, sem reprodução independente até agora

Trate como ponto de partida pro seu teste, não como resposta pronta

Até o próximo post! 😀