Por que o GPT-6 Astra corta a resposta no meio? O limite de 128 mil tokens de saída e como fatiar tarefas longas

Fala aí, beleza? Poucas coisas irritam mais que pedir um documentão pro modelo, esperar, e ver o texto parar assim: "e para configurar o serviço basta"

E acabou 😅

Se liga no que quase sempre está por trás disso: o GPT-6 Astra tem janela de contexto de 1.050.000 tokens e limite máximo de 128.000 tokens de saída

São dois números BEM diferentes, e é o segundo que corta a tua resposta no meio

É tipo caixa d’água e torneira: a caixa (o contexto) é gigante, mas a vazão da torneira (a saída por resposta) tem um teto fixo

O modelo entrou em rollout escalonado no dia 3 de setembro de 2026, começando pelas empresas do Trusted Access Program, com acesso mais amplo via API e nos planos ChatGPT Plus, Pro, Business e Enterprise anunciado para os dias seguintes

Então muita gente está batendo nesse teto agora, pela primeira vez, e achando que é bug

Não é. É orçamento de saída, e dá pra trabalhar com ele

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

Sintoma 1: a resposta para no meio de uma frase ou de um bloco de código

O sintoma é o mais óbvio de todos: o texto simplesmente encerra

Às vezes no meio de uma palavra, às vezes com a cerca de código aberta e nunca fechada

A causa:

A geração bateu no teto de tokens de saída daquela chamada

Não importa se sobrou contexto de sobra. O contexto é o quanto ele consegue LER, o max_output_tokens é o quanto ele pode ESCREVER naquela resposta

Quem já brigou com limites de resposta longa em outros modelos já conhece esse padrão de cabeça

Como identificar (sem achismo):

Não fique adivinhando pelo texto. A própria resposta te conta

Na Responses API, o retorno vem com status igual a incomplete e incomplete_details.reason igual a max_output_tokens

# Responses API
if resp.status == "incomplete" and resp.incomplete_details.reason == "max_output_tokens":
    print("truncou por limite de saída, precisa continuar em outra chamada")

Os valores possíveis de reason são max_output_tokens ou content_filter, então se veio o primeiro, é teto de saída mesmo

Na Chat Completions API o sinal é outro campo:

# Chat Completions API
if finish_reason == "length":
    print("truncou por ter atingido o teto de tokens de saída")

A solução:

Reduzir o escopo POR REQUISIÇÃO e continuar a geração numa nova chamada

Não é gambiarra, é o jeito certo de lidar com um teto por resposta

Como prevenir:

Definir o tamanho do entregável ANTES de pedir

"Escreva a documentação completa do sistema" é um pedido sem tamanho, e pedido sem tamanho estoura

"Escreva o capítulo 3, cobrindo só autenticação, em no máximo X seções" é um pedido com contorno

Sintoma 2: você pagou a requisição e recebeu resposta vazia

Esse é o que dói no bolso 😛

Nenhum token visível voltou, a tela ficou em branco, mas a requisição contou na fatura

A causa:

O max_output_tokens limita o TOTAL de tokens que o modelo gera, e isso inclui tokens de raciocínio, tokens de saída visível e tokens de formatação não visíveis

Ou seja: o corte pode acontecer antes de qualquer token visível ser produzido

Aí você paga input e raciocínio e não recebe resposta nenhuma

Tome cuidado com isso, porque é justamente quando a pessoa aperta o limite "pra economizar" que a conta vira desperdício puro

A solução:

A OpenAI recomenda reservar pelo menos 25.000 tokens para raciocínio e saída ao começar a usar modelos de raciocínio

E o segundo ajuste é o esforço de raciocínio: no GPT-6 Astra o reasoning.effort aceita low, medium, high, xhigh e max

O nível none não é suportado nesse modelo, então não adianta tentar zerar o raciocínio pra sobrar tudo pro texto

{
  "model": "gpt-6-astra",
  "max_output_tokens": 25000,
  "reasoning": { "effort": "medium" }
}

O valor de max_output_tokens aí em cima é a reserva mínima recomendada, ajuste ao teu entregável (o teto do modelo continua sendo 128.000)

Como prevenir:

Nunca apertar o max_output_tokens no tamanho exato do texto que você espera receber

Se você acha que o capítulo vai dar X, o orçamento precisa ser maior que X, porque o raciocínio come do mesmo pote

Sintoma 3: a contagem de tokens de saída não bate com o texto que você recebeu

Esse aqui é o clássico "mas eu recebi meia página, por que a contagem tá tão alta?"

A resposta veio curtinha, e mesmo assim o output_tokens (Responses) ou o completion_tokens (Chat Completions) apareceu MUITO acima do tamanho aparente

A causa:

O uso de tokens de saída reportado inclui todos os tokens gerados pelo modelo, não só o texto visível

E tem mais: tokens de raciocínio são cobrados como tokens de saída, na tarifa padrão de output do modelo

Então não existe raciocínio "de graça" acontecendo nos bastidores. Ele está na conta e está no orçamento

A solução:

Tratar raciocínio como parte do orçamento de saída na hora de dimensionar cada fatia

A fatia não é "o texto que eu quero". A fatia é "o texto que eu quero + o que o modelo vai pensar pra escrever isso"

Como prevenir:

Medir o custo real de UMA fatia antes de escalar o processo pras outras cinquenta

Roda uma, olha o output_tokens, compara com o texto que voltou

Aí sim você sabe o tamanho de fatia que cabe, e não vai descobrir isso na fatura do mês

Como fatiar um documento longo ou um refactor grande em etapas

