Seu agente chama uma ferramenta lenta (uma consulta ao ERP, um relatório que leva um minuto pra montar) e fica parado esperando a resposta. Você paga o modelo pra esperar, o usuário olha pro spinner, e se ele quiser corrigir o rumo no meio, tem que cancelar tudo e começar de novo. Esse era o desenho de todo agente até aqui.

A OpenAI liberou o GPT-6 Astra na API com três recursos que atacam exatamente isso. O modelo foi apresentado em 3 de setembro, e eu já escrevi sobre o que ele é e quanto custa e sobre os números que ninguém estava mostrando. Este post é sobre a parte que interessa a quem escreve código: o que a API ganhou, o que quebra na migração e onde cada recurso novo vale o trabalho.

• Ferramenta assíncrona: o modelo segue trabalhando enquanto sua função roda

• Correção no meio do turno, mas só por WebSocket

• Esforço de raciocínio ajustável sem perder o cache de prompt

• Os parâmetros que somem e o que fazer com cada um

• A ordem certa pra migrar sem descobrir erro em produção

O que chegou de fato na API

O GPT-6 Astra está disponível como gpt-6-astra nos endpoints Responses, Chat Completions e Batch, com três recursos exclusivos dele: chamada assíncrona de ferramentas, correção no meio do turno e mudança do esforço de raciocínio entre respostas sem invalidar o cache. Nenhum modelo anterior da OpenAI, incluindo o GPT-5.6, tem os três.

O e-mail de lançamento fala em "modelo mais inteligente e alinhado de todos os tempos" e cita o Terminal-Bench 4.0 e o Intelligence Index v4.3 da Artificial Analysis. Não vou repetir a discussão de benchmark aqui: ela está no post Astra contra Claude Fable 5.1, e o resumo é que os dois cobram o mesmo na tabela e a diferença aparece na fatura. O que este post cobre é o que a documentação oficial do modelo lista como novo pra quem constrói, e o que ela lista como descontinuado.

Uma coisa que a documentação diz e o e-mail não: junto com os recursos veio um monitoramento assíncrono de desalinhamento, que dispara alertas quando o comportamento do modelo sai do esperado. É a parte "alinhado" da frase de marketing traduzida em sistema. Pra quem roda agente com autonomia real, é o tipo de detalhe que importa mais que um ponto a mais no benchmark.

Ferramenta assíncrona: o modelo não espera mais

Uma chamada de função normal pausa a geração até o resultado voltar. Com async: true na definição da ferramenta, o Astra continua raciocinando, chama outras ferramentas ou responde as partes que não dependem daquele resultado, enquanto sua aplicação executa a função em segundo plano. Quando o resultado chega, você devolve com o mesmo call_id numa requisição seguinte.

Na prática, o fluxo fica assim: o modelo emite a chamada e segue; sua aplicação dispara o trabalho; quando terminar, você manda um item function_call_output (ou custom_tool_call_output, pra ferramenta customizada) com o call_id original e o previous_response_id da resposta em andamento. Se em algum ponto o modelo precisar do resultado antes de continuar, existe a ferramenta síncrona wait_for_tasks, que recebe os task_handle pendentes e espera só por eles.

const tools = [{
  type: "function",
  name: "gerar_relatorio",
  async: true,
  parameters: { /* ... */ },
}];

// O modelo chamou a ferramenta e seguiu trabalhando.
const trabalho = gerarRelatorio(args); // roda em segundo plano

// Quando terminar, devolve o resultado pela mesma call_id.
const resultado = await trabalho;
await client.responses.create({
  previous_response_id: ultimaResposta.id,
  input: [{
    type: "function_call_output",
    call_id: chamada.call_id,
    output: JSON.stringify(resultado),
  }],
});

Três limites que a página do recurso deixa claros e que mudam o desenho: não funciona com as ferramentas hospedadas da própria OpenAI (busca na web, busca em arquivos e afins), não funciona em modo multiagente com chamadas paralelas, e não se aplica ao "programmatic tool calling". Ou seja, é pra sua ferramenta lenta, no seu agente, em modo padrão.

O ganho é de tempo de parede, não de tokens. O modelo que continua trabalhando gera saída enquanto espera, e saída é o token caro. Se a ferramenta lenta é a única coisa que o agente tem pra fazer naquele momento, o assíncrono não te dá nada além de complexidade. Ele vale quando existe trabalho independente pra fazer em paralelo: montar a resposta parcial, chamar a segunda ferramenta, validar o que já chegou.

Assíncrono resolve espera, não custo. Quem resolve custo é o cache.

Correção no meio do turno, só por WebSocket

O segundo recurso é o que a OpenAI chama de steering: o usuário (ou seu sistema) manda uma instrução nova enquanto o modelo ainda está executando, sem esperar a resposta terminar. O Astra incorpora a correção no que ainda vai fazer e preserva o que já fez. Só o GPT-6 Astra suporta isso; o GPT-5.6 e os anteriores, não.

