track
Inginer AI asociat pentru dezvoltatori
26 oră
Ce este API-ul GPT-6 Astra?
API-ul GPT-6 Astra este modul în care accesezi noul model flagship OpenAI, lansat pe 3 septembrie 2026, prin Responses API. Pentru acest tutorial, contează suprafața: gpt-6-astra acceptă input text și imagine prin Responses API de la OpenAI. Efortul de raționare variază de la low la max, fără opțiunea none.
Exemplele din acest tutorial folosesc client.responses.create în loc de client.chat.completions.create, dar migrarea necesită și schimbări la formatele de request, output și rezultate ale uneltelor. Elimină setările personalizate pentru temperature, top_p și probabilități log, deoarece Astra nu le suportă. Înainte de primul apel, să ne uităm la prețuri.
Cât costă GPT-6 Astra?
Pentru requesturi cu cel mult 272.000 de tokeni de input, prețul standard este 10 $ pe milion de tokeni obișnuiți de input și 50 $ pe milion de tokeni de output. Inputul din cache costă 1 $ pe milion, iar scrierile în cache costă 12,50 $ pe milion.
După ce un request depășește acest prag, OpenAI aplică un multiplicator 2x pentru input și cache și 1,5x pentru output. Ratele mai mari se aplică întregului request, nu doar tokenilor de peste prag. Niciuna dintre rulările din acest tutorial nu s-a apropiat de prag.
Ce vom construi cu API-ul GPT-6 Astra?
Aplicația de staging este un mic task board Flask: o pagină de start, un formular pentru adăugarea unei sarcini, un buton pentru a marca una ca finalizată și un endpoint /health . Codul complet, inclusiv aplicația de staging, este în acest repository GitHub.
Trei sarcini prestabilite apar înainte de testare. Imagine de Autor.
Aplicația are un singur defect intenționat. Agentul are trei verificări, dar doar suita de teste este concepută să le prindă.
De ce acceptă aplicația titluri goale pentru sarcini?
Endpointul de creare a sarcinii nu respinge un titlu gol. Am lăsat acel comportament pentru ca agentul să aibă un eșec cunoscut de găsit, fără a-l dezvălui în prompt.
Ce verificări de release poate rula agentul?
Agentul poate apela trei unelte:
-
run_test_suiterulează pytest, inclusiv un test de import în masă cu aproximativ 250 de cereri HTTP. -
check_ui_flowfolosește Playwright pentru a adăuga o sarcină și a confirma că apare. -
check_staging_healthtrimite o cerere GET la/health.
Toate trei rulează pe staging, fără mock-uri. Verificarea în browser folosește cod fix; demo-ul de folosire a computerului scris de model vine mai târziu.
Cum configurezi API-ul GPT-6 Astra în Python
Ai nevoie de o cheie OpenAI API cu acces la gpt-6-astra. Creează o cheie la platform.openai.com/api-keys și verifică faptul că proiectul tău are gpt-6-astra activat. Workspace-urile Enterprise au Astra oprit implicit la lansare.
Comenzile de mai jos folosesc Windows PowerShell și instalează toate pachetele necesare pentru acest tutorial, inclusiv realtime de la OpenAI pentru demo-ul de 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 chromiumPe macOS sau Linux, înlocuiește comanda de activare cu source .venv/bin/activate și comanda de copiere cu cp .env.example .env.
Apoi adaugă cheia API în noul fișier .env: Deschide fișierul .env pe care tocmai l-ai copiat și adaugă OPENAI_API_KEY=sk-..., pe care python-dotenv îl încarcă, iar SDK-ul îl preia automat, astfel încât să nu treci niciodată cheia în cod.
Dacă dependențele specifice proiectului sau fișierele .env îți sunt noi, ghidurile noastre despre medii virtuale și variabile de mediu le explică. Confirmă că cheia funcționează înainte de a construi pe ea.
Dacă cheia ta API deja funcționează cu Responses API, sari peste subsecțiunea următoare și începe cu bucla sincronă de unelte. Prima cerere doar verifică setup-ul.
Fă primul tău apel la API-ul GPT-6 Astra
După ce cheia este configurată, trebuie încărcată folosind dotenv. După asta, poți crea un client OpenAI și trimite prima cerere folosind funcția client.responses.create(). Cea mai mică cerere posibilă arată așa:
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)Câmpul usage al răspunsului listează numerele de tokeni necesare pentru calculul de cost de mai târziu.
Construiește o buclă sincronă de unelte pentru GPT-6 Astra
Fragmentele de mai jos sunt extrase; versiunile runnable sunt în repository-ul GitHub aferent.
Înainte de orice async, am construit versiunea obișnuită:
-
Apelează modelul
-
Verifică existența unui element
function_call -
Rulează unealta corespunzătoare
-
Trimite rezultatul înapoi cu
previous_response_id -
Repetă până când modelul nu mai cere unelte.
Această buclă blocantă este baza pentru comparația cu 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.idCe a găsit rularea de bază
În rularea de bază, modelul a apelat fiecare unealtă pe rând. A găsit eșecul de validare cunoscut și a returnat o decizie no-go. Pe trei rulari, timpul total pe ceas a avut o medie de 23,40 secunde. Acea medie acoperă întreaga rulare, nu timpii individuali ai uneltelor.
Cum funcționează apelarea async a uneltelor în GPT-6 Astra?
Marchează o unealtă cu "async": true în schema ei, iar aplicația ta poate amâna acel rezultat în timp ce modelul fie continuă să lucreze, fie așteaptă. Aplicația ta tot rulează unealta și gestionează jobul de fundal.
Cum rulezi verificări independente concurent
Am marcat run_test_suite și check_ui_flow ca async și am adăugat o unealtă definită în aplicație, wait_for_tasks, fără argumente, deoarece acest demo are mereu un singur lot de lucru în așteptare la un moment dat. Acel „wait” fără argumente păstrează exemplul mic.
Într-un runner de producție, identifică joburile cu handle-uri de task, leagă fiecare handle de call_id-ul său original și așteaptă doar când pasul următor depinde de un rezultat în așteptare.
Returnează fiecare rezultat finalizat pe call_id-ul său original, apoi returnează statusul de așteptare pe call_id-ul propriu al uneltei de așteptare.
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", ...},
]Pentru această rulare, aplicația a trimis fiecare apel marcat către un thread pool. În timp ce verificările de fundal rulau, a efectuat verificarea rapidă, sincronă, de health. Apoi s-a blocat la wait_for_tasks până când verificările în așteptare au fost finalizate.
Reduce apelarea async timpul pe ceas?
Pe trei rulari, async a redus timpul mediu pe ceas cu 19,1%, de la 23,40 secunde la 18,94 secunde. Media părea clară până au venit rularile individuale; graficul de mai jos arată cât de mult au variat de fapt. Trei rulari sunt suficiente ca să arate ce s-a întâmplat aici, nu ca să prezică latența în producție.
Timpurile de rulare au variat în ambele moduri. Imagine de Autor.
De ce au cauzat verificările concurente o condiție de cursă?
Rularea simultană a verificării în browser și a testului de import în masă a cauzat uneori eșecul aserțiunii de import în masă, deoarece ambele verificări au modificat aceeași listă de sarcini în memorie. Asta a stricat presupunerea testului de acces exclusiv. Izolarea datelor fie în runner, fie în teste ar evita cursa.
Folosire limitată a computerului cu GPT-6 Astra pentru testarea UI
Pentru folosirea computerului, documentația GPT-6 Astra recomandă execuția de cod, în timp ce unealta structurată computer rămâne susținută ca alternativă. Cu execuția de cod, un apel poate combina mai multe acțiuni, bucle și logică condițională, în timp ce unealta computer returnează câte o acțiune structurată de mouse sau tastatură pe rând, pe care aplicația ta o traduce și o redea.
Cum limitezi runner-ul de folosire a computerului
Am numit clasa BrowserSandbox, dar numele exagerează protecția. Oferă codului scris de model un page Playwright, o funcție log() și un helper expect_text() . Python tot poate injecta built-in-uri în exec(), iar pagina poate naviga către alt origin.
sandbox_globals = {"page": self.page, "log": log, "expect_text": expect_text}
exec(code, sandbox_globals)Tratează asta ca pe un runner demo, nu ca pe o barieră de securitate. Codul scris de model are nevoie de un proces sau container izolat, cu restricții pe filesystem, procese, rețea și origini.
Ce s-a întâmplat în verificarea UI?
Am limitat bucla la opt ture pentru că un check limitat are nevoie de un stop clar. Modelul a inspectat pagina, a găsit câmpul de formular, a creat titlul „UI flow check, cobalt otter 73921”, a trimis sarcina și a confirmat că titlul a apărut, ceea ce a durat 13 secunde. Tutorialul nostru despre folosirea computerului cu GPT-5.4 acoperă un exemplu detaliat folosind un predecesor al lui Astra.
Cum funcționează steering-ul în mijlocul turului cu GPT-6 Astra?
Steering-ul în mijlocul turului este disponibil doar pentru gpt-6-astra peste o conexiune WebSocket.
Deschide o conexiune și creează un răspuns, apoi trimite un eveniment response.steer cu instrucțiuni noi în timp ce răspunsul se generează. Un eveniment response.steer.accepted înseamnă că update-ul este coadat, nu aplicat. Înainte de a crea continuarea automată, serverul termină elementul de output curent și orice muncă de unealtă găzduită deja în desfășurare.
Dacă tot are nevoie de rezultatul unei unelte de client sau de aprobare, response.steer.pending identifică inputul lipsă.
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.",
)Întârzierea de o secundă se potrivește cu codul experimentului și oferă timp primului răspuns să înceapă. Fără această întârziere, s-ar testa un alt punct din ciclul de viață al răspunsului.
Ce lasă neschimbat steering-ul în mijlocul turului?
Steering-ul nu rescrie răspunsul original. Dacă actualizarea îl întrerupe, acel răspuns se termină cu status: "incomplete" și incomplete_details.reason: "steered". Un răspuns succesor continuă apoi cu noua instrucțiune.
Dacă primul răspuns se termină înainte ca update-ul să aibă efect, rămâne completat. Steering-ul nu inversează și nu anulează acțiunile client-side care au început deja; aplicația ta încă deține acel comportament. Steering-ul coadat există doar pe conexiunea WebSocket curentă, așa că înregistrează update-ul înainte de a încerca o reconectare.
Calea de comparație lasă primul răspuns să se termine, apoi trimite un nou request cu instrucțiunile combinate. Pe două rulari, steering-ul a avut în medie 26,91 secunde față de 50,02 secunde pentru calea finish-then-restart. Această comparație nu acoperă o politică cancel-and-restart și nici nu punctează corectitudinea textului final.
Medii pe două rulari pentru timp și cost. Imagine de Autor.
Calea de restart generează două răspunsuri complete care acoperă unele dintre aceleași cereri. Acea configurație explică o parte din diferența de timp, deci nu aș trata aceste două rulari ca un benchmark general pentru steering.
Cum schimbi efortul de raționare GPT-6 Astra în mijlocul conversației
gpt-6-astra suportă efort de raționare de la low până la max. Un efort mai mare poate crește utilizarea tokenilor de raționare, dar nu garantează un răspuns diferit. Un configuration_update schimbă răspunsurile următoare până când un alt update îl suprascrie, în timp ce setarea la nivel de cerere rămâne neschimbată.
În acest pipeline, raportul încheie conversația, deci update-ul afectează doar acel pas final.
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."},
],
)Am folosit aceeași urmă a eșecului la ambele niveluri de efort și am comparat diagnosticul și utilizarea de tokeni.
O subtilitate: câmpul reasoning.effort al răspunsului raportează în continuare setarea la nivel de cerere, nu efortul selectat de configuration_update. Nu folosi acel câmp pentru a verifica dacă update-ul a avut efect.
A schimbat efortul ridicat diagnosticul?
În rularea completă combinată, pasul escaladat a folosit 108 tokeni de raționare. Fiecare alt pas la low a folosit zero. Într-un test izolat anterior, cu o urmă a eșecului mai lungă, efortul scăzut a folosit zero tokeni de raționare, iar cel ridicat a folosit 318. Ambele versiuni au identificat bugul de validare, deci schimbarea la efort mai mare a modificat utilizarea de tokeni, dar nu diagnosticul.
Actualizările de configurație funcționează doar în requesturi standard, cu un singur agent. API-ul respinge update-urile adiacente, iar ele nu pot fi combinate cu compactare automată sau trunchiere automată.
Cum folosești outputurile structurate GPT-6 Astra
Ultimul pas al pipeline-ului apelează client.responses.parse pentru a înlocui textul liber cu un model Pydantic validat.
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 verifică tipurile de câmp declarate aici. Nu dovedește că raportul se potrivește cu dovezile, iar această versiune nu restricționează decision la două valori sau confidence la un interval.
Ce a prins raportul go/no-go?
Raportul a returnat decision: "no_go". A clasificat eșecul de validare menționat mai devreme sub failures și problema de concurență sub risks. Pentru acesta din urmă, a scris: „posibilă interferență de la verificări UI concurente asupra datelor comune din staging.” Promptul nu a numit acel risc.
Păstrează latența și costul în afara acestui schelet și calculează-le în cod. Modelul completează câmpurile raportului din dovezile uneltelor.
Interfața Streamlit consumă același generator ca runner-ul din linia de comandă. Redă fiecare eveniment de unealtă pe măsură ce sosește, apoi arată raportul pars-at în taburile Report și JSON.