OpenAI Responses API: come migrare a GPT-6 Astra

Le decisioni concrete riguardano il lavoro di sviluppo da mettere in conto per la migrazione e la capacità dei nuovi controlli di ridurre i costi legati ad attese, correzioni e riavvii delle esecuzioni degli agenti.

OpenAI Responses API: che cosa cambia davvero

Prima del lancio, Astra si presentava come un modello di ricerca accessibile solo a porte chiuse. Con il rilascio di settembre arriva un ID pubblico, gpt-6-astra, insieme a prezzi definiti e alla disponibilità sia su Chat Completions sia su Responses. L'accesso parte dalle aziende che aderiscono al Trusted Access Program di OpenAI; nei giorni successivi sarà esteso alle API e a più piani.

La scelta dell'endpoint dipende da ciò che fa l'applicazione. Un'integrazione Chat Completions che elabora soltanto testo può usare Astra. Se invece Astra deve chiamare funzioni proprie o tool ospitati da OpenAI, è obbligatorio usare la Responses API.

Responses introduce un contratto applicativo diverso. Chat Completions riceve un elenco di messaggi e restituisce un elenco di scelte; Responses scambia Item tipizzati. Un messaggio è un Item, una function_call è un altro e il risultato del tool rientra come function_call_output, associato al call_id originale.

La migrazione nasconde due insidie immediate. Le instructions di primo livello non vengono mantenute quando si concatena una richiesta con previous_response_id, quindi vanno inviate di nuovo. Anche Structured Outputs cambia posizione: da response_format passa a text.format. La guida alla migrazione riepiloga tutte le modifiche a parser, stato, tool e streaming.

Perché è importante: ora il budget copre due cambiamenti

La prima voce di budget è il tempo di sviluppo. Un ciclo di tool calling in produzione coinvolge endpoint, schema della richiesta, parser dell'output, definizioni delle funzioni, correlazione dei risultati, gestione dello stato, eventi di streaming, log, retry ed eval. Cambiare soltanto il nome del modello lascia incompiuta quasi tutta la migrazione.

La seconda voce è il costo per job completato. Con contesto breve e piano Standard, GPT-6 Astra costa $10.00 per 1 milione di token di input, $1.00 per l'input in cache, $12.50 per la scrittura in cache e $50.00 per l'output. Le attuali tariffe promozionali di GPT-5.6 Sol sono, sulle stesse quattro voci, $4.00, $0.40, $5.00 e $20.00. A parità di volume di token, Astra costa 2.5 volte tanto in ogni voce.

L'endpoint non comporta un costo separato. La fattura comprende i token del modello, i tool integrati a pagamento, l'infrastruttura dei propri strumenti, i retry e il lavoro abbandonato. Se il prompt supera 272,000 token di input, inoltre, l'intera richiesta Astra passa al doppio delle tariffe per input e cache e a 1.5 volte la tariffa di output. Sono questi i valori da inserire nel budget del progetto pilota, prendendoli dalla pagina dei prezzi attuali.

Un possibile risparmio esiste, ma va dimostrato con dati propri. Nei test interni, OpenAI dichiara per Responses un miglioramento compreso tra 40% e 80% nell'utilizzo della cache rispetto a Chat Completions. Riporta inoltre un costo API stimato per attività più basso per Astra in diverse valutazioni, perché il modello ha usato meno token di output nonostante il prezzo superiore per token. Nessuna delle due affermazioni garantisce un risparmio universale.

La metrica da misurare è invece:

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

Il denominatore fa la differenza. Un'esecuzione meno costosa che deve ripartire dopo una correzione tardiva può incidere più di un'esecuzione più cara che conserva il lavoro utile e arriva al risultato.

Chiamate asincrone API: come cambia il ciclo di attesa

Una normale chiamata di funzione mette in pausa il modello finché l'applicazione non restituisce un risultato. Con Astra, una funzione eseguita dall'applicazione o un custom tool può includere async: true. Il modello può avviare la chiamata e continuare a ragionare, richiamare un altro strumento indipendente oppure rispondere a una parte autonoma della richiesta mentre l'applicazione esegue il job.

Il lavoro resta comunque sotto il controllo del server dell'applicazione. Spetta all'applicazione avviare il job, mantenere un registro, salvare il call_id originale e consegnare il risultato in una richiesta Responses successiva. Se prima del risultato arrivano altri turni, la continuazione deve usare l'ID della risposta più recente, mentre l'output del tool continua a puntare al call ID originale.

In un prodotto di ricerca, una richiesta lenta a un fornitore di dati può procedere mentre Astra organizza le fonti già disponibili. In un agente per le operazioni interne, due verifiche indipendenti sugli account possono partire subito, mentre il modello prepara la parte del report che non dipende da quei dati. Il vantaggio è la riduzione dei tempi morti, non un'esecuzione gratuita.

Lo steering durante il turno cambia il ciclo dei riavvii

Lo steering durante il turno consente all'utente di correggere un job mentre Astra è ancora al lavoro. L'applicazione invia un evento response.steer sullo stesso WebSocket di Responses, indica la risposta attiva tramite previous_response_id e aggiunge la nuova istruzione. Il server completa l'Item di output in corso e tutti i processi dei tool ospitati già avviati, quindi crea una continuazione che incorpora l'aggiornamento.

