GPT-6 Astra API-handledning: Bygg en releasekontroll-agent med asynkrona verktyg och styrning

Vad är GPT-6 Astra API?

GPT-6 Astra API är sättet att komma åt OpenAI:s nya flaggskeppsmodell, släppt den 3 september 2026, via Responses API. För den här handledningen är ytan det viktiga: gpt-6-astra tar emot text- och bildinmatningar via OpenAI:s Responses API. Dess resonemangsinsats sträcker sig från low till max, utan något none-alternativ. 

Exemplen i denna handledning använder client.responses.create i stället för client.chat.completions.create, men migreringen kräver också ändringar i format för begäran, utdata och verktygsresultat. Ta även bort anpassade inställningar för temperature, top_p och loggsannolikheter, eftersom Astra inte stöder dem. Innan vi gör det första anropet tittar vi på prissättningen.

Hur mycket kostar GPT-6 Astra?

För begäranden med högst 272 000 indatatoken är standardpriset 10 USD per miljon vanliga indatatoken och 50 USD per miljon utdata-token. Cachad indata kostar 1 USD per miljon, och cacheskrivningar kostar 12,50 USD per miljon. 

När en begäran överskrider den tröskeln tillämpar OpenAI en 2x-multiplikator på indata- och cacheraterna och en 1,5x-multiplikator på utdata-raten. De högre raterna gäller för hela begäran, inte bara tokenen över tröskeln. Ingen av körningarna i den här handledningen kom i närheten av tröskeln.

Vad ska vi bygga med GPT-6 Astra API?

Stagingappen är en liten Flask-uppgiftstavla: en startsida, ett formulär för att lägga till en uppgift, en knapp för att markera en som klar och ett /health endpoint. Komplett kod, inklusive stagingapp, finns i detta GitHub-repo.

Tre förifyllda uppgifter visas före testning. Bild av författaren.

Appen har en avsiktlig brist. Agenten har tre kontroller, men bara testsviten är utformad för att fånga dem.

Varför accepterar appen tomma uppgiftstitlar?

Endpointen för att skapa uppgifter avvisar inte en tom titel. Jag lät det beteendet vara kvar så att agenten har ett känt fel att hitta utan att det avslöjas i prompten.

Vilka releasekontroller kan agenten köra?

Agenten kan anropa tre verktyg:

• run_test_suite kör pytest, inklusive ett bulkimporttest med runt 250 HTTP-förfrågningar. 

• check_ui_flow använder Playwright för att lägga till en uppgift och bekräfta att den visas. 

• check_staging_health skickar en GET-förfrågan till /health. 

Alla tre körs mot staging, utan mocks. Webbläsarkontrollen använder fast kod; demo för modellförfattad datoranvändning kommer senare.

Så här sätter du upp GPT-6 Astra API i Python

Du behöver en OpenAI API-nyckel med åtkomst till gpt-6-astra. Skapa en nyckel på platform.openai.com/api-keys, och kontrollera att ditt projekt har gpt-6-astra aktiverat. Enterprise-arbetsytor har Astra avstängt som standard vid lansering.

Kommandona nedan använder Windows PowerShell och installerar alla paket som behövs för denna handledning, inklusive OpenAI:s realtime för styrningsdemot.

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 chromium

På macOS eller Linux, ersätt aktiveringskommandot med source .venv/bin/activate och kopieringskommandot med cp .env.example .env. 

Lägg sedan till API-nyckeln i den nya .env-filen: Öppna .env-filen du just kopierade och lägg till OPENAI_API_KEY=sk-..., som python-dotenv laddar och som SDK:n plockar upp automatiskt, så du aldrig skickar nyckeln i kod.

Om projektspecifika beroenden eller .env-filer är nya för dig, finns förklaringar i våra guider för virtuella miljöer och miljövariabler. Bekräfta att nyckeln fungerar innan du bygger vidare på den.

Om din API-nyckel redan fungerar med Responses API, hoppa över nästa delavsnitt och börja med den synkrona verktygsslingan. Den första begäran verifierar bara uppsättningen.

Gör ditt första GPT-6 Astra API-anrop

När nyckeln är på plats behöver den läsas in med dotenv. Därefter kan du skapa en OpenAI-klient och skicka din första begäran med funktionen client.responses.create(). Den minsta möjliga begäran ser ut så här:

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)

Svarets usage fält listar antalet token som behövs för den senare kostnadsberäkningen.

Bygg en synkron GPT-6 Astra-verktygsslinga

Kodsnuttarna nedan är utdrag; körbara versioner finns i det tillhörande GitHub-repot.

Innan jag rörde något asynkront byggde jag den vanliga versionen: 

1. Anropa modellen

2. Kontrollera efter ett function_call-objekt

3. Kör motsvarande verktyg

4. Skicka tillbaka resultatet med previous_response_id

