Saída de 131.072 tokens do Ox Alpha: quando o limite de resposta longa faz diferença?

Fala aí, beleza? Sabe aquela cena de a IA estar cuspindo o arquivo inteiro, tudo lindo, e do nada a resposta parar no meio de uma função?

Pois é…

Quase todo mundo culpa o contexto nessa hora, mas o culpado costuma ser outro: o teto de SAÍDA, ou seja, o quanto o modelo consegue escrever numa resposta só

O Ox Alpha declara até 131.072 tokens de saída por resposta, e é justamente esse número que a gente vai destrinchar aqui: onde ele muda o teu fluxo de trabalho de verdade e onde ele não resolve nada

Contexto de entrada x limite de saída: são coisas diferentes

Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

• 474 aulas
• 20 projetos
• 39h 27min

Conhecer formação

Essa confusão é a mãe de quase todo o problema, então bora separar

A janela de contexto é o quanto o modelo consegue LER numa conversa. Aqui são 1.048.576 tokens, e eu já falei em detalhe sobre o que cabe numa janela de 1 milhão quando o assunto é entrada

O limite de saída é outra coisa: é o quanto ele consegue ESCREVER de uma vez. E aí o número cai pra 131.072 tokens

É tipo prova de vestibular: tu pode ter lido a biblioteca inteira, mas a folha de resposta tem um número fixo de linhas 😀

E quem controla isso na prática?

O max_tokens

Na OpenRouter, esse parâmetro define o teto de tokens que o modelo pode gerar na resposta. E tem uma regra que pega muita gente de surpresa: o valor máximo aceito é o tamanho do contexto MENOS o tamanho do prompt

Ou seja, prompt gordo come orçamento de saída, mesmo que tu tenha 1M de janela pra brincar

E o que é o Ox Alpha, afinal?

É um modelo stealth

Ele ficou disponível em 20 de agosto de 2026 sob o nome de provedor stealth, com o ID stealth/ox-alpha. Quem desenvolve e opera é um provedor terceiro que optou por permanecer anônimo durante o preview

A OpenRouter apenas roteia as requisições: ela não é dona, não é desenvolvedora e não é a provedora do modelo. Tu pode conferir isso direto na página do modelo na OpenRouter

Guarda essa informação, ela volta lá no veredito 😉

Quando o limite de saída é o gargalo real

Agora a parte prática: em que momento 131.072 tokens de saída mudam o resultado?

• Arquivo completo em uma tacada: em vez de pedir "me dá a parte 1", "agora a parte 2", o modelo devolve o arquivo inteiro sem quebra artificial
• Refatoração extensa: quando a tarefa exige devolver o bloco inteiro reescrito, não um diff de três linhas
• Relatório ou documentação longa: aquele documento que precisa sair coerente do começo ao fim, numa resposta só
• Migração de trechos grandes: converter um arquivo inteiro de uma sintaxe pra outra sem picotar
• Saída estruturada volumosa: o modelo suporta response_format e chamada de função com tools e tool_choice, então dá pra pedir JSON grande sem ficar rezando pra caber

E ele aceita texto, imagem e vídeo na entrada, devolvendo texto

O contraponto honesto: quando isso não importa nada

Se liga, porque aqui muita gente troca de modelo à toa

Se o teu caso é ler uma base gigante e responder "onde está o bug", o gargalo é ENTRADA, não saída

Se é chat, pergunta curta, explicação de conceito, revisão pontual? O teto de saída nunca vai ser alcançado. Trocar de modelo por causa disso é resolver um problema que tu não tem

Regra simples: se tuas respostas nunca são cortadas, esse número não é pra ti

131.072 tokens de saída x o que outros modelos entregam

Bora colocar lado a lado só o que está declarado em documentação, sem achismo

A leitura da tabela é bem direta

Na resposta síncrona, aquela que tu espera na tela, os números são vizinhos: 131.072 do stealth contra os 128k documentados da linha Claude. Já detalhei o limite de saída do Fable 5 em outro post, se quiser o recorte só dele

O salto grande mesmo está na rota de lote da Anthropic, que chega a 300k com o header beta

