Claude Fable 5: quanto ele consegue escrever em uma resposta só (o limite de 128 mil tokens de saída)

1 milhão de tokens de contexto e 128 mil de saída: os dois números do Claude Fable 5 que todo mundo confunde

Essa confusão é a mãe de quase todo "a resposta parou no meio do nada" que aparece por aí

São dois números diferentes: a janela de contexto (1 milhão de tokens, tudo que cabe na conversa, incluindo o que o próprio modelo escreve) e o teto de saída por requisição (128 mil tokens, o quanto ele consegue escrever numa tacada só)

O primeiro número é o que todo mundo comemora no anúncio

O segundo é o que corta seu texto no meio da frase 😅

Bora separar os dois de vez?

Janela de contexto x limite de saída: a diferença que confunde todo mundo

A analogia mais direta que eu consigo: a janela de contexto é a mesa de trabalho, e tudo vai ocupando espaço nela (o que entra E o que o modelo escreve), enquanto o limite de saída é o quanto ele consegue redigir antes de ter que levantar da cadeira

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Cabe MUITA coisa na mesa

Mas a redação de uma vez só tem teto

Repara no preço: saída custa cinco vezes a entrada

Então pedir uma resposta gigante "só pra ver no que dá" é diferente de jogar um monte de arquivo no contexto

E tem uma boa notícia no meio disso: nos modelos com janela de 1 milhão, 1M é o PADRÃO

Não precisa de beta header, não tem sobretaxa de contexto longo, as requisições longas são cobradas pelo preço padrão

Comparando as janelas por modelo:

Se você acompanhou a janela de 1 milhão de tokens na API quando isso ainda era novidade e exigia cerimônia, agora virou o comportamento normal da linha

O identificador na API, pra registrar: claude-fable-5

O que cabe (e o que não cabe) em 128 mil tokens de saída

Aqui vem a pergunta óbvia: 128 mil tokens dá quantas páginas?

E aqui vem a resposta honesta: depende, e a documentação não te dá essa conversão pronta

O que a documentação da Anthropic dá é uma razão de referência: um token corresponde a aproximadamente 3,5 caracteres em inglês, variando conforme o idioma

Ou seja: em português a conta MUDA

Acentuação, palavras mais longas, estrutura diferente, tudo isso mexe na tokenização

Por isso eu não vou te vender "cabem X páginas", porque seria chute e chute nesse assunto é o que faz gente calibrar o max_tokens errado

O teto não é todo do texto final

Esse é o ponto que quase ninguém considera na hora de fazer a conta

Os tokens de thinking são um subconjunto do parâmetro max_tokens

Eles saem de dentro do mesmo orçamento, são cobrados como tokens de saída e contam para os limites de uso

Então quando você define um max_tokens de 128 mil, você não reservou 128 mil tokens de resposta

Você reservou 128 mil tokens de raciocínio + resposta

E no Fable 5 tem um agravante: ele sempre opera com thinking habilitado

Passar thinking: {"type": "disabled"} não é suportado

Não tem como desligar pra "sobrar mais espaço pro texto", esse orçamento vai ser dividido, ponto

E existe um outro nome que aparece nessa conversa: o effort

Ele é o nível de esforço de raciocínio, ou seja, o quanto o modelo se estende pensando antes de escrever

Guarda esse termo, porque ele volta já já quando o pensamento come o orçamento inteiro

Sua resposta foi cortada no meio: como identificar o motivo

Antes de xingar o modelo, olha o stop_reason da resposta

Ele te diz exatamente o que aconteceu, e são três cenários bem diferentes com sintomas parecidos

Caso 1: stop_reason "max_tokens"

Sinal: a resposta chega truncada, cortada no meio, e o stop_reason devolvido é max_tokens

Causa: o modelo bateu no teto daquela requisição

Tem uma variação mais cruel desse caso: um raciocínio longo pode consumir o orçamento ANTES de o texto terminar

Aí você recebe stop_reason: max_tokens com o texto truncado ou até ausente

Você pagou pelo pensamento e não levou a resposta 😬

Solução: continuar em nova requisição, e quando o problema foi o raciocínio comendo o orçamento, a orientação é aumentar o max_tokens ou reduzir o effort (aquele nível de esforço de raciocínio que a gente viu ali em cima)

Caso 2: stop_reason "model_context_window_exceeded"

Sinal: a geração para e o motivo é model_context_window_exceeded

Causa: os tokens de entrada somados ao max_tokens ultrapassam a janela