5. Upprepa tills modellen slutar be om verktyg. 

Denna blockerande slinga är baslinjen för jämförelsen med 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.id

Vad baslinjekörningen hittade

I baslinjekörningen anropade modellen varje verktyg i tur och ordning. Den hittade det kända valideringsfelet och returnerade ett no-go-beslut. Över tre körningar var genomsnittlig väggklocktid 23,40 sekunder. Det genomsnittet täcker hela körningen, inte enskilda verktygstider.

Hur fungerar GPT-6 Astras asynkrona verktygsanrop?

Markera ett verktyg med "async": true i dess schema, så kan din app skjuta upp det resultatet medan modellen antingen fortsätter arbeta eller väntar. Din applikation kör fortfarande verktyget och hanterar bakgrundsjobbet.

Så här kör du oberoende kontroller samtidigt

Jag markerade run_test_suite och check_ui_flow som asynkrona och lade till ett appdefinierat wait_for_tasks-verktyg utan argument, eftersom denna demo bara har en omgång väntande arbete åt gången. Denna väntan utan argument håller exemplet litet. 

I en produktions-körare identifierar du jobb med uppgiftshandtag, binder varje handtag till dess ursprungliga call_id och väntar bara när nästa steg beror på ett väntande resultat.

Returnera varje slutfört resultat på dess ursprungliga call_id, returnera sedan väntestatus på väntverktygets eget call_id.

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", ...},
]

För denna körning skickade appen in varje markerat anrop till en trådpool. Medan bakgrundskontrollerna kördes utförde den den snabba synkrona hälsokontrollen. Den blockerade sedan vid wait_for_tasks tills de väntande kontrollerna var klara.

Minskar asynkrona verktygsanrop väggklocktiden?

Över tre körningar minskade async den genomsnittliga väggklocktiden med 19,1 %, från 23,40 sekunder till 18,94 sekunder. Genomsnittet såg okomplicerat ut tills de enskilda körningarna kom in; diagrammet nedan visar hur mycket de faktiskt varierade. Tre körningar räcker för att visa vad som hände här, inte för att förutsäga latens i produktion.

Körtiderna varierade i båda lägen. Bild av författaren.

Varför orsakade samtidiga kontroller ett racetillstånd?

Att köra webbläsarkontrollen och bulkimporttestet samtidigt fick ibland bulkimport-assertionen att fallera eftersom båda kontrollerna ändrade samma uppgiftslista i minnet. Det bröt testets antagande om exklusiv åtkomst. Att isolera data antingen i köraren eller i testen skulle undvika racet.

Avgränsad GPT-6 Astra-datoranvändning för UI-testning

För datoranvändning rekommenderar GPT-6 Astras dokumentation kodexekvering, medan det strukturerade computer-verktyget fortfarande stöds som alternativ. Med kodexekvering kan ett anrop kombinera flera åtgärder, loopar och villkorslogik, medan computer-verktyget returnerar en strukturerad mus- eller tangentbordsåtgärd i taget som din applikation översätter och spelar upp.

Hur begränsar man köraren för datoranvändning

Jag kallade klassen BrowserSandbox, men det namnet överdriver dess skydd. Den ger modellförfattad kod en Playwright-page, en log()-funktion och en expect_text() hjälpare. Python kan fortfarande injicera built-ins i exec(), och sidan kan navigera till en annan origin.

sandbox_globals = {"page": self.page, "log": log, "expect_text": expect_text}
exec(code, sandbox_globals)

Behandla detta som en demokörare, inte en säkerhetsgräns. Modellförfattad kod behöver en isolerad process eller container med begränsningar för filsystem, processer, nätverk och origin.

Vad hände i UI-kontrollen?

Jag satte ett tak på åtta vändor eftersom en avgränsad kontroll behöver ett tydligt stopp. Modellen inspekterade sidan, hittade formulärfältet, skapade titeln "UI flow check, cobalt otter 73921", skickade uppgiften och bekräftade att titeln dök upp, vilket tog 13 sekunder. Vår handledning för datoranvändning i GPT-5.4 täcker ett detaljerat exempel med en föregångarmodell till Astra.

Hur fungerar GPT-6 Astras styrning mitt i en vändning?

Styrning mitt i en vändning är endast tillgänglig för gpt-6-astra över en WebSocket-anslutning.

Öppna en anslutning och skapa ett svar, skicka sedan en response.steer-händelse med nya instruktioner medan svaret genereras. En response.steer.accepted-händelse betyder att uppdateringen är köad, inte tillämpad. Innan den automatiska fortsättningen skapas avslutar servern det aktuella utdataobjektet och allt värdat verktygsarbete som redan körs. 

Om den fortfarande behöver ett klientverktygsresultat eller ett godkännande identifierar response.steer.pending den saknade inmatningen.

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.",
            )

