Por que o GPT-6 Astra demora para responder e o que fazer na sua aplicação

Fala aí, beleza? Você manda o prompt, a tela fica parada, o cursor piscando, e nada do primeiro token aparecer

A vontade é jurar que travou

Só que o GPT-6 Astra é um modelo de raciocínio, e isso muda a régua: ele pensa antes de escrever, e esse tempo de pensar acontece antes de qualquer caractere chegar na sua tela

O rollout começou em 3 de setembro de 2026, primeiro para um grupo limitado de empresas do programa Daybreak da OpenAI, com acesso para Plus, Pro, Business e Enterprise, e com API da OpenAI e AWS previstos para os dias seguintes

A OpenAI também classificou o Astra como o primeiro modelo a atingir o limiar ‘critical’ em cibersegurança dentro do Preparedness Framework, e foi por isso que o lançamento veio em fases

Neste post a gente separa de onde vem essa espera e, principalmente, o que dá pra mexer na SUA aplicação: esforço de raciocínio, tamanho de contexto, cache, escolha de API, streaming e Fast mode

Bora?

Sintoma: a tela fica parada por vários segundos antes do primeiro token

Causa: em modelo de raciocínio, o tempo até o primeiro token não é só rede e fila, ele inclui o thinking

A própria metodologia da Artificial Analysis deixa isso explícito: o Time to First Answer Token é medido em segundos até o primeiro token recebido, usando 10.000 tokens de entrada, e nos modelos de raciocínio essa métrica inclui o tempo de raciocínio antes da resposta

Ou seja, você não está medindo "o modelo é lento", você está medindo "o modelo pensou por X e só depois falou"

E tem um detalhe importante pra sua expectativa: na página viva da Artificial Analysis, a métrica de output tokens por segundo do GPT-6 Astra (max) aparece como Unknown

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

Não existe medição pública de velocidade de saída dele ainda

O que aparece por lá é o Intelligence Index em 61 e a janela de contexto arredondada em 1,0M (a doc da API detalha esse número, e a gente volta nele na próxima seção)

A Artificial Analysis também publica páginas separadas por variante do modelo: medium, high, xhigh, max e Non-reasoning

Repare que isso é o recorte de benchmark DELES, não a lista de níveis que a API aceita, e são coisas diferentes

Isso é comum quando o modelo é novo demais pro benchmark acompanhar, igual acontece com modelo stealth na OpenRouter que aparece antes de qualquer número oficial existir

Solução: calibrar o reasoning.effort para a tarefa em vez de deixar sempre no topo

Na API, o parâmetro aceita low, medium, high, xhigh e max, e o nível none NÃO é suportado nesse modelo

Mande o effort explícito na chamada: é uma linha de código e tira a dúvida de vez

Como prevenir: defina o effort por tipo de rota da aplicação, não globalmente

Rota de classificação não precisa do mesmo esforço da rota de análise longa, e tratar tudo igual é a forma mais fácil de pagar espera à toa

Sintoma: o mesmo pedido demora muito mais quando o prompt está gigante

Causa: contexto inflado

O gpt-6-astra na API tem janela de 1.050.000 tokens, com máximo de 922.000 tokens de entrada e 128.000 de saída

É esse número que a Artificial Analysis mostra arredondado como 1,0M, então não se assuste se você vir os dois formatos por aí

Janela grande é ótimo, mas vira armadilha: como cabe tudo, a galera joga tudo

E aí vem a parte que dói no bolso: requisições com mais de 272 mil tokens de entrada são cobradas a 2x a tarifa de input e de cache e 1,5x a de output, aplicado à requisição INTEIRA

Com preço base anunciado de US$ 10 por 1M de tokens de entrada e US$ 50 por 1M de saída, estourar essa faixa sem necessidade é o tipo de erro que só aparece na fatura do mês seguinte 😅

Solução: recortar o escopo do pedido e enxugar o que entra no contexto

Na prática: em vez de "analisa esse repositório inteiro", peça "analisa esses 4 arquivos e me diz onde está o acoplamento"

Menos coisa pra ler é menos coisa pra raciocinar em cima

Como prevenir: meça o tamanho do input ANTES de mandar e trate 272K como linha vermelha

Coloque isso como um contador no seu código, não como confiança

Sintoma: toda requisição paga o preço cheio de espera, mesmo repetindo o mesmo prefixo

Causa: seu prefixo de prompt está variando, então o cache nunca é acertado

O prompt caching da OpenAI é automático e sem custo adicional

Ele ativa a partir de 1.024 tokens em modelos GPT-5.6 e posteriores (2.048 em modelos anteriores), com acertos em incrementos de 128 tokens

E tem uma condição dura: só funciona quando duas requisições compartilham exatamente o mesmo prefixo

Exatamente mesmo

Um timestamp no topo do system prompt, um ID de usuário na primeira linha, um "hoje é dia tal" antes das instruções, e pronto: cache nunca bate

