Streaming ou resposta completa no GPT-6 Astra: qual escolher na sua aplicação?

Tem decisão que parece detalhe de API e vira experiência do usuário na cara dura

Fala aí, beleza? A OpenAI anunciou o rollout do GPT-6 Astra em 03/09/2026, o novo modelo de topo da linha da casa, e na API ele atende pelo id gpt-6-astra

Aí bate a dúvida na hora de plugar ele no teu produto: tu entrega o texto em pedaços conforme o modelo escreve, ou espera a resposta inteira chegar e mostra de uma vez?

Parece escolha de front, mas mexe em percepção de velocidade, em como tu trata erro no meio da geração e em quanta complexidade tu vai carregar pelo resto da vida do projeto

Bora comparar

O que o GPT-6 Astra suporta hoje:

Antes de escolher, o básico do que está na mesa

O gpt-6-astra suporta streaming, e está disponível tanto na Chat Completions quanto na Responses API

Batch também é suportado, fine-tuning não

Segundo a ficha do modelo no llm-stats, a janela é de 1.050.000 tokens de contexto, com 128.000 tokens de saída máxima

O preço no tier padrão e contexto curto fica assim: US$ 10,00 por 1 milhão de tokens de entrada, US$ 50,00 por 1 milhão de tokens de saída e US$ 1,00 por 1 milhão de tokens de entrada em cache

Repara numa coisa importante: o preço NÃO muda se tu liga ou desliga o streaming

O que muda é onde o tempo aparece pro usuário, e é aí que a comparação começa 🙂

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

Streaming x resposta completa: comparação lado a lado

Os tempos e as velocidades que aparecem na tabela abaixo não são medição minha, são os números publicados pelo Artificial Analysis pra esse modelo

Olha os números de espera até o primeiro token de novo, ainda na medição do Artificial Analysis

2,60s no low e 155,16s no xhigh: isso não é a mesma aplicação, é outro universo de UX

Se a tua dor é justamente essa espera antes de qualquer coisa aparecer na tela, dá uma olhada em por que o Astra demora para responder, porque streaming ameniza o sintoma mas não resolve a causa

Qual modo escolher por tipo de interface

Chat com humano esperando na frente da tela:

Streaming, sem pensar muito

Com esforço low ou medium, a primeira palavra sai em poucos segundos e o resto vai desenrolando na casa das dezenas de tokens por segundo

O usuário lê enquanto o modelo escreve, e a espera vira leitura em vez de spinner girando

Script de terminal, cron ou pipeline de dados:

Resposta completa

Não tem ninguém olhando, então mostrar o texto nascendo não entrega valor nenhum, só te obriga a escrever código de acumular delta à toa

E se o volume for grande e o resultado não for pra agora, o gpt-6-astra também suporta Batch

Job em segundo plano dentro do produto:

Modo background, que eu explico logo abaixo

Geração que o usuário dispara e vai fazer outra coisa não combina com conexão aberta esperando

Geração longa, perto do teto de 128.000 tokens de saída:

Aqui mora a pegadinha

Respostas com mais de 5 minutos não podem mais ser transmitidas por streaming, e texto muito longo com esforço alto passa desse tempo com facilidade

Só lembra que subir o esforço de raciocínio não infla só o relógio: infla também os reasoning tokens que tu paga na saída

Pra esse cenário, background é a escolha mais tranquila que ficar rezando pra conexão sobreviver

Como ligar o streaming na Responses API:

Passo a passo curto, só com o que está documentado

1. Mande stream como true no corpo da requisição da Responses API, junto do model id

{
  "model": "gpt-6-astra",
  "stream": true
}

2. Trate a entrega como server-sent events (SSE), e não como um JSON único no fim

O erro comum deste passo é exatamente esse: o time consome a resposta como texto puro, faz um JSON.parse no corpo inteiro e quebra tudo

3. Consuma os eventos tipados, que é o jeito da Responses API entregar as coisas

Os mais comuns pra texto são:

response.created
response.output_text.delta
response.completed
error

O response.output_text.delta é o pedaço novo de texto, o response.completed fecha o ciclo

4. Acumule os deltas no teu lado e renderize o texto crescendo

Erro comum aqui: tratar cada delta como uma mensagem separada, o que faz o front piscar ou duplicar trecho

5. Guarde o sequence_number que vem em cada evento