È utile, per esempio, quando chi coordina un'agenzia si accorge che il report è rivolto al mercato sbagliato, oppure quando un responsabile tecnico deve ridurre l'ambito di un piano di migrazione già in esecuzione. La correzione può arrivare prima che si concluda l'intero turno.

Il lavoro già svolto continua comunque a generare costi. Lo steering non riscrive l'output già consegnato, non annulla un'azione precedente e non interrompe un tool già avviato. I limiti relativi ai token e alle chiamate dei tool si applicano separatamente alla risposta originale e alla continuazione. Il vantaggio economico deriva dalla riduzione dei riavvii completi quando una correzione arriva tardi, ma occorre comunque misurare se il caso si verifica abbastanza spesso da essere rilevante.

Lo steering è disponibile soltanto con Astra e richiede il WebSocket di Responses. Gli aggiornamenti in coda rimangono esclusivamente su quella connessione: l'applicazione deve quindi registrare ogni modifica accettata e gestire con attenzione il ripristino dopo una disconnessione. OpenAI limita una connessione WebSocket a 60 minuti. Per implementazioni WebSocket con 20 o più chiamate ai tool, la guida alla modalità WebSocket indica un'esecuzione end-to-end fino a circa il 40% più veloce; è però un risultato relativo al trasporto, non un risparmio garantito dallo steering.

Migrazione Chat Completions: un percorso operativo

Si parte da un solo flusso di funzioni a basso rischio, non dall'agente più trafficato in produzione.

Installare la versione corrente dell'SDK Python e impostare la variabile d'ambiente come indicato nel quickstart di OpenAI:

pip install openai
export OPENAI_API_KEY="your_api_key_here"

Quello che segue è l'esempio eseguibile di OpenAI per i tool asincroni, con dati meteo dimostrativi. Va eseguito quando il progetto API dispone dell'accesso ad 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)

La riga che rischia di sfuggire è call_id: call.call_id. Il risultato successivo appartiene alla chiamata originale del tool, anche se turni di conversazione più recenti hanno modificato l'ID della risposta più recente.

Quale parte serve a ciascun team

Un team backend che usa già le chiamate di funzione

Prima di adottare Astra per quel percorso, bisogna mettere a budget la migrazione a Responses. Il vantaggio è un passaggio controllato, con log ed eval confrontabili, invece del debug simultaneo di endpoint, parser e modello.

Un agente SaaS che attende servizi lenti

La modalità async va usata solo per attività realmente indipendenti. Una ricerca nel CRM, una ricerca interna o l'esportazione di un documento possono partire mentre Astra gestisce un altro ramo. Una dipendenza che blocca la decisione successiva dovrebbe restare sincrona oppure usare un tool di attesa esplicito.

Un team operativo o un'agenzia che supervisiona lavori lunghi

Lo steering è indicato per le correzioni che altrimenti imporrebbero annullamento e riavvio. Occorre rilevare quanti riavvii evita davvero e quanto lavoro già completato preserva ogni correzione: sono questi dati a costruire il business case, non una demo della funzione.

Un'azienda regolamentata che usa Zero Data Retention

La modalità WebSocket di Responses funziona con store: false e Zero Data Retention, ma la responsabilità dello stato passa all'applicazione. Quando necessario, bisogna conservare gli Item di reasoning cifrati, riprodurre l'intero contesto quando un ID di risposta non è più disponibile e progettare il percorso di ripristino prima di rendere lo steering accessibile agli utenti.

Il punto, senza scorciatoie

L'accesso ad Astra è ancora in fase di estensione. La migrazione può essere preparata subito, ma il passaggio completo in produzione andrebbe rimandato finché il progetto non dispone dell'accesso e non sono concluse valutazioni specifiche sul carico di lavoro.

I tool asincroni richiedono un registro dei job e la gestione di risultati fuori ordine. Lo steering aggiunge lo stato della connessione, la gestione delle continuazioni e il ripristino. Entrambi possono ridurre attese o riavvii sprecati; entrambi introducono altro codice che può guastarsi.

Senza telemetria propria, il vantaggio economico resta aperto. A parità di token, Astra costa 2.5 volte le tariffe promozionali di GPT-5.6 Sol. Una cache più efficiente, meno token di output e meno riavvii potrebbero colmare il divario in alcuni job. Il progetto pilota va protetto da un limite di spesa rigido, quindi Astra va giudicato sul costo per job completato e sul tempo dell'operatore.

Le azioni da avviare lunedì

• Se l'applicazione usa tool calling con Chat Completions e si vuole adottare Astra, questa settimana va mappato un flusso di produzione e finanziato un percorso shadow con Responses.
• Se l'applicazione elabora solo testo, conviene mantenerla stabile mentre l'accesso viene esteso. Per quel percorso non esiste alcuna migrazione obbligatoria dell'endpoint.
• Se i tool lenti assorbono gran parte del tempo trascorso, è il momento di provare una funzione async e misurare tempi morti, errori e costo per job completato.
• Se le correzioni umane tardive causano riavvii, lo steering va prototipato soltanto dopo aver superato i test di riconnessione e replay del WebSocket.
• Se la tariffa per token di Astra, pari a 2.5 volte, compromette l'economia unitaria prima di qualunque risparmio misurato, è meglio mantenere quel carico su GPT-5.6 Sol, Terra o Luna.

Per ricevere anche il prossimo cambiamento di piattaforma tradotto in un flusso operativo e in una scelta di budget, iscriviti alla newsletter.