O ganho que você está deixando na mesa é grande: o caching pode reduzir a latência de tempo até o primeiro token em até 80% e o custo de tokens de entrada em até 90%

A conta de tarifa também ajuda a entender o incentivo: em GPT-5.6 e posteriores, a escrita no cache custa 1,25x a tarifa de input não cacheado e a leitura custa 0,1x essa tarifa

Você paga um pouquinho a mais uma vez pra pagar quase nada depois

Solução: o que é estável vai no COMEÇO do prompt, o que varia vai no fim

System prompt, instruções fixas, esquema, few-shot: tudo no topo

Pergunta do usuário, dados da sessão, variáveis: tudo lá embaixo

Existe também o parâmetro opcional prompt_cache_key, usado pra melhorar o roteamento de tráfego que compartilha prefixos comuns

Como prevenir: revise se algum campo dinâmico está poluindo o início do prompt

Tome cuidado com montagem de prompt por template: é ali que um campo dinâmico se esconde no meio do bloco fixo sem ninguém perceber

Sintoma: o modelo parece mais lento na Completions API do que deveria

Causa: escolha de API

A documentação da OpenAI recomenda usar modelos de raciocínio, como o gpt-6-astra, pela Responses API, onde eles performam melhor

E não é papo de marketing: em testes citados pela própria OpenAI, migrar da Completions API para a Responses API elevou a utilização de cache de 40% para 80%

Mais cache acertado é menos custo e menos latência, direto

Solução: padronizar a chamada com o campo reasoning

const response = await client.responses.create({
  model: 'gpt-6-astra',
  reasoning: { effort: 'low' },
  input: [
    { role: 'system', content: 'Instruções fixas aqui, sempre iguais, sempre no topo' },
    { role: 'user', content: pergunta }
  ]
})

Repare que o effort vai dentro de reasoning, não solto na raiz

E já adianto uma dúvida clássica de quem vem de Completions: aqui não adianta procurar botão de criatividade

O GPT-6 Astra não suporta valores customizados de temperature nem top_p, e não retorna logprobs

Se seu código atual manda esses parâmetros no automático, essa é uma boa hora de limpar

"E se minha empresa não pode guardar estado?"

Pra organizações com exigência de Zero Data Retention, que não podem usar a Responses API de forma stateful, a OpenAI oferece os encrypted reasoning items, mantendo o fluxo stateless com reaproveitamento dos itens de raciocínio

Como prevenir: padronize a Responses API em todas as rotas que usam raciocínio, e não deixe uma rota legada de Completions sobrevivendo escondida no projeto

Sintoma: o usuário acha que travou e recarrega a página

Causa: espera silenciosa

Enquanto o modelo raciocina, sua UI não tem nada pra mostrar, e cinco segundos de tela vazia parecem cinco minutos pra quem está do outro lado

Solução: dar sinal de vida com streaming

A Responses API emite o evento response.reasoning_summary_text.delta conforme o resumo de raciocínio vai sendo gerado, o que te permite mostrar algo ao usuário antes da resposta final chegar

É o suficiente pra transformar "travou" em "tá pensando"

Agora, um limite que precisa estar claro na sua cabeça antes de prometer qualquer coisa na interface: a OpenAI não expõe os tokens brutos da cadeia de raciocínio

O que a Responses API disponibiliza são os reasoning summaries, os resumos

Quem já se aprofundou nos thinking blocks no Claude Fable 5.1 sabe que cada fornecedor trata esse material de um jeito, então não desenhe uma feature de "veja o pensamento completo do modelo" que a API não entrega

Como prevenir: nunca deixe estado vazio em rota de raciocínio

Skeleton, texto de progresso, resumo em streaming, qualquer coisa é melhor que branco

Sintoma: já cortei tudo e ainda preciso de mais velocidade

Causa: você chegou no limite do que dava pra otimizar no prompt

Escopo enxuto, contexto limpo, cache batendo, effort calibrado, e ainda assim a rota precisa ser mais rápida

Solução: Fast mode

Ele é acionado pelo parâmetro service_tier na requisição, que aceita os valores "fast" ou "priority"

const response = await client.responses.create({
  model: 'gpt-6-astra',
  service_tier: 'fast',
  reasoning: { effort: 'medium' },
  input: [...]
})

O Fast mode está disponível para o GPT-6 Astra na API e entrega até 2x a velocidade do processamento Standard, cobrando 2x as tarifas aplicáveis

Ou seja: é velocidade comprada, não velocidade de graça

Dois detalhes que evitam dor de cabeça:

1. O priority processing foi renomeado para Fast mode em 30 de julho de 2026, e os dois valores de service_tier continuam válidos. O erro comum aqui é achar que "priority" quebrou e sair refatorando código que estava funcionando
2. O Fast mode NÃO está disponível para o GPT-6 Astra com residência de dados na União Europeia. Nesses casos é preciso usar o processamento Standard, e o erro comum é descobrir isso só quando a requisição do ambiente europeu se comporta diferente do seu ambiente de teste