Fördröjningen på en sekund matchar experimentkoden och ger första svaret tid att starta. Utan den fördröjningen skulle detta testa en annan punkt i svarslivscykeln.

Vad lämnar styrning mitt i en vändning oförändrat?

Styrning skriver inte om det ursprungliga svaret. Om uppdateringen avbryter det slutar det svaret med status: "incomplete" och incomplete_details.reason: "steered". En efterföljande respons fortsätter sedan med den nya instruktionen. 

Om det första svaret blir klart innan uppdateringen börjar gälla förblir det slutfört. Styrning återkallar eller avbryter inte klientsideåtgärder som redan har startat; din applikation äger fortfarande det beteendet. Köad styrning finns bara på den aktuella WebSocket-anslutningen, så registrera uppdateringen innan du försöker återskapa anslutningen.

Jämförelsevägen låter det första svaret bli klart och skickar sedan en ny begäran med de kombinerade instruktionerna. Över två körningar blev genomsnittet 26,91 sekunder för styrning jämfört med 50,02 sekunder för vägen avsluta-och-starta-om. Denna jämförelse täcker inte en avbryt-och-starta-om-policy eller poängsätter den slutliga texten för korrekthet.

Genomsnitt över två körningar för tid och kostnad. Bild av författaren.

Vägen med omstart genererar två kompletta svar som täcker vissa av samma förfrågningar. Den uppsättningen förklarar delvis tidsskillnaden, så jag skulle inte betrakta dessa två körningar som ett allmänt riktmärke för styrning.

Så här ändrar du GPT-6 Astras resonemangsinsats mitt i en konversation

gpt-6-astra stöder resonemangsinsats från low till max. Högre insats kan öka användningen av resonemangstoken, men garanterar inte ett annat svar. En configuration_update ändrar nästa och senare svar tills en annan uppdatering åsidosätter den, medan inställningen på begärandenivå förblir oförändrad. 

I denna pipeline avslutar rapporten konversationen, så uppdateringen påverkar bara det sista steget.

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."},
    ],
)

Jag använde samma felspårning på båda insatsnivåerna och jämförde diagnos och tokenanvändning.

En subtilitet: svarets reasoning.effort fält rapporterar fortfarande inställningen på begärandenivå, inte den insats som valts av configuration_update. Använd inte det fältet för att kontrollera om uppdateringen trädde i kraft.

Ändrade hög resonemangsinsats diagnosen?

I den fullständiga kombinerade körningen använde det eskalerade steget 108 resonemangstoken. Varje annat steg på low använde noll. I ett tidigare isolerat test med en längre felspårning använde låg insats noll resonemangstoken och hög insats 318. Båda versionerna identifierade valideringsbuggen, så en förändring till högre insats påverkade tokenanvändningen men inte diagnosen.

Konfigurationsuppdateringar fungerar bara i standardförfrågningar med en enda agent. API:t avvisar intilliggande uppdateringar, och de kan inte kombineras med automatisk komprimering eller automatisk trunkering.

Så här använder du GPT-6 Astras strukturerade utdata

Pipelines sista steg anropar client.responses.parse för att ersätta fritext med en validerad Pydantic-modell.

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 kontrollerar fälttyperna som deklareras här. Det bevisar inte att rapporten matchar bevisen, och den här versionen begränsar inte decision till två värden eller confidence till ett intervall.

Vad fångade go/no-go-rapporten?

Rapporten returnerade decision: "no_go". Den klassificerade valideringsfelet som nämndes tidigare under failures och samtidighetsproblemet under risks. För det senare skrev den: "möjlig påverkan från samtidiga UI-kontroller mot delad stagingdata." Prompten namngav inte den risken.

Håll latens och kostnad utanför detta schema och beräkna dem i kod. Modellen fyller rapportfälten utifrån bevis från verktygen.

Gränssnittet i Streamlit konsumerar samma generator som kommandoradsköraren. Det renderar varje verktygshändelse när den anländer och visar sedan den parsade rapporten i flikarna Report och JSON.

Agentens liveförlopp bredvid slutrapporten. Video av författaren.

Instrumentpanelen kör den kombinerade asynkrona releasepipeline med dess fasta webbläsarkontroll, resonemangsuppdatering, strukturerade rapport och tidsvisning. Dess kostnadspanel läser samma huvudbok som kommandoradsköraren. Den kör inte de separata demona för modellförfattad datoranvändning eller styrning.

Så här spårar du GPT-6 Astra API-tokenanvändning och kostnad

För modelltoken-delen av dessa körningar innehåller usage-fältet de fyra tokenräkningarna som behövs för att prissätta varje svar. Cache-skrivningar har egen taxa, så gruppera dem inte med vanlig indata. Verktygen här körs i din applikation; om du lägger till ett värdat verktyg med separat avgift, ta med den kostnaden också.