E olha o detalhe traiçoeiro: a API aceita a requisição nesse caso

Ela não te barra na porta

Se a geração bater no limite da janela durante a escrita, ela para ali

Solução: enxugar a entrada ou baixar o max_tokens pra soma caber na janela

Lembra que input, output e thinking ocupam a MESMA janela de contexto

Caso 3: a requisição nem chega a terminar

Sinal: você pede uma saída grande e a coisa morre por queda de conexão ociosa

Causa: definir um max_tokens grande sem usar a Messages API em streaming ou a Message Batches API

Os SDKs inclusive validam isso: requisições não-streaming não devem exceder o timeout de 10 minutos

Solução (e prevenção): saída longa pede streaming

<pre><code>{ "model": "claude-fable-5", "max_tokens": 64000, "stream": true, "messages": [ { "role": "user", "content": "…" } ] }</code></pre>

Se o trabalho não é interativo, a Message Batches API também é caminho

O erro comum aqui é tratar "conexão caiu" como instabilidade do provedor

Na maioria das vezes é só uma requisição não-streaming pedindo mais texto do que dá pra entregar dentro do timeout

Quando quebrar o trabalho em partes em vez de pedir tudo de uma vez

Agora a parte prática, que é onde essa régua vira decisão

Pede em uma resposta só quando:

• o entregável é UM artefato contínuo que perde sentido fatiado
• você consegue estimar que o texto final fica confortavelmente abaixo do orçamento, lembrando que o thinking também come dali
• você ligou streaming

Quebra em requisições encadeadas quando:

• você está mirando perto do teto de 128 mil, porque "perto do teto" com thinking ligado é basicamente "no teto"
• o trabalho tem partes independentes (módulos, capítulos, arquivos), que é justamente o caso onde continuar de onde parou é barato
• a primeira tentativa já voltou com stop_reason: max_tokens
• o custo importa: a US$ 50 por milhão de tokens de saída, gerar duas vezes o mesmo bloco porque a primeira truncou é dinheiro jogado fora

Conversa longa come janela a cada turno

Esse aqui é sutil e merece atenção

O Claude Fable 5 mantém os blocos de thinking anteriores por padrão

E eles contam na janela de contexto como qualquer token de entrada

Traduzindo: cada turno de uma conversa longa carrega junto o raciocínio dos turnos passados

A janela é enorme, mas ela não é infinita, e quem trabalha em sessões longas sente isso

É o mesmo raciocínio de quando você precisa gerenciar contexto no Claude Code: não é sobre ter espaço, é sobre não deixar o espaço se encher de coisa que já cumpriu o papel

E se você não controla o max_tokens?

Detalhe importante: nem todo ambiente te dá esse botão

O Fable 5 está disponível na Claude API, no Claude Code, no Amazon Bedrock, no GitHub Copilot, no Google Cloud e no Microsoft Foundry, e para usuários Pro, Max, Team e Enterprise

Ele ficou disponível de forma geral em 9 de junho de 2026

Onde você mexe na requisição direto, a régua deste post é literal

Onde a plataforma monta a chamada por você, o que sobra é o comportamento: quebrar o pedido em partes menores continua sendo a jogada quando o entregável é grande

Ah, e vale saber: o Fable 5 e o Claude Mythos 5 compartilham as mesmas especificações e o mesmo preço

A diferença é que o Fable 5 roda com classificadores de segurança que redirecionam pedidos de alto risco (cibersegurança, biologia, química e saúde) para resposta do Claude Opus 4.8

Conclusão

A régua, resumida pra você não esquecer nunca mais:

1 milhão de tokens é a mesa inteira, e tudo ocupa ela: entrada, saída e thinking. 128 mil tokens é o máximo que ele escreve numa única requisição. E o thinking sai de dentro desse orçamento de escrita

São três frases que resolvem a maior parte da frustração com resposta cortada

O próximo passo é bem concreto:

1. Defina o max_tokens DE PROPÓSITO, sabendo que o raciocínio divide esse espaço com o texto final
2. Ligue streaming (ou vá de Message Batches API) sempre que a saída for longa, senão você arrisca perder a requisição por conexão ociosa
3. Confira o stop_reason ANTES de culpar o modelo: max_tokens e model_context_window_exceeded são problemas diferentes, com soluções diferentes

O modelo raramente "esqueceu" o que você pediu

Na maioria das vezes ele só bateu num teto que ninguém tinha configurado direito 🙂

até o próximo post!