Só que essa rota é ASSÍNCRONA, ou seja, é outro fluxo de trabalho: tu manda e busca depois, não serve pra quem quer o arquivo aparecendo na tela agora

Comparar 131.072 com 300k sem olhar isso é comparar coisa que não compete entre si

Como pedir uma resposta longa sem ser cortado

Passo a passo enxuto, só com o que dá pra afirmar com segurança

1. Chame o modelo pela API compatível com OpenAI da OpenRouter, usando o campo model com o valor stealth/ox-alpha

{
  "model": "stealth/ox-alpha",
  "max_tokens": 131072,
  "messages": [
    { "role": "user", "content": "reescreva o arquivo inteiro, sem omitir trechos" }
  ]
}

2. Defina o max_tokens como o teto de geração que tu quer de verdade, lembrando que o máximo aceito é o tamanho do contexto menos o tamanho do prompt

O erro comum deste passo: mandar um prompt gigantesco (colar a base inteira, o histórico todo) e depois estranhar que a saída não alcança o teto. O prompt comeu o orçamento, simples assim

3. Se o teu fluxo usa reasoning, deixe o max_tokens estritamente maior que o orçamento de reasoning

O erro comum deste passo: colocar max_tokens igual ao budget de reasoning. Aí sobra ZERO espaço pra resposta final, e o modelo pensa lindamente pra te entregar nada 😛

4. Confira o finish_reason da resposta antes de dar a tarefa por concluída

Esse último merece seção própria, porque é onde o bicho pega

Resposta cortada no meio: como identificar e o que fazer

O sintoma tu já conhece: a geração para no meio da função, o relatório morre no meio de um tópico, o JSON vem sem fechar chave

E o pior é que o texto parece plausível até o ponto do corte, então dá pra passar batido

O diagnóstico

A OpenRouter normaliza o finish_reason em cinco valores: tool_calls, stop, length, content_filter e error

finish_reason: "stop"    -> o modelo terminou sozinho, tá tudo certo
finish_reason: "length"  -> cortou porque bateu no max_tokens

O valor bruto do provedor, sem normalização, fica no native_finish_reason. Útil quando tu quer saber exatamente o que veio do outro lado

A solução

Com length na mão, tu tem três caminhos:

• Elevar o max_tokens, respeitando o limite (contexto menos prompt)
• Reduzir o prompt pra liberar orçamento de saída
• Fatiar a tarefa em pedaços que caibam com folga

Como prevenir

Checar o finish_reason em TODA resposta longa, sempre

Confiar no texto recebido é o caminho mais rápido pra commitar um arquivo pela metade… já vi isso acontecer com gente boa

Vale apostar o fluxo no Ox Alpha por causa da saída longa?

Veredito honesto, sem inventar teste que eu não fiz

O teto de 131.072 tokens de saída é competitivo com os limites síncronos documentados da concorrência, isso é fato. Pra quem vive batendo no corte de resposta, é um número que resolve

Porém (e é um porém grande) o modelo é stealth

O provedor não se identificou durante o preview, e o preço listado na OpenRouter é de PREVIEW: US$ 0 por 1M de tokens de entrada e US$ 0 por 1M de tokens de saída, com aviso explícito de que isso pode mudar sem aviso prévio

Minha postura seria essa: usar pra experimentar fluxos de saída longa, medir, aprender o formato de prompt que funciona

Agora amarrar produção a um modelo sem dono declarado e sem preço estável? Aí não. Se o provedor sumir ou o preço aparecer amanhã, teu fluxo vai junto

Conclusão

Recapitulando o que importa:

Contexto e saída são gargalos DIFERENTES. O modelo tem 1.048.576 tokens de janela e 131.072 tokens de saída, e trocar de modelo achando que um número resolve o problema do outro é desperdício de tempo

O max_tokens é quem manda no teto de geração, e o máximo aceito é contexto menos prompt

O finish_reason com valor length é a prova objetiva de que tu foi cortado, não é sensação

Próximo passo prático: pega uma tarefa real de geração longa que tu já resolve fatiada hoje, roda de uma vez só checando o finish_reason, e compara os dois resultados

Se o resultado inteiro sair mais coerente que os pedaços colados, tu achou teu caso de uso. Se sair igual, economizou uma migração 🙂

até o próximo post!