A mecânica é um evento response.steer enviado pelo WebSocket da Responses API, com o previous_response_id da resposta em andamento e o input novo (texto ou lista de mensagens). A API responde response.steer.accepted quando enfileira. Se a correção interrompe a resposta original, ela fecha como response.incomplete com incomplete_details.reason igual a steered, e a continuação já nasce com a instrução nova. Erros voltam por response.steer.failed, e entre eles está too_many_pending_steers: dá pra empilhar correções, mas não sem limite.

O que ele não faz, e a documentação do steering é honesta nisso: não reescreve o que já foi enviado, não desfaz ação já executada e não cancela ferramenta já disparada. Se o agente já mandou o e-mail, a correção chega tarde. Steering é volante, não freio de mão.

A restrição de WebSocket é a que mais pesa. Se a sua integração é HTTP com streaming por SSE, como a maioria das integrações pequenas, não existe steering pra você sem reescrever a camada de transporte. Faz sentido em produto com humano na frente da tela, acompanhando o agente em tempo real. Em rotina de servidor que roda sozinha de madrugada, não há ninguém pra corrigir nada, e o recurso não muda a sua vida.

Raciocínio ajustável sem perder o cache

O terceiro recurso é o que mais mexe na conta. O Astra aceita reasoning.effort em cinco níveis (low, medium, high, xhigh e max) e não aceita none. Até aqui, trocar o esforço no meio de uma conversa longa significava trocar um parâmetro da requisição, e isso invalidava o prefixo cacheado. Em conversa de agente, com dezenas de turnos e um contexto de centenas de milhares de tokens, o cache é a diferença entre pagar US$ 10 e pagar US$ 1 por milhão de tokens de entrada.

Agora existe um item configuration_update que você insere entre uma resposta e outra, deixando o reasoning.effort da requisição intocado. O prefixo original continua igual, o cache continua valendo, e o próximo passo roda com o esforço que você pediu. A página de raciocínio descreve o uso: subir o esforço pro passo difícil, baixar pro acompanhamento de rotina.

Dois avisos da mesma página, que viram bug silencioso se ignorados: não combine configuration_update com a compactação automática de contexto, e nunca coloque dois configuration_update em sequência. E o recurso só existe no modo padrão, de agente único. Quem já orquestra vários agentes numa mesma resposta fica de fora.

É aqui que o Astra se separa de verdade na fatura. No post sobre o Claude Fable 5.1 eu mostrei o cache de leitura da Anthropic quatro vezes mais barato que o da OpenAI. O Astra responde não baixando o preço, e sim tornando mais difícil perder o cache que você já pagou pra criar. São estratégias diferentes pro mesmo problema, e qual vence depende de quanto do seu tráfego é prefixo repetido.

O que quebra na migração

A lista abaixo é a que a documentação de migração apresenta, e é a parte que ninguém coloca no e-mail de lançamento. Se você está saindo do GPT-5.6, cada linha é um lugar onde o código atual passa a dar erro ou a se comportar diferente.

O que você tem hoje	O que acontece no Astra	O que fazer
temperature, top_p, top_logprobs	Descontinuados	Remover das requisições
logprobs (Chat Completions) e message.output_text.logprobs (Responses)	Descontinuados	Remover; não há substituto
Tool calling pelo Chat Completions	Não suportado por completo	Migrar a chamada de ferramentas pra Responses API
reasoning.effort em none ou minimal	none não existe no Astra	Começar em low e comparar a saída
prompt_cache_retention	Substituído	Usar prompt_cache_options.ttl com "30m"
Modo rápido com residência de dados na UE	Indisponível	Ficar no Standard ou trocar a região

O item mais traiçoeiro é o do Chat Completions. Muita integração antiga usa esse endpoint com tools e funciona bem no GPT-5.6. No Astra ela pode até responder, mas sem o tool calling completo, e o agente passa a "resolver" tarefas sem chamar a ferramenta que deveria. Isso não dá erro, dá resultado errado, que é pior. A migração pra Responses API é o primeiro passo, não o último.

O segundo mais traiçoeiro é o temperature. Ele está em quase todo wrapper, em quase todo template de projeto, e no Astra é parâmetro descontinuado: a orientação oficial é remover. A Anthropic fez o mesmo movimento no Fable 5.1 e o efeito foi uma leva de agentes antigos quebrando com erro 400 em produção. O padrão se repete: os fornecedores estão tirando do desenvolvedor os botões que atrapalhavam o raciocínio do modelo, e o código legado paga a conta.

A documentação ainda recomenda ajustar o prompt pra "iniciativa e continuidade", pra evitar que o modelo pare pedindo aprovação onde não precisa. Traduzindo: o Astra vem calibrado pra ser mais autônomo, e se o seu prompt antigo dizia "confirme antes de cada passo", ele vai confirmar demais. Reescrever a instrução de autonomia é parte da migração, não polimento.

Quanto custa e onde o cache compensa

Os preços de tabela do GPT-6 Astra na API são US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de saída, com leitura de cache a US$ 1 e escrita de cache a US$ 12,50. Batch e Flex custam metade do Standard; o modo rápido, o dobro. A janela de contexto é de 1.050.000 tokens, com saída máxima de 128.000, e prompts acima de 272 mil tokens têm multiplicador adicional. O corte de conhecimento é 30 de abril de 2026.

Modo	Entrada (por 1M)	Saída (por 1M)
Standard	US$ 10,00	US$ 50,00
Leitura de cache	US$ 1,00	não se aplica
Escrita de cache	US$ 12,50	não se aplica
Batch	US$ 5,00	US$ 25,00
Flex	US$ 5,00	US$ 25,00
Rápido	US$ 20,00	US$ 100,00

A tabela é a mesma que a página do modelo publica, e a escrita de cache a US$ 12,50 é o detalhe que muita gente não olha: criar cache custa 25% a mais que uma entrada normal. Vale quando o prefixo vai ser lido muitas vezes; não vale pra conversa de um turno. Junte isso ao configuration_update e o desenho fica claro: a OpenAI quer que você construa agentes de conversa longa, com prefixo estável, lendo cache barato dezenas de vezes. É nesse cenário que o Astra fica competitivo com o Claude, e é fora dele que ele fica caro.

Pra quem precisa de velocidade em vez de contexto, o caminho continua sendo o Ultrafast com o GPT-5.6 Sol, que roda em outra classe de latência. O Astra não é o modelo de resposta rápida; é o modelo de tarefa longa.

A ordem certa pra migrar

No golber.net a geração de conteúdo roda numa cadeia de modelos com fallback entre fornecedores, e eu troco de modelo por rotina e por medição, não por e-mail de lançamento. É com essa cabeça que eu faria a migração pro Astra, nesta ordem:

1. Mover a chamada de ferramentas pra Responses API antes de trocar o modelo. Sem isso, nada do que vem depois funciona direito.

2. Tirar temperature, top_p e logprobs de todas as requisições, e trocar prompt_cache_retention por prompt_cache_options.ttl. Fazer isso num commit separado, testável.

3. Trocar o modelo pra gpt-6-astra com reasoning.effort em low e comparar saída e custo com o GPT-5.6 na mesma amostra de tarefas. Subir o esforço só onde a qualidade caiu.

4. Adotar configuration_update nos fluxos longos, medindo a taxa de acerto de cache antes e depois. Se a taxa não subir, o problema é prefixo instável, não esforço.

5. Ligar async: true só na ferramenta que comprovadamente segura o agente e só onde existe trabalho paralelo a fazer.

6. Steering por último, e só se o produto tem humano acompanhando em tempo real por WebSocket.

Repare que os três recursos novos são os três últimos passos. A migração que dá certo é a chata: endpoint, parâmetros, medição. Os recursos bonitos vêm depois que o básico parou de dar erro 400.

Recurso novo em agente que ainda não mede custo por tarefa é dívida com juros.

Se o seu sistema já tem agente rodando e você não quer descobrir cada uma dessas quebras em produção, esse é exatamente o tipo de trabalho que eu faço numa sessão de consultoria técnica: a gente abre o código, lista o que quebra, migra o endpoint e sai com a medição montada. E se você ainda está decidindo se agente faz sentido pro seu negócio, comece pelo post sobre agentes em looping infinito, que mostra onde isso funciona de verdade e onde só parece que funciona.

Perguntas frequentes

O GPT-6 Astra funciona no Chat Completions?

Funciona pra conversa simples, mas a documentação avisa que o tool calling não é suportado por completo nesse endpoint. Agente com ferramentas precisa da Responses API. Batch também está disponível.

Preciso de WebSocket pra usar o Astra?

Não. WebSocket é exigido só pelo steering (correção no meio do turno). Ferramenta assíncrona e mudança de esforço de raciocínio funcionam pela Responses API normal, por HTTP.

O que acontece se eu mandar temperature pro Astra?

O parâmetro foi descontinuado, junto com top_p, top_logprobs e logprobs. A recomendação oficial é remover das requisições. A Anthropic tomou o mesmo caminho no Fable 5.1, e lá o código antigo que insistiu passou a receber erro 400.

A ferramenta assíncrona funciona com a busca na web da OpenAI?

Não. O modo assíncrono é só pra funções e ferramentas customizadas da sua aplicação. As ferramentas hospedadas pela OpenAI, o modo multiagente com chamadas paralelas e o programmatic tool calling ficam de fora.

Mudar o esforço de raciocínio no meio da conversa invalida o cache?

Não, se você usar o item configuration_update entre respostas e deixar o reasoning.effort da requisição intocado. É justamente pra isso que o recurso existe. Trocar o parâmetro na requisição, como antes, continua invalidando o prefixo.

Vale migrar do GPT-5.6 pro Astra agora?

Vale medir, não vale migrar no escuro. Comece pela Responses API e pela limpeza de parâmetros, rode as duas versões na mesma amostra de tarefas e compare custo por tarefa concluída. Quem tem conversa longa com prefixo estável tende a ganhar; quem faz chamada curta e isolada tende a pagar mais pelo mesmo resultado.