Bora ver na prática? A ideia é simples: em vez de um pedido gigante que morre no meio, você monta uma linha de produção

1. Defina o entregável e quebre em partes nomeadas. Antes de qualquer chamada, escreva a lista: "capítulo 1: instalação", "capítulo 2: configuração", "capítulo 3: autenticação". Parte sem nome é parte que você não consegue conferir depois. O erro comum deste passo: pedir "a documentação inteira" e deixar o recorte por conta do modelo.

2. Peça primeiro só o esqueleto, numa requisição curta. Índice, títulos e uma linha de escopo por parte. É barato, é rápido e vira o contrato do resto do trabalho. O erro comum deste passo: já mandar o esqueleto junto com o pedido do conteúdo, o que devolve o problema pro mesmo teto de saída.

3. Gere uma parte por requisição, passando o esqueleto como contexto. Cada chamada recebe o índice completo e a instrução de escrever SÓ a parte da vez. É isso que mantém coerência entre as fatias sem inflar a saída. O erro comum deste passo: mandar duas ou três partes "que são curtinhas" na mesma chamada, e aí a terceira trunca.

4. Reserve folga de saída e ajuste o reasoning.effort por etapa. Esqueleto e revisão pedem menos esforço, trecho difícil pede mais. E não perca tempo tentando calibrar por outro caminho: o GPT-6 Astra não aceita valores customizados de temperature, top_p nem logprobs. O erro comum deste passo: apertar o max_output_tokens no limite exato do texto esperado e cair direto no sintoma 2.

5. Cheque o status de término de CADA chamada antes de seguir. finish_reason == "length" na Chat Completions, incomplete_details.reason == "max_output_tokens" na Responses. Se truncou, essa parte volta pra fila menor, não vai pro documento final. O erro comum deste passo: juntar tudo primeiro e só descobrir o buraco na hora da revisão final.

6. Junte as partes na ordem do esqueleto. Como cada fatia foi gerada contra o mesmo índice, a costura é montagem, não reescrita. O erro comum deste passo: pedir pro modelo "juntar e revisar tudo de uma vez" no final, que é exatamente o pedido gigante que você estava evitando desde o começo 😅

Quando fatiar de verdade compensa: documentação, migração de código e relatórios

Nem toda tarefa longa se fatia igual. O segredo é achar a unidade natural de corte de cada uma

Documentação técnica: a fatia é o capítulo

Capítulo é uma unidade que já nasce autocontida: tem começo, meio e fim próprios

Você gera o índice primeiro, depois um capítulo por chamada

Se um capítulo estourar, ele vira duas seções e pronto, o resto do documento nem sente

Migração de código: a fatia é o arquivo

Aqui a unidade é óbvia e quase ninguém usa: um arquivo por requisição

Migrar dez arquivos numa chamada só é o caminho mais curto pra receber sete arquivos completos e o oitavo cortado no meio de uma função, o que é bem pior que não ter feito nada

E tem um detalhe que só aparece na prática: arquivo cortado no meio parece pronto se você não conferir o status de término, aí o pedaço quebrado entra no commit e você descobre no build

Vale o mesmo raciocínio de consumo de tokens em tarefas longas com agente de código: tarefa grande sem recorte vira token queimado

Relatório: a fatia é a seção

Relatório tem estrutura fixa (resumo, dados, análise, conclusão), então o recorte já vem pronto de fábrica

Gera seção por seção passando o sumário como contexto, e deixa a conclusão por último, quando as outras seções já existem e podem ser resumidas de verdade

Se uma seção de dados for pesada, quebra ela por tabela ou por indicador, que a lógica é a mesma: cada fatia precisa caber com folga no orçamento de saída, contando o raciocínio junto

O outro lado da conta: contexto gigante custa caro mesmo sem estourar a saída

Tem gente que resolve o truncamento do jeito errado: enfia TUDO no contexto de uma vez pra não precisar fatiar

Só que o contexto tem preço, se liga na tabela

E olha o detalhe que pega: prompts com mais de 272.000 tokens de entrada são cobrados com 2x nas taxas de entrada e de cache e 1,5x na taxa de saída, valendo para a REQUISIÇÃO INTEIRA

Não é só o excedente que fica mais caro. É tudo

Conclusão prática: encher o contexto de 1.050.000 tokens só pra fugir do trabalho de fatiar sai mais caro que fatiar

E, de quebra, você continua com o mesmo teto de 128.000 tokens de saída no fim da linha, então nem resolveu o problema original 🙂

Vídeo: por que boa parte dos tokens do seu agente vai pro lixo

Orçamento de saída é só metade da história: tem também o token que você gasta à toa antes mesmo de gerar qualquer coisa

Pra começar do zero nesse assunto de desperdício de tokens em agente, este vídeo do canal mostra o problema e apresenta o FastContext:

Conclusão

Guarda essas duas ideias e você para de apanhar:

Janela de contexto é o quanto o modelo lê (1.050.000 tokens), teto de saída é o quanto ele escreve por resposta (128.000 tokens)

E checar o status de término de cada chamada precisa virar hábito, não algo que você faz só quando desconfia: finish_reason == "length" ou incomplete_details.reason == "max_output_tokens" já te contam tudo

Próximo passo, bem concreto: no teu próximo documento longo, gaste UMA requisição curta só pro esqueleto antes de gerar qualquer conteúdo

É a chamada mais barata do processo e é ela que segura o resto de pé

Ah, e pra fechar o operacional: o modelo aparece como gpt-6-astra na API da OpenAI e também está disponível no Amazon Bedrock, e tool calling só rola pela Responses API

até o próximo post! 😀