details = usage.input_tokens_details
cached_tokens = details.cached_tokens
cache_write_tokens = details.cache_write_tokens
ordinary_tokens = usage.input_tokens - cached_tokens - cache_write_tokens

cost = (
    ordinary_tokens * PRICE_INPUT
    + cached_tokens * PRICE_CACHED_INPUT
    + cache_write_tokens * PRICE_CACHE_WRITE
    + usage.output_tokens * PRICE_OUTPUT
) / 1_000_000

Denna beräkning täcker ett svar. Huvudboken tillämpar den efter varje svar och adderar sedan anropssummorna.

Logga cache_write_tokens även när värdet är noll. Annars kan en framtida cacheskrivning gömma sig i den vanliga indataräkningen, och det är ett irriterande sätt att upptäcka ett faktureringsfel.

Produktionsaspekter för GPT-6 Astra-agenten

Demon behöver dessa ändringar innan den kan granska och stoppa driftsättningar.

Verktygsbehörigheter och isolering

Behåll staginggränsen och isolera BrowserSandbox som beskrivet ovan. Ge den inte databasuppgifter eller produktionsåtkomst.

Livscykel för asynkrona jobb

I demon blir varje väntande jobb klart, och inget annat rör det. En driftsatt körare måste överleva fallen där inget av det är sant. Den behöver, för varje väntande post:

• En tidsgräns och en slutstatus, så att inget blir väntande för alltid
• En leveransflagga, så att en callback och en retry inte kan skicka samma resultat två gånger
• Start- och sluttidsstämplar, för att kunna skilja en timeout från en sen men giltig slutföring
• Avvisning av dubblettanrop, så att samma uppgift inte kan startas två gånger
• Felmappning för bakgrundstråd, så att ett kastat undantag synliggörs i stället för att försvinna i poolen
• Avbrytning, vilket betyder att ignorera ett sent resultat och stoppa externt arbete som redan pågår

Styrning och irreversibla åtgärder

En styrning kan ändra framtida instruktioner, men den kan inte backa en slutförd sidoeffekt. Om ett verktyg redan har ändrat ett externt system måste en separat verktygåtgärd kompensera för det.

Övervakning av missanpassning

Automatisk stoppning gäller för Responses API-begäranden som använder bestående resonemang, WebSockets eller OpenAI-komprimering. Andra begäranden kan utlösa varningar, men stoppas inte automatiskt. 

Före strömning kan övervakning av missanpassning blockera en täckt körning med HTTP 403 och koden misalignment_policy_violation. En strömmande klient kan i stället få ett fel efter att utdata har börjat. API:t erbjuder ingen allmän återupptagningsväg för den stoppade konversationen.

Checklista för driftsättning av GPT-6 Astra-agent

Innan du flyttar denna agent från lokal demo till driftsättning, lägg till dessa kontroller. De hör hemma i applikationskoden snarare än i modellinstruktionerna.

• Sätt explicita timeouter på stagingappens HTTP-anrop och WebSocket-anslutningen

• Logga vanlig indata, cachad indata, cache-skrivningar, utdata, svar-ID och antal vändor

• Varna för ofullständiga körningar eller körningar som träffar vändningstaket. Sätt en separat varning för budgetöverskridanden

• Frys versionen av openai-SDK och kontrollera om asynk, styrning och configuration_update-beteende igen före uppgradering

När ska du använda GPT-6 Astras asynkrona verktyg eller styrning?

Välj den enklaste vägen som passar uppgiften.

• Börja med en synkron begäran och strukturerade utdata när verktyg returnerar snabbt och kraven förblir fasta.
• Lägg till asynkrona verktygsanrop när modellen eller ett annat verktyg kan göra nyttigt arbete under ett långsamt anrop, och den sparade tiden motiverar extra jobbhantering.
• Använd styrning mitt i en vändning när kraven ändras under en körning.

Avslutande tankar

Den synkrona releasekontrollen blev mer användbar när långsamma verktyg kunde överlappa, även om resultatet inte var en solklar seger. Över tre körningar minskade async medeltiden från 23,40 sekunder till 18,94 sekunder och blottlade sedan ett racetillstånd i delad state som den sekventiella slingan hade dolt. 

Jag skulle isolera webbläsaren och testdatan, hålla rutinvändningar på low och höja resonemangsinsatsen bara när bevisen behöver granskas närmare. Om verktygen blir klara snabbt och kraven förblir fasta, stanna vid den synkrona slingan med strukturerade utdata. Använd async när oberoende arbete kan överlappa, och använd styrning när instruktioner ändras under ett svar.

För API-grunder rekommenderar jag att du tar vår kurs Working with the OpenAI API. För större agentsystem, se vår kurs Building Scalable Agentic Systems.