Programma
Ingegnere AI associato per sviluppatori
26 h
Cos’è l’API GPT-6 Astra?
L’API GPT-6 Astra è il modo per accedere al nuovo modello di punta di OpenAI, rilasciato il 3 settembre 2026, tramite la Responses API. Per questo tutorial, ciò che conta è l’interfaccia: gpt-6-astra accetta input di testo e immagine tramite la Responses API di OpenAI. Il suo sforzo di ragionamento va da low a max, senza opzione none.
Gli esempi in questo tutorial usano client.responses.create invece di client.chat.completions.create, ma la migrazione richiede anche modifiche ai formati di richiesta, output e risultati degli strumenti. Rimuovi anche le impostazioni personalizzate di temperature, top_p e probabilità logaritmiche, poiché Astra non le supporta. Prima di effettuare la prima chiamata, vediamo i prezzi.
Quanto costa GPT-6 Astra?
Per richieste con al massimo 272.000 token in input, il prezzo standard è di 10 $ per milione di token di input ordinari e 50 $ per milione di token di output. L’input in cache costa 1 $ per milione, e le scritture in cache costano 12,50 $ per milione.
Una volta superata la soglia, OpenAI applica un moltiplicatore 2x alle tariffe di input e cache, e 1,5x alla tariffa di output. Le tariffe più alte si applicano all’intera richiesta, non solo ai token oltre soglia. Nessuna delle esecuzioni in questo tutorial si è avvicinata alla soglia.
Cosa costruiremo con l’API GPT-6 Astra?
L’app di staging è una piccola bacheca di task in Flask: una home page, un form per aggiungere un task, un pulsante per segnarlo come completato e un endpoint /health . Il codice completo, app di staging inclusa, è in questo repository GitHub.
Tre task precaricati compaiono prima del test. Immagine dell’autore.
L’app ha un difetto intenzionale. L’agente ha tre controlli, ma solo la test suite è progettata per rilevarli.
Perché l’app accetta titoli di task vuoti?
L’endpoint di creazione del task non rifiuta un titolo vuoto. Ho lasciato quel comportamento in modo che l’agente avesse un errore noto da trovare senza rivelarlo nel prompt.
Quali controlli di release può eseguire l’agente?
L’agente può chiamare tre strumenti:
-
run_test_suiteesegue pytest, incluso un test di import bulk con circa 250 richieste HTTP. -
check_ui_flowusa Playwright per aggiungere un task e confermare che compaia. -
check_staging_healthinvia una richiesta GET a/health.
Tutti e tre girano contro lo staging, senza mock. Il controllo browser usa codice fisso; la demo di computer use scritta dal modello arriva dopo.
Come configurare l’API GPT-6 Astra in Python
Ti serve una chiave API OpenAI con accesso a gpt-6-astra. Crea una chiave su platform.openai.com/api-keys e verifica che il tuo progetto abbia gpt-6-astra abilitato. Nelle workspace Enterprise Astra è disattivata di default al lancio.
I comandi sotto usano Windows PowerShell e installano tutti i pacchetti necessari per questo tutorial, incluso il realtime di OpenAI per la demo di steering.
python -m venv .venv
.venv\Scripts\Activate.ps1
Copy-Item .env.example .env
pip install "openai[realtime]" flask pytest playwright pydantic matplotlib python-dotenv streamlit
playwright install chromiumSu macOS o Linux, sostituisci il comando di attivazione con source .venv/bin/activate e il comando di copia con cp .env.example .env.
Poi aggiungi la chiave API nel nuovo file .env: apri il file .env appena copiato e aggiungi OPENAI_API_KEY=sk-..., che python-dotenv carica e l’SDK rileva automaticamente, così non passi mai la chiave nel codice.
Se dipendenze specifiche di progetto o file .env ti sono nuovi, i nostri guide sull’ambiente virtuale e sulle variabili d’ambiente li spiegano. Verifica che la chiave funzioni prima di costruirci sopra.
Se la tua chiave API funziona già con la Responses API, salta la prossima sottosezione e inizia con il loop sincrono degli strumenti. La prima richiesta serve solo a verificare la configurazione.
Effettua la tua prima chiamata API a GPT-6 Astra
Una volta inserita la chiave, va caricata usando dotenv. Dopo di che, puoi creare un client OpenAI e inviare la tua prima richiesta usando la funzione client.responses.create(). La richiesta più piccola possibile è questa:
from dotenv import load_dotenv
from openai import OpenAI
load_dotenv()
client = OpenAI()
response = client.responses.create(
model="gpt-6-astra",
reasoning={"effort": "low"},
input="In one sentence, what is a staging environment used for?",
)
print(response.output_text)Il campo usage della risposta elenca i conteggi di token necessari per il calcolo dei costi più avanti.
Costruisci un loop di strumenti sincrono con GPT-6 Astra
Gli snippet sotto sono estratti; le versioni eseguibili sono nel relativo repository GitHub.
Prima di toccare l’async, ho costruito la versione ordinaria:
-
Chiama il modello
-
Controlla la presenza di un elemento
function_call -
Esegui lo strumento corrispondente
-
Invia il risultato con
previous_response_id -
Ripeti finché il modello non smette di chiedere strumenti.
Questo loop bloccante è la baseline per il confronto con l’async.
for turn in range(max_turns):
response = client.responses.create(
model="gpt-6-astra",
reasoning={"effort": "low"},
tools=TOOLS,
input=next_input,
previous_response_id=previous_response_id,
)
calls = [item for item in response.output if item.type == "function_call"]
if not calls:
final_text = response.output_text
break
outputs = [
{"type": "function_call_output", "call_id": call.call_id, "output": run_tool(call)}
for call in calls
]
next_input, previous_response_id = outputs, response.idCosa ha trovato l’esecuzione di baseline
Nell’esecuzione di baseline, il modello ha chiamato ogni strumento a turno. Ha trovato il noto errore di validazione e ha restituito una decisione no-go. Su tre esecuzioni, il tempo medio complessivo è stato di 23,40 secondi. Questa media copre l’intera esecuzione, non i tempi dei singoli strumenti.
Come funziona l’async tool calling di GPT-6 Astra?
Contrassegna uno strumento con "async": true nel suo schema, e la tua app può rimandarne il risultato mentre il modello continua a lavorare o attende. La tua applicazione comunque esegue lo strumento e gestisce il job in background.
Come eseguire controlli indipendenti in concorrenza
Ho marcato run_test_suite e check_ui_flow come async, e ho aggiunto uno strumento wait_for_tasks definito dall’app senza argomenti, dato che questa demo ha sempre e solo un batch di lavoro in sospeso alla volta. Quella attesa senza argomenti mantiene l’esempio snello.
In un runner di produzione, identifica i job con handle di task, associa ogni handle al suo call_id originale e attendi solo quando il passo successivo dipende da un risultato in sospeso.
Ritorna ogni risultato completato sul suo call_id originale, poi restituisci lo stato di attesa sul call_id dello strumento di attesa.
TOOLS = [
{"type": "function", "name": "run_test_suite", "async": True, ...},
{"type": "function", "name": "check_ui_flow", "async": True, ...},
{"type": "function", "name": "check_staging_health", ...},
{"type": "function", "name": "wait_for_tasks", ...},
]Per questa esecuzione, l’app ha inviato ogni chiamata marcata a un thread pool. Mentre i controlli in background erano in corso, ha eseguito il veloce controllo sincrono di health. Poi si è bloccata su wait_for_tasks finché i controlli in sospeso non si sono conclusi.
Le chiamate async riducono il tempo di wall-clock?
Su tre esecuzioni, l’async ha ridotto il tempo medio di wall-clock del 19,1%, da 23,40 secondi a 18,94 secondi. La media sembrava lineare finché non sono arrivati i singoli run; il grafico sotto mostra quanto sono in realtà variati. Tre esecuzioni bastano a mostrare cosa è successo qui, non a prevedere la latenza in produzione.
I tempi di esecuzione sono variati in entrambe le modalità. Immagine dell’autore.
Perché i controlli concorrenti hanno causato una race condition?
Eseguire insieme il controllo browser e il test di import bulk a volte causava il fallimento dell’asserzione dell’import bulk perché entrambi i controlli modificavano la stessa lista di task in memoria. Ciò ha infranto l’assunzione del test di accesso esclusivo. Isolare i dati nel runner o nei test eviterebbe la race.
Computer use GPT-6 Astra con limiti per test UI
Per il computer use, la documentazione di GPT-6 Astra raccomanda l’esecuzione di codice, mentre lo strumento strutturato computer resta supportato come alternativa. Con l’esecuzione di codice, una chiamata può combinare più azioni, cicli e logica condizionale, mentre lo strumento computer restituisce una singola azione strutturata di mouse o tastiera alla volta che la tua applicazione traduce e riproduce.
Come limitare il runner di computer-use
Ho chiamato la classe BrowserSandbox, ma il nome enfatizza troppo la protezione. Fornisce al codice scritto dal modello una page di Playwright, una funzione log() e un helper expect_text() . Python può comunque iniettare built-in in exec(), e la pagina può navigare verso un’altra origin.
sandbox_globals = {"page": self.page, "log": log, "expect_text": expect_text}
exec(code, sandbox_globals)Consideralo un runner demo, non un confine di sicurezza. Il codice scritto dal modello necessita di un processo o container isolato con restrizioni su filesystem, processi, rete e origin.
Cosa è successo nel controllo UI?
Ho impostato un massimo di otto turni perché un controllo con limiti ha bisogno di uno stop rigido. Il modello ha ispezionato la pagina, trovato l’input del form, creato il titolo "UI flow check, cobalt otter 73921", inviato il task e confermato che il titolo apparisse, il tutto in 13 secondi. Il nostro tutorial su computer use con GPT-5.4 copre un esempio dettagliato con un modello predecessore di Astra.
Come funziona lo steering a metà turno di GPT-6 Astra?
Lo steering a metà turno è disponibile solo per gpt-6-astra su connessione WebSocket.
Apri una connessione e crea una risposta, poi invia un evento response.steer con nuove istruzioni mentre la risposta è in generazione. Un evento response.steer.accepted significa che l’aggiornamento è in coda, non applicato. Prima di creare la continuazione automatica, il server termina l’output corrente e qualsiasi lavoro di strumenti hosted già in corso.
Se serve ancora il risultato di uno strumento client o un’approvazione, response.steer.pending identifica l’input mancante.
async with client.responses.connect() as connection:
await connection.response.create(model="gpt-6-astra", input=TASK)
async for event in connection:
if event.type == "response.created" and initial_response_id is None:
initial_response_id = event.response.id
await asyncio.sleep(1.0)
await connection.response.steer(
previous_response_id=initial_response_id,
input="Also add a rollback plan, but skip mobile.",
)Il ritardo di un secondo replica il codice dell’esperimento e dà tempo alla prima risposta di iniziare. Senza quel ritardo, si testerebbe un punto diverso del ciclo di vita della risposta.
Cosa lascia invariato lo steering a metà turno?
Lo steering non riscrive la risposta originale. Se l’aggiornamento la interrompe, quella risposta termina con status: "incomplete" e incomplete_details.reason: "steered". Una risposta successiva continua con la nuova istruzione.
Se la prima risposta finisce prima che l’aggiornamento abbia effetto, rimane completata. Lo steering non annulla o inverte azioni lato client già avviate; quel comportamento resta di competenza della tua applicazione. Lo steering in coda esiste solo sulla connessione WebSocket corrente, quindi registra l’aggiornamento prima di tentare una riconnessione.
Il percorso di confronto lascia terminare la prima risposta, poi invia una nuova richiesta con le istruzioni combinate. Su due esecuzioni, lo steering ha avuto una media di 26,91 secondi contro 50,02 secondi per quel percorso finish-then-restart. Questo confronto non copre una politica cancel-and-restart né valuta la correttezza del testo finale.
Medie su due esecuzioni per tempo e costo. Immagine dell’autore.
Il percorso di restart genera due risposte complete che coprono alcune delle stesse richieste. Questo setup spiega parte del divario temporale, quindi non tratterei queste due esecuzioni come benchmark generali per lo steering.
Come cambiare lo sforzo di ragionamento di GPT-6 Astra a conversazione in corso
gpt-6-astra supporta uno sforzo di ragionamento da low a max. Uno sforzo maggiore può aumentare l’uso di token di ragionamento, ma non garantisce una risposta diversa. Un configuration_update cambia la risposta successiva e le seguenti finché un altro aggiornamento non lo sovrascrive, mentre l’impostazione a livello di richiesta resta invariata.
In questa pipeline, il report chiude la conversazione, quindi l’aggiornamento incide solo su quell’ultimo passo.
response = client.responses.create(
model="gpt-6-astra",
previous_response_id=previous_id,
reasoning={"effort": "low"}, # default remains low
input=[
{"type": "configuration_update", "reasoning": {"effort": "high"}},
{"role": "user", "content": "Diagnose the root cause and recommend a fix."},
],
)Ho usato la stessa traccia di errore a entrambi i livelli di sforzo e confrontato diagnosi e uso dei token.
Una sottigliezza: il campo reasoning.effort della risposta riporta comunque l’impostazione a livello di richiesta, non lo sforzo selezionato da configuration_update. Non usare quel campo per verificare se l’aggiornamento è entrato in vigore.
Uno sforzo di ragionamento alto ha cambiato la diagnosi?
Nell’esecuzione combinata completa, il passo con escalation ha usato 108 token di ragionamento. Ogni altro passo a low ne ha usati zero. In un test isolato precedente con una traccia di errore più lunga, low ha usato zero token di ragionamento e high ne ha usati 318. Entrambe le versioni hanno identificato il bug di validazione, quindi un cambio a sforzo maggiore ha modificato l’uso dei token ma non la diagnosi.
Gli aggiornamenti di configurazione funzionano solo in richieste standard a singolo agente. L’API rifiuta aggiornamenti adiacenti e non possono essere combinati con compattazione o troncamento automatici.
Come usare gli output strutturati di GPT-6 Astra
L’ultimo passo della pipeline chiama client.responses.parse per sostituire il testo libero con un modello Pydantic validato.
class GoNoGoReport(BaseModel):
decision: str
summary: str
checks_completed: list[str]
failures: list[str]
risks: list[str]
follow_up_actions: list[str]
confidence: float
response = client.responses.parse(
model="gpt-6-astra",
previous_response_id=previous_id,
text_format=GoNoGoReport,
input=[...],
)Pydantic verifica i tipi dei campi dichiarati qui. Non dimostra che il report corrisponda alle evidenze, e questa versione non limita decision a due valori né confidence a un intervallo.
Cosa ha rilevato il report go/no-go?
Il report ha restituito decision: "no_go". Ha classificato il fallimento di validazione citato prima sotto failures e il problema di concorrenza sotto risks. Per quest’ultimo, ha scritto: "possibile interferenza da controlli UI concorrenti su dati di staging condivisi." Il prompt non nominava quel rischio.
Mantieni latenza e costo fuori da questo schema e calcolali in codice. Il modello compila i campi del report dalle evidenze degli strumenti.
L’interfaccia Streamlit consuma lo stesso generatore del runner da riga di comando. Renderizza ogni evento di strumento man mano che arriva, poi mostra il report parsato nelle tab Report e JSON.