Ele é o cursor da tua posição no stream, e sem ele tu não tem como pedir a continuação depois de uma queda

Quando o stream cai no meio: erro, retomada e limites

Sintoma: a conexão morre no meio da geração e o usuário fica com meio parágrafo na tela

Causa: stream é conexão aberta, e conexão aberta cai (wi-fi ruim, proxy, timeout de load balancer, o que tu imaginar)

Sintoma 2: chega um evento de erro em vez de texto

O evento de erro do streaming tem type sempre igual a error e carrega code, message e sequence_number

Ou seja: dá pra logar o motivo E o ponto exato onde parou, o que é ótimo

Solução: retomar de onde parou, usando starting_after no GET da resposta

GET https://api.openai.com/v1/responses/{response_id}?stream=true&starting_after=N

O N é o último sequence_number que tu recebeu com sucesso

Limite duro, e esse dói: respostas com mais de 5 minutos não podem mais ser transmitida por streaming, então a janela de retomada fecha junto

Se a tua geração é longa, não conta com a retomada como plano A

Bônus do Chat Completions: se tu usa stream_options com include_usage em true, o último chunk pode vir com o array choices vazio

{
  "stream_options": { "include_usage": true }
}

Parece bug, não é

O erro comum é o front fazer choices[0] sem checar tamanho e estourar bem no finalzinho, quando tudo já tinha dado certo, haha

Prevenção: guarda sempre o response id e o último sequence_number recebido

São as duas únicas coisas que te salvam depois

Background: a terceira opção que muita gente esquece

O modo background executa a geração de forma assíncrona, sem manter a conexão aberta

Tu dispara, recebe o id da response e vai consultando por polling até chegar num estado terminal

Se você conhece fila de jobs (Sidekiq, Celery, Bull, esses da vida), é a mesma ideia: enfileira e checa depois

E dá pra combinar os dois mundos, background e stream na mesma requisição

{
  "model": "gpt-6-astra",
  "background": true,
  "stream": true,
  "store": true
}

Tome cuidado com o store! Em requisições background, a resposta só é retida além do período de polling quando store vem como true explicitamente

Sem isso ela é apagada em cerca de 10 minutos, e aí o teu job assíncrono vira um belo de um 404

Outra coisa que reforça o cinto de segurança: a OpenAI já registrou um incidente em que parte das requisições em modo background da Responses API ficou presa no estado queued, ou seja, o job era aceito mas não avançava pro estado terminal

O registro indica que os serviços impactados se recuperaram totalmente, beleza

Mas serve de lembrete: teu polling precisa de timeout, de retry e de um plano pra quando o estado não muda

Assumir que a resposta sempre chega é a receita pra job pendurado pra sempre

Veredito: quando cada modo compensa

Tem humano olhando a tela? Streaming, e ponto

Não porque fica mais rápido, mas porque a espera vira leitura, e isso é percepção de velocidade de graça

Ninguém olhando? Resposta completa

Menos código, menos estado, menos coisa pra quebrar no front

Coisa longa, ou que o usuário dispara e sai andando? Background com polling bem feito

Agora o trade-off menos óbvio, que quase ninguém coloca na conta na hora de decidir

Streaming dificulta moderar conteúdo em produção

Resposta parcial é mais difícil de avaliar, e os scores de moderação só chegam depois da saída completa, eles não vêm junto dos deltas parciais

Traduzindo: se o teu produto precisa barrar conteúdo ANTES de aparecer pro usuário, o streaming trabalha contra você

E o que não muda entre os três modos: o custo por token

São os mesmos US$ 10,00 por 1M de entrada e US$ 50,00 por 1M de saída em qualquer um deles

Então isso aqui é decisão de arquitetura e de experiência, não de economia

Conclusão

A regra de bolso é boba de tão simples: se tem alguém olhando a tela, streaming; se não tem, resposta completa ou background

O resto é consequência disso, incluindo o tanto de complexidade que tu aceita colocar no front e como tu vai lidar com queda no meio da geração

Antes de fixar a arquitetura, faz o teste: roda a MESMA tarefa nos dois modos e mede duas coisas, tempo até o primeiro token e tempo total até o texto completo

Com esses dois números na frente, a escolha entre streaming e resposta completa deixa de ser opinião e vira decisão

Só não esquece de guardar o response id e o último sequence_number, que é o que te salva quando a conexão resolve morrer 😀

até o próximo post!