Pra quem quiser ir mais fundo, a OpenAI mantém um guia dedicado de Latency optimization na documentação da API

Como prevenir: reserve o Fast mode para as rotas que realmente têm um humano esperando na tela

Job que roda de madrugada pagando 2x é dinheiro queimado 🙂

Sintoma: está lento no ChatGPT, não na sua aplicação

Esse caso é outro campeonato, então vale separar

Se você não está na API, reasoning.effort não é o seu botão

No ChatGPT existe um controle de thinking time com os níveis Light, Standard, Extended e Heavy

Standard e Extended estão disponíveis para Plus e Business, e o Pro tem também Light e Heavy

E tem um contexto interessante aí: em 10 de janeiro de 2026 a OpenAI reduziu o tempo de raciocínio dos níveis Standard e Light, depois de observar que os usuários preferem respostas mais rápidas

Ou seja, a tensão entre "pensa mais" e "responde logo" não é frescura sua, é produto sendo ajustado

Só não confunda os dois mundos: esse seletor é do ChatGPT e não substitui o reasoning.effort da API, são controles de produtos diferentes

Como prevenir: escolha o nível pela tarefa ANTES de mandar o prompt, e não no meio da espera

Como é esperar na prática: 10 minutos para um projeto nascer

Aqui eu não vou fingir que já rodei bateria de teste no GPT-6 Astra, porque não rodei

Mas eu tenho material próprio sobre a sensação de esperar um modelo de raciocínio trabalhar, e ele calibra bem a expectativa

No vídeo em que eu testo o Sonnet 5 dentro do Claude Code, eu fiquei vários minutos olhando pra tela antes de qualquer resultado aparecer

O primeiro projeto era um quadro Kanban em React pedido em um único prompt, e quando voltei a acompanhar ele ainda estava rodando, por volta de 8 minutos

Terminou com cerca de 10 minutos

E essa não foi uma exceção: a média que eu venho observando pra scaffolding de projeto com o modelo maior fica em torno de 10 minutos

Uma coisa que ficou clara pra mim é que o modelo começa pelo scaffolding, a criação da estrutura inicial de pastas, e essa etapa sozinha já come boa parte do tempo

Outra: a demora acompanha a complexidade do pedido

O jogo estilo Pac-Man em HTML5 canvas, com 2 níveis de dificuldade criados pelo modelo, levou bem mais tempo que os projetos web, porque envolve mecânica, animação e física

Enquanto o primeiro projeto processava, eu abri outros em paralelo pra não ficar parado

No encurtador de URLs eu pedi em etapas, backend primeiro, frontend depois, com instrução explícita de manter consistência de nomes, arquivos, rotas e esquema entre os prompts

E no fim eu testei os três rodando de verdade no navegador, movendo card, usando filtro e busca, cadastrando e encurtando link, chegando no game over do jogo

Julgar pelo código gerado é fácil, julgar pelo resultado rodando é o que vale

A lição que eu tiro disso pra quem está construindo aplicação com raciocínio pesado: tarefa grande é medida em MINUTOS, não em segundos

E se o seu produto vai fazer o usuário esperar minutos, a interface precisa ser desenhada pra isso desde o começo, com progresso, resumo em streaming e a possibilidade de tocar outra coisa enquanto o modelo trabalha

Qual nível de esforço usar em cada tipo de tarefa

Traduzindo tudo isso em decisão prática, por cenário:

Lembrando os limites do modelo pra você não desenhar em cima do que não existe:

• reasoning.effort aceita low, medium, high, xhigh e max, e none não é suportado nesse modelo
• não dá pra usar temperature ou top_p customizados
• não conte com logprobs, ele não retorna

O padrão mental é simples: esforço alto é pra quando o erro custa caro, esforço baixo é pra quando a espera custa caro

Conclusão

Quando alguém diz que o GPT-6 Astra está lento, na esmagadora maioria das vezes o problema tem nome: escopo largo demais, contexto inflado ou UI sem feedback nenhum durante o raciocínio

O modelo pensar antes de responder não é bug, é o desenho dele

Seu próximo passo, bem concreto:

1. Instrumente o tempo até o primeiro token nas suas rotas, porque sem medir você só tem sensação
2. Baixe um nível de effort na rota mais quente e compare o resultado, não só o tempo
3. Confira se o prefixo do prompt está estável o bastante pra bater cache, lembrando que precisa ser prefixo idêntico

E vale o lembrete: quando o modelo foi anunciado, o rollout ainda estava em fases, começando pelas empresas do Daybreak, com os demais planos e a API previstos pros dias seguintes

Então disponibilidade pode variar dependendo de onde e quando você está testando

Mede, recorta, mostra progresso pro usuário e segue o jogo 😀

até o próximo post!