Responses API: por que o GPT-6 Astra exige uma migração de verdade

Na prática, é preciso decidir quanto trabalho de engenharia entra nessa migração e se os novos controles podem reduzir o custo de esperar, corrigir e reiniciar execuções de agentes.

O que mudou na Responses API

Antes do lançamento, o cenário do Astra em pré-lançamento era o de um modelo de pesquisa mantido sob acesso restrito. A versão de setembro lhe dá um ID público, gpt-6-astra, define seus preços e o disponibiliza tanto no Chat Completions quanto no Responses. O acesso começa pelas empresas do Trusted Access Program da OpenAI; o acesso à API e a planos mais amplos será liberado nos próximos dias.

A escolha do endpoint depende do que a aplicação faz. Uma integração de Chat Completions dedicada apenas a texto pode usar o Astra. Já uma integração que permite ao Astra chamar funções próprias ou ferramentas hospedadas pela OpenAI precisa usar a Responses API.

Responses estabelece outro contrato com a aplicação. No Chat Completions, entra uma lista de mensagens e sai uma lista de escolhas. Em Responses, o fluxo é feito com Items tipados: uma mensagem é um Item, uma function_call é outro, e o resultado da ferramenta volta como uma function_call_output que carrega o call_id original.

Há duas armadilhas fáceis de encontrar na migração. As instructions no nível superior não são mantidas quando a cadeia usa previous_response_id; por isso, envie-as novamente. Structured Outputs também sai de response_format e passa para text.format. O guia de migração reúne todas as mudanças de parser, estado, ferramentas e streaming.

Por que isso importa: agora o orçamento cobre duas mudanças

A primeira conta é o tempo de engenharia. Um loop de ferramentas em produção envolve endpoint, esquema da requisição, parser da saída, definições de funções, correlação de resultados, gestão de estado, eventos de streaming, logs, novas tentativas e evals. Trocar apenas o nome do modelo deixa quase todo esse trabalho por fazer.

A segunda conta é o custo por tarefa concluída. Nas tarifas Standard de contexto curto, o GPT-6 Astra custa $10.00 por 1 milhão de tokens de entrada, $1.00 para entrada em cache, $12.50 para gravações no cache e $50.00 para saída. As tarifas promocionais atuais do GPT-5.6 Sol são $4.00, $0.40, $5.00 e $20.00 nas mesmas quatro linhas. Com o mesmo volume de tokens, o Astra custa 2.5 vezes mais em cada uma delas.

O endpoint não tem uma tarifa separada. A fatura vem dos tokens do modelo, das ferramentas integradas cobradas, da sua própria infraestrutura de ferramentas, das novas tentativas e do trabalho abandonado. Prompts com mais de 272,000 tokens de entrada também levam a requisição inteira do Astra ao dobro das tarifas de entrada e cache e multiplicam a tarifa de saída por 1.5. São esses os números que devem entrar no orçamento do piloto, conforme a página de preços atual.

Existe uma possível compensação, mas ela precisa ser comprovada com os seus dados. A OpenAI relata uma utilização de cache de 40% a 80% melhor no Responses do que no Chat Completions em testes internos. Também informa um custo estimado menor por tarefa na API do Astra em várias avaliações porque o modelo usou menos tokens de saída, apesar do preço mais alto por token. Nenhuma das duas afirmações garante economia para todo tipo de uso.

Meça isto:

cost per completed job = model tokens + built-in tool fees + your tool costs + retries + operator time

O denominador faz diferença. Uma execução mais barata que precisa recomeçar depois de uma correção tardia pode sair mais cara por resultado finalizado do que outra, mais cara, que preserva o trabalho útil.

Chamadas assíncronas mudam o ciclo de espera

Uma chamada de função normal pausa o modelo até a aplicação devolver um resultado. Com o Astra, uma função ou custom tool executada pela aplicação pode receber async: true. O modelo pode disparar a chamada, continuar raciocinando, acionar outra ferramenta independente ou responder a uma parte autônoma da solicitação enquanto a aplicação executa o job.

O trabalho continua sob responsabilidade do seu servidor. Ele precisa iniciar o job, manter um registro, guardar o call_id original e entregar o resultado em uma requisição posterior do Responses. Se houver outros turnos antes da chegada desse resultado, a continuação deve usar o ID da resposta mais recente, enquanto a saída da ferramenta continua apontando para o ID da chamada original.

Em um produto de pesquisa, isso permite executar uma solicitação lenta a um provedor de dados enquanto o Astra organiza as fontes já disponíveis. Em um agente de operações internas, duas consultas independentes a contas podem começar logo no início, enquanto o modelo redige a parte do relatório que não depende delas. O ganho está em reduzir o tempo ocioso, não em obter execução gratuita.

Steering durante o turno muda o ciclo de reinício

O steering durante o turno permite que o usuário corrija uma tarefa enquanto o Astra ainda trabalha. A aplicação envia um evento response.steer pelo mesmo WebSocket do Responses, aponta para a resposta ativa com previous_response_id e fornece a nova instrução. O servidor conclui o Item de saída atual e qualquer trabalho de ferramenta hospedada que já esteja em andamento; depois, cria uma continuação com a atualização.

Isso ajuda, por exemplo, quando alguém em uma agência percebe que o relatório está voltado ao mercado errado ou quando uma liderança de engenharia precisa reduzir o escopo de um plano de migração ainda em execução. A correção pode entrar antes que o turno inteiro termine.

O trabalho já consumido continua consumido. O steering não reescreve uma saída já entregue, não desfaz uma ação anterior nem cancela uma ferramenta que já começou. Os limites de tokens e chamadas de ferramentas são aplicados separadamente à resposta original e à continuação. O argumento de negócio é evitar reinícios completos quando a correção chega tarde; ainda assim, é preciso medir se isso acontece com frequência suficiente para compensar.

O steering é exclusivo do Astra e exige o WebSocket do Responses. As correções na fila existem somente naquela conexão, então a aplicação precisa registrar cada atualização aceita e se recuperar com cuidado depois de uma desconexão. A OpenAI limita cada conexão WebSocket a 60 minutos. Em implantações por WebSocket com 20 ou mais chamadas de ferramentas, o guia do modo WebSocket relata execução de ponta a ponta até aproximadamente 40% mais rápida; esse, porém, é um resultado do transporte, não uma economia prometida pelo steering.

Um roteiro de migração que você pode executar

Comece por um fluxo de funções de baixo risco. Não escolha o agente mais movimentado da produção como ponto de partida.

Instale a versão atual do SDK para Python e defina a variável de ambiente como mostra o quickstart da OpenAI:

pip install openai
export OPENAI_API_KEY="your_api_key_here"

Este é o exemplo executável de ferramenta assíncrona da OpenAI, com dados meteorológicos de demonstração. Execute-o quando o seu projeto de API tiver acesso ao Astra:

import json
from concurrent.futures import ThreadPoolExecutor

from openai import OpenAI
from openai.types.responses import FunctionToolParam

def get_weather(city):
    # Demo data. Replace this function with your weather service.
    weather = {
        "Paris": {
            "city": "Paris",
            "temperature_c": 22,
            "condition": "Clear",
            "source": "demo weather snapshot",
        }
    }
    return weather[city]

worker = ThreadPoolExecutor()

def main():
    client = OpenAI()
    model = "gpt-6-astra"
    tools: list[FunctionToolParam] = [
        {
            "type": "function",
            "name": "get_weather",
            "description": "Read the demo weather snapshot for a city.",
            "async": True,
            "strict": True,
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
                "additionalProperties": False,
            },
        },
    ]

    instructions = (
        "Start the weather lookup and answer the independent packing "
        "question without waiting. Use the actual tool result when it "
        "arrives; never invent it. Identify the weather as demo data."
    )
    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        input=(
            "Check the demo weather in Paris. Meanwhile, "
            "list three essentials for any city trip."
        ),
    )

    call = next(item for item in response.output if item.type == "function_call")
    arguments = json.loads(call.arguments)
    if call.name != "get_weather" or arguments != {"city": "Paris"}:
        raise ValueError("Expected a weather lookup for Paris")

    latest_response_id = response.id
    if call.async_:
        job = worker.submit(get_weather, **arguments)
        print(response.output_text)
        # Independent work or conversation turns can happen here.
        # Update latest_response_id after each continuation.
        result = job.result()
    else:
        result = get_weather(**arguments)

    response = client.responses.create(
        model=model,
        tools=tools,
        instructions=instructions,
        previous_response_id=latest_response_id,
        input=[
            {
                "type": "function_call_output",
                "call_id": call.call_id,
                "output": json.dumps(result),
            },
        ],
    )
    print(response.output_text)

if __name__ == "__main__":
    try:
        main()
    finally:
        worker.shutdown(wait=True)

A linha que muita gente deixará passar é call_id: call.call_id. O resultado posterior pertence à chamada de ferramenta original, mesmo que turnos mais recentes da conversa tenham alterado o ID da resposta mais recente.

Para qual equipe serve cada recurso

Uma equipe de backend que já chama funções

Inclua a migração para Responses no orçamento antes de adotar o Astra nesse caminho. O benefício é uma transição controlada, com logs e evals comparáveis, em vez de depurar ao mesmo tempo uma mudança de endpoint, parser e modelo.

Um agente SaaS que espera por serviços lentos

Use o modo assíncrono apenas em trabalhos realmente independentes. Uma consulta ao CRM, uma busca interna ou a exportação de um documento pode começar enquanto o Astra cuida de outro ramo. Uma dependência que bloqueia a próxima decisão deve continuar síncrona ou usar uma ferramenta explícita de espera.

Uma equipe de operações ou agência que supervisiona tarefas longas

Disponibilize o steering para correções que, sem ele, exigiriam cancelar e recomeçar. Acompanhe quantos reinícios ele realmente evita e quanto trabalho concluído cada correção preserva. Assim, você terá um caso de negócio, não apenas uma demonstração do recurso.

Uma empresa regulada que usa Zero Data Retention

O modo WebSocket do Responses funciona com store: false e Zero Data Retention, mas a responsabilidade pelo estado passa a ser sua. Preserve Items de raciocínio criptografados quando necessário, repita o contexto completo quando um ID de resposta não estiver mais disponível e projete esse caminho de recuperação antes de liberar o steering aos usuários.

Sem maquiagem: os limites

O acesso ao Astra ainda está em processo de liberação. A migração pode ser preparada agora, mas a troca completa em produção deve esperar o acesso do projeto e evals específicos para a carga de trabalho.

Ferramentas assíncronas acrescentam um registro de jobs e resultados fora de ordem. O steering adiciona estado de conexão, gestão de continuações e recuperação. Os dois podem reduzir o desperdício causado por esperas ou reinícios, e os dois adicionam código sujeito a falhas.

A conta de preço continuará em aberto até que exista telemetria própria. Para o mesmo volume de tokens, o custo do Astra é 2.5 vezes maior que as tarifas promocionais do GPT-5.6 Sol. Cache mais eficiente, menos tokens de saída e menos reinícios podem fechar essa diferença em algumas tarefas. Coloque o piloto atrás de um limite rígido de gastos e avalie o Astra pelo custo da tarefa concluída e pelo tempo do operador.

O que fazer na segunda-feira

• Se a sua aplicação usa chamadas de ferramentas no Chat Completions e você quer adotar o Astra, mapeie um fluxo de produção e financie uma rota espelho no Responses ainda esta semana.
• Se a aplicação trabalha apenas com texto, mantenha-a estável enquanto o acesso é liberado. Não há migração obrigatória de endpoint nesse caminho.
• Se ferramentas lentas concentram a maior parte do tempo total, teste uma função assíncrona e meça o tempo ocioso, as falhas e o custo por tarefa concluída.
• Se correções humanas tardias provocam reinícios, crie um protótipo de steering somente depois que os testes de reconexão e replay do WebSocket passarem.
• Se pagar 2.5 vezes mais pelos tokens do Astra inviabiliza a economia unitária antes de qualquer compensação comprovada, mantenha essa carga de trabalho no GPT-5.6 Sol, Terra ou Luna.

Para receber a próxima mudança de plataforma transformada em decisões práticas de workflow e orçamento, assine a newsletter.