GPT-6 Astra API ट्यूटोरियल: Async टूल्स और स्टीयरिंग के साथ एक रिलीज़-चेक एजेंट बनाएँ

GPT-6 Astra API क्या है?

GPT-6 Astra API वह तरीका है जिससे आप OpenAI के नए फ्लैगशिप मॉडल (3 सितंबर, 2026 को जारी) तक Responses API के माध्यम से पहुँचते हैं। इस ट्यूटोरियल के लिए जो मायने रखता है वह सतह है: gpt-6-astra OpenAI की image इनपुट्स स्वीकार करता है Responses API के जरिए। इसका रीजनिंग एफ़र्ट low से max तक होता है, none विकल्प के बिना। 

इस ट्यूटोरियल के उदाहरण client.responses.create का उपयोग करते हैं, client.chat.completions.create के बजाय, लेकिन माइग्रेशन के लिए अनुरोध, आउटपुट, और टूल-रिज़ल्ट फॉर्मैट भी बदलने पड़ते हैं। कस्टम temperature, top_p और लॉग-प्रॉबेबिलिटी सेटिंग्स भी हटा दें, क्योंकि Astra उन्हें सपोर्ट नहीं करता। पहली कॉल करने से पहले, कीमत पर नज़र डालें।

GPT-6 Astra की कीमत कितनी है?

272,000 इनपुट टोकन तक के अनुरोधों के लए मानक प्राइसिंग $10 प्रति मिलियन सामान्य इनपुट टोकन और $50 प्रति मिलियन आउटपुट टोकन है। कैश्ड इनपुट $1 प्रति मिलियन है, और कैश राइट्स $12.50 प्रति मिलियन। 

एक बार जब कोई अनुरोध उस थ्रेशोल्ड से अधिक हो जाता है, OpenAI इनपुट और कैश रेट्स पर 2x मल्टीप्लायर और आउटपुट रेट पर 1.5x मल्टीप्लायर लागू करता है। उच्च रेट्स पूरे अनुरोध पर लागू होते हैं, केवल थ्रेशोल्ड से ऊपर के टोकन पर नहीं। इस ट्यूटोरियल में कोई भी रन उस थ्रेशोल्ड के करीब नहीं आया।

हम GPT-6 Astra API से क्या बनाएंगे?

स्टेजिंग ऐप एक छोटा Flask टास्क बोर्ड है: एक होम पेज, एक टास्क जोड़ने का फ़ॉर्म, किसी टास्क को डन मार्क करने का बटन, और एक /health एंडपॉइंट। पूरा कोड, स्टेजिंग ऐप सहित, इस GitHub रिपॉज़िटरी में है।

टेस्टिंग से पहले तीन सीडेड टास्क दिखाई देते हैं। इमेज: लेखक द्वारा।

ऐप में एक जानबूझकर छोड़ी गई खामी है। एजेंट के पास तीन चेक हैं, लेकिन केवल टेस्ट सूट उन्हें पकड़ने के लिए डिज़ाइन किया गया है।

ऐप खाली टास्क टाइटल्स क्यों स्वीकार करता है?

टास्क-क्रिएशन एंडपॉइंट खाली टाइटल को अस्वीकार नहीं करता। मैंने वह व्यवहार इसलिए रहने दिया ताकि एजेंट के पास एक ज्ञात विफलता हो जिसे वह बिना प्रॉम्प्ट में बताए ढूंढ सके।

एजेंट कौन-से रिलीज़ चेक चला सकता है?

एजेंट तीन टूल्स को कॉल कर सकता है:

• run_test_suite pytest चलाता है, जिसमें लगभग 250 HTTP रिक्वेस्ट्स वाला एक बल्क इम्पोर्ट टेस्ट शामिल है। 

• check_ui_flow Playwright का उपयोग करके एक टास्क जोड़ता है और पुष्टि करता है कि वह दिखाई देता है। 

• check_staging_health /health को एक GET रिक्वेस्ट भेजता है। 

तीनों स्टेजिंग पर, बिना मॉक्स के चलते हैं। ब्राउज़र चेक फिक्स्ड कोड का उपयोग करता है; मॉडल-रचित कंप्यूटर यूज़ डेमो बाद में आता है।

Python में GPT-6 Astra API कैसे सेट करें

आपको gpt-6-astra की एक्सेस के साथ OpenAI API कुंजी चाहिए। platform.openai.com/api-keys पर एक कुंजी बनाएं, और जाँचें कि आपके प्रोजेक्ट में gpt-6-astra सक्षम है। एंटरप्राइज़ वर्कस्पेस में लॉन्च पर Astra डिफॉल्ट रूप से ऑफ रहता है।

नीचे दिए गए कमांड Windows PowerShell का उपयोग करते हैं और इस ट्यूटोरियल के लिए आवश्यक सभी पैकेज इंस्टॉल करते हैं, जिसमें स्टीयरिंग डेमो के लिए OpenAI का realtime शामिल है।

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

macOS या Linux पर, एक्टिवेशन कमांड को source .venv/bin/activate और कॉपी कमांड को cp .env.example .env से बदलें। 

फिर नई .env फ़ाइल में API कुंजी जोड़ें: अभी कॉपी की गई .env फ़ाइल खोलें और OPENAI_API_KEY=sk-... जोड़ें, जिसे python-dotenv लोड करता है और SDK अपने आप उठा लेता है, ताकि आपको कभी भी कोड में कुंजी पास न करनी पड़े।

यदि प्रोजेक्ट-विशिष्ट डिपेंडेंसीज़ या .env फ़ाइलें आपके लिए नई हैं, तो हमारे वर्चुअल एनवायरनमेंट और एनवायरनमेंट वेरिएबल्स गाइड्स उन्हें समझाते हैं। कुंजी का काम करना कन्फर्म करें, फिर उस पर आगे बनाएं।

यदि आपकी API कुंजी पहले से Responses API के साथ काम करती है, तो अगला उपखंड छोड़ दें और सिंक्रोनस टूल लूप से शुरू करें। पहली रिक्वेस्ट केवल सेटअप सत्यापित करती है।

अपनी पहली GPT-6 Astra API कॉल करें

एक बार कुंजी लगने के बाद, उसे dotenv के जरिए लोड करना होगा। इसके बाद, आप एक OpenAI क्लाइंट बना सकते हैं और client.responses.create() फ़ंक्शन का उपयोग करके अपनी पहली रिक्वेस्ट भेज सकते हैं। सबसे छोटी संभव रिक्वेस्ट इस तरह दिखती है:

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)

रेस्पॉन्स का usage फ़ील्ड बाद की लागत गणना के लिए आवश्यक टोकन काउंट्स सूचीबद्ध करता है।

एक सिंक्रोनस GPT-6 Astra टूल लूप बनाएँ

नीचे दिए गए स्निपेट अंश हैं; चलने योग्य संस्करण साथ की GitHub रिपॉज़िटरी में हैं।

किसी भी async चीज़ को छूने से पहले, मैंने साधारण वर्ज़न बनाया: 

1. मॉडल को कॉल करें

2. function_call आइटम देखें

3. मिलते-जुलते टूल को चलाएं

4. previous_response_id के साथ नतीजा वापस भेजें

5. जब तक मॉडल टूल्स माँगना बंद न कर दे, दोहराएँ। 

यह ब्लॉकिंग लूप 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

बेसलाइन रन ने क्या पाया

बेसलाइन रन में, मॉडल ने हर टूल को बारी-बारी से कॉल किया। उसने ज्ञात वैलिडेशन फेल्योर पाया और no-go निर्णय लौटाया। तीन रनों में, कुल वॉल-क्लॉक समय औसतन 23.40 सेकंड रहा। यह औसत पूरे रन को कवर करता है, न कि व्यक्तिगत टूल समयों को।

GPT-6 Astra Async Tool Calling कैसे काम करता है?

किसी टूल को उसकी स्कीमा में "async": true से चिह्नित करें, और आपकी ऐप वह नतीजा टाल सकती है जबकि मॉडल या तो काम जारी रखेगा या इंतज़ार करेगा। आपकी एप्लिकेशन अब भी टूल चलाती है और बैकग्राउंड जॉब को मैनेज करती है।

स्वतंत्र चेक्स को साथ में कैसे चलाएँ

मैंने run_test_suite और check_ui_flow को async चिह्नित किया, और एक ऐप-परिभाषित wait_for_tasks टूल बिना आर्ग्युमेंट्स के जोड़ा, क्योंकि इस डेमो में एक समय में केवल एक बैच की पेंडिंग वर्क होता है। यह बिना-आर्ग्युमेंट वेट उदाहरण को छोटा रखता है। 

प्रोडक्शन रनर में, जॉब्स को टास्क हैंडल्स से पहचानें, हर हैंडल को उसके मूल call_id से बाँधें, और केवल तब वेट करें जब अगला कदम किसी पेंडिंग नतीजे पर निर्भर हो।

हर पूर्ण हुए नतीजे को उसके मूल call_id पर लौटाएँ, फिर वेट टूल के अपने 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", ...},
]

इस रन में, ऐप ने प्रत्येक चिह्नित कॉल को एक थ्रेड पूल में सबमिट किया। जबकि बैकग्राउंड चेक्स चल रहे थे, इसने तेज़ सिंक्रोनस हेल्थ चेक किया। फिर यह wait_for_tasks पर तब तक ब्लॉक रहा जब तक पेंडिंग चेक्स पूरे नहीं हो गए।

क्या async tool calling वॉल-क्लॉक समय घटाता है?

तीन रनों में, async ने औसत वॉल-क्लॉक समय 19.1% घटाया, 23.40 सेकंड से 18.94 सेकंड तक। औसत सीधा लगा जब तक कि व्यक्तिगत रनों के नतीजे नहीं आए; नीचे का चार्ट दिखाता है कि वे वास्तव में कितने अलग थे। तीन रन यहाँ क्या हुआ यह दिखाने को पर्याप्त हैं, प्रोडक्शन लेटेंसी की भविष्यवाणी के लिए नहीं।

दोनों मोड में रन टाइम बदले। इमेज: लेखक द्वारा।

साथ-साथ चेक्स ने रेस कंडीशन क्यों पैदा की?

ब्राउज़र चेक और बल्क इम्पोर्ट टेस्ट को एक साथ चलाने से कभी-कभी बल्क इम्पोर्ट एसेर्शन फेल हो गया क्योंकि दोनों चेक्स ने एक ही इन-मैमोरी टास्क सूची को संशोधित किया। इससे टेस्ट का एक्सक्लूसिव एक्सेस का अनुमान टूट गया। रनर या टेस्ट्स में डेटा को आइसोलेट करना रेस से बचाएगा।

UI टेस्टिंग के लिए बाउंडेड GPT-6 Astra कंप्यूटर यूज़

कंप्यूटर यूज़ के लिए, GPT-6 Astra के दस्तावेज़ कोड एक्ज़िक्यूशन की अनुशंसा करते हैं, जबकि संरचित computer टूल एक विकल्प के रूप में समर्थित रहता है। कोड एक्ज़िक्यूशन के साथ, एक कॉल कई ऐक्शंस, लूप्स, और कंडीशनल लॉजिक को जोड़ सकती है, जबकि computer टूल एक समय में एक संरचित माउस या कीबोर्ड ऐक्शन लौटाता है जिसे आपकी एप्लिकेशन ट्रांसलेट और रीप्ले करती है।

कंप्यूटर-यूज़ रनर को कैसे सीमित करें

मैंने क्लास का नाम BrowserSandbox रखा, लेकिन यह नाम इसकी सुरक्षा को बढ़ा-चढ़ाकर बताता है। यह मॉडल-रचित कोड को एक Playwright page, एक log() फ़ंक्शन, और एक expect_text() हेल्पर देता है। Python अब भी exec() में बिल्ट-इन्स इंजेक्ट कर सकता है, और पेज किसी दूसरे ओरिजिन पर नेविगेट कर सकता है।

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

इसे एक डेमो रनर मानें, सुरक्षा सीमा नहीं। मॉडल-रचित कोड को फाइलसिस्टम, प्रोसेस, नेटवर्क, और ओरिजिन प्रतिबंधों के साथ एक आइसोलेटेड प्रोसेस या कंटेनर चाहिए।

UI चेक में क्या हुआ?

मैंने लूप को आठ टर्न पर कैप किया क्योंकि बाउंडेड चेक को हार्ड स्टॉप चाहिए। मॉडल ने पेज का निरीक्षण किया, फ़ॉर्म इनपुट पाया, शीर्षक "UI flow check, cobalt otter 73921" बनाया, टास्क सबमिट किया, और पुष्टि की कि शीर्षक दिखाई दिया—जिसमें 13 सेकंड लगे। हमारा GPT-5.4 कंप्यूटर यूज़ ट्यूटोरियल Astra के पूर्ववर्ती मॉडल का विस्तृत उदाहरण कवर करता है।

GPT-6 Astra मिड-टर्न स्टीयरिंग कैसे काम करती है?

मिड-टर्न स्टीयरिंग केवल gpt-6-astra के लिए एक WebSocket कनेक्शन पर उपलब्ध है।

कनेक्शन खोलें और एक रेस्पॉन्स बनाएं, फिर रेस्पॉन्स जेनरेट होते समय नए निर्देशों के साथ एक response.steer इवेंट भेजें। response.steer.accepted इवेंट का मतलब है कि अपडेट कतार में है, लागू नहीं हुआ। स्वचालित कंटिन्युएशन बनाने से पहले, सर्वर मौजूदा आउटपुट आइटम और कोई भी चल रहा होस्टेड टूल वर्क पूरा करता है। 

यदि उसे अब भी किसी क्लाइंट टूल रिजल्ट या अप्रूवल की ज़रूरत है, तो response.steer.pending गायब इनपुट की पहचान करता है।

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

एक-सेकंड की देरी प्रयोग कोड से मेल खाती है और पहले रेस्पॉन्स को शुरू होने का समय देती है। इस देरी के बिना, यह रेस्पॉन्स लाइफसाइकल के एक अलग बिंदु का परीक्षण करता।

मिड-टर्न स्टीयरिंग क्या अपरिवर्तित छोड़ती है?

स्टीयरिंग मूल रेस्पॉन्स को फिर से नहीं लिखती। यदि अपडेट उसे बाधित करता है, तो वह रेस्पॉन्स status: "incomplete" और incomplete_details.reason: "steered" के साथ समाप्त होता है। फिर एक उत्तराधिकारी रेस्पॉन्स नए निर्देश के साथ जारी रहता है। 

यदि पहला रेस्पॉन्स अपडेट के प्रभाव में आने से पहले पूरा हो जाता है, तो वह पूरा ही रहता है। स्टीयरिंग उन क्लाइंट-साइड ऐक्शंस को रिवर्स या कैंसिल नहीं करती जो पहले ही शुरू हो चुके हैं; वह व्यवहार अब भी आपकी एप्लिकेशन के जिम्मे है। कतारबद्ध स्टीयरिंग केवल वर्तमान WebSocket कनेक्शन पर मौजूद होती है, इसलिए रीकनेक्ट की कोशिश से पहले अपडेट रिकॉर्ड करें।

तुलना पथ पहले रेस्पॉन्स को पूरा होने देता है, फिर संयुक्त निर्देशों के साथ एक नई रिक्वेस्ट भेजता है। दो रनों में, स्टीयरिंग का औसत 26.91 सेकंड रहा, जबकि उस फिनिश-फिर-रीस्टार्ट पथ के लिए 50.02 सेकंड। यह तुलना कैंसल-एंड-रीस्टार्ट पॉलिसी को कवर नहीं करती और न ही अंतिम टेक्स्ट की शुद्धता का स्कोर देती है।

समय और लागत के लिए दो-रन औसत। इमेज: लेखक द्वारा।

रीस्टार्ट पथ दो पूर्ण रेस्पॉन्स जेनरेट करता है जो कुछ समान अनुरोधों को कवर करते हैं। यह सेटअप समय के अंतर का एक हिस्सा समझाता है, इसलिए मैं इन दो रनों को स्टीयरिंग के लिए एक सामान्य बेंचमार्क नहीं मानूँगा।

बातचीत के बीच में GPT-6 Astra का रीजनिंग एफ़र्ट कैसे बदलें

gpt-6-astra का रीजनिंग एफ़र्ट low से max तक सपोर्ट करता है। उच्च एफ़र्ट रीजनिंग-टोकन उपयोग बढ़ा सकता है, लेकिन अलग उत्तर की गारंटी नहीं देता। एक configuration_update अगले और बाद के रेस्पॉन्स को तब तक बदलता है जब तक कि कोई और अपडेट उसे ओवरराइड न करे, जबकि रिक्वेस्ट-लेवल सेटिंग अपरिवर्तित रहती है। 

इस पाइपलाइन में, रिपोर्ट बातचीत को समाप्त करती है, इसलिए अपडेट केवल उसी अंतिम चरण को प्रभावित करता है।

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

मैंने दोनों एफ़र्ट लेवल पर वही फेल्योर ट्रेस इस्तेमाल किया और डायग्नोसिस और टोकन उपयोग की तुलना की।

एक बारीकी: रेस्पॉन्स का reasoning.effort फ़ील्ड अब भी रिक्वेस्ट-लेवल सेटिंग रिपोर्ट करता है, न कि configuration_update द्वारा चुना गया एफ़र्ट। यह जाँचने के लिए उस फ़ील्ड का उपयोग न करें कि अपडेट प्रभावी हुआ या नहीं।

क्या उच्च रीजनिंग एफ़र्ट ने डायग्नोसिस बदला?

पूरे संयुक्त रन में, बढ़े हुए स्टेप ने 108 रीजनिंग टोकन उपयोग किए। अन्य हर स्टेप ने low पर शून्य उपयोग किया। एक पहले के अलग-थलग टेस्ट में, जिसमें लंबा फेल्योर ट्रेस था, low एफ़र्ट ने शून्य रीजनिंग टोकन उपयोग किए, और high एफ़र्ट ने 318। दोनों वर्ज़न ने वैलिडेशन बग पहचाना, इसलिए उच्च एफ़र्ट बदलाव ने टोकन उपयोग बदला लेकिन डायग्नोसिस नहीं।

कॉन्फ़िगरेशन अपडेट केवल मानक, सिंगल-एजेंट रिक्वेस्ट्स में काम करते हैं। API आस-पास के अपडेट्स को अस्वीकार करता है, और उन्हें ऑटोमैटिक कम्पैक्शन या ऑटोमैटिक ट्रंकेशन के साथ जोड़ा नहीं जा सकता।

GPT-6 Astra Structured Outputs का उपयोग कैसे करें

पाइपलाइन का अंतिम चरण फ्री टेक्स्ट को एक वैलिडेटेड Pydantic मोडल से बदलने के लिए client.responses.parse को कॉल करता है।

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 यहाँ घोषित फील्ड प्रकारों की जाँच करता है। यह साबित नहीं करता कि रिपोर्ट साक्ष्यों से मेल खाती है, और यह वर्ज़न decision को दो मानों तक या confidence को एक रेंज तक सीमित नहीं करता।

go/no-go रिपोर्ट ने क्या पकड़ा?

रिपोर्ट ने decision: "no_go" लौटाया। इसने पहले बताए गए वैलिडेशन फेल्योर को failures के तहत और कंकरेन्सी समस्या को risks के तहत वर्गीकृत किया। बाद वाले के लिए, इसने लिखा: "shared staging data के खिलाफ concurrent UI checks से संभव हस्तक्षेप।" प्रॉम्प्ट ने उस जोखिम का नाम नहीं लिया था।

लेटेंसी और लागत को इस स्कीमा के बाहर रखें और उन्हें कोड में कैलकुलेट करें। मॉडल टूल साक्ष्यों से रिपोर्ट फील्ड्स भरता है।

The Streamlit इंटरफ़ेस कमांड-लाइन रनर जैसा ही जेनरेटर कंज़्यूम करता है। यह जैसे-जैसे हर टूल इवेंट आता है, उसे रेंडर करता है, फिर पार्स की गई रिपोर्ट को Report और JSON टैब्स में दिखाता है।

लाइव एजेंट प्रोग्रेस और उसके बगल में अंतिम रिपोर्ट। वीडियो: लेखक द्वारा।

डैशबोर्ड फिक्स्ड ब्राउज़र चेक, रीजनिंग अपडेट, स्ट्रक्चर्ड रिपोर्ट, और टाइमिंग डिस्प्ले के साथ संयुक्त async रिलीज़ पाइपलाइन चलाता है। इसका कॉस्ट पैनल वही लेज़र पढ़ता है जो कमांड-लाइन रनर पढ़ता है। यह अलग मॉडल-रचित कंप्यूटर यूज़ या स्टीयरिंग डेमो नहीं चलाता।

GPT-6 Astra API टोकन उपयोग और लागत कैसे ट्रैक करें

इन रनों के मॉडल-टोकन हिस्से के लिए, usage फ़ील्ड में प्रत्येक रेस्पॉन्स की कीमत लगाने के लिए आवश्यक चार टोकन काउंट्स शामिल हैं। कैश राइट्स की अपनी दर होती है, इसलिए उन्हें सामान्य इनपुट के साथ समूहित न करें। यहाँ के टूल्स आपकी एप्लिकेशन में चलते हैं; यदि आप किसी अलग शुल्क वाले होस्टेड टूल को जोड़ते हैं, तो उस चार्ज को भी शामिल करें।

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

यह गणना एक रेस्पॉन्स को कवर करती है। लेज़र इसे हर रेस्पॉन्स के बाद लागू करता है, फिर कॉल टोटल्स जोड़ता है।

cache_write_tokens को तब भी लॉग करें जब मान शून्य हो। अन्यथा, भविष्य का कोई कैश राइट सामान्य इनपुट काउंट के अंदर छिप सकता है, और बिलिंग त्रुटि का यह पता चलने का कष्टप्रद तरीका है।

GPT-6 Astra एजेंट प्रोडक्शन कंसिडरेशंस

डिप्लॉयमेंट्स को गेट करने से पहले डेमो को इन बदलावों की ज़रूरत है।

टूल परमिशंस और आइसोलेशन

स्टेजिंग सीमा बनाए रखें और ऊपर बताए अनुसार BrowserSandbox को आइसोलेट करें। इसे डेटाबेस क्रेडेंशियल्स या प्रोडक्शन एक्सेस न दें।

Async जॉब लाइफसाइकल

डेमो में, हर पेंडिंग जॉब खत्म होता है, और उसे कोई और नहीं छूता। डिप्लॉयड रनर को उन केसों से बचना होगा जहाँ दोनों में से कोई सच न हो। उसे हर पेंडिंग एंट्री के लिए ज़रूरत है:

• एक डेडलाइन और एक फाइनल स्टेट, ताकि कुछ भी हमेशा के लिए पेंडिंग न पड़े
• एक डिलीवरी फ़्लैग, ताकि एक कॉलबैक और एक रिट्राई एक ही नतीजा दो बार न भेजें
• स्टार्ट और फिनिश टाइमस्टैम्प्स, ताकि टाइमआउट और देर से लेकिन वैध कंप्लीशन में फर्क किया जा सके
• डुप्लिकेट-कॉल रिजेक्शन, ताकि एक ही टास्क दो बार लॉन्च न हो सके
• बैकग्राउंड-थ्रेड एरर हैंडलिंग, ताकि थ्रो हुई एक्सेप्शन पूल में गुम न हो जाए
• कैंसलेशन, जिसका मतलब है देर से आए नतीजे को अनदेखा करना और कोई भी बाहरी चल रहा काम रोकना

स्टीयरिंग और अपरिवर्तनीय क्रियाएँ

स्टीयर भविष्य के निर्देश बदल सकता है, लेकिन पूर्ण हो चुके साइड इफ़ेक्ट को रिवर्स नहीं कर सकता। यदि किसी टूल ने पहले ही किसी बाहरी सिस्टम को बदल दिया है, तो उसकी भरपाई के लिए अलग टूल ऐक्शन चाहिए।

मिसअलाइनमेंट मॉनिटरिंग

ऑटोमैटिक स्टॉपिंग उन Responses API रिक्वेस्ट्स पर लागू होती है जो persisted reasoning, WebSockets, या OpenAI कम्पैक्शन का उपयोग करती हैं। अन्य रिक्वेस्ट्स अलर्ट ट्रिगर कर सकती हैं, लेकिन स्वतः नहीं रुकतीं। 

स्ट्रीमिंग से पहले, misalignment monitoring HTTP 403 और कोड misalignment_policy_violation के साथ किसी कवर किए गए रन को ब्लॉक कर सकता है। एक स्ट्रीमिंग क्लाइंट को आउटपुट शुरू होने के बाद एरर मिल सकता है। रुकी हुई बातचीत के लिए API कोई सामान्य रिज्यूम पाथ नहीं देता।

GPT-6 Astra एजेंट डिप्लॉयमेंट चेकलिस्ट

इस एजेंट को लोकल डेमो से डिप्लॉयमेंट में ले जाने से पहले ये कंट्रोल जोड़ें। ये मॉडल निर्देशों के बजाय एप्लिकेशन कोड में होने चाहिए।

• स्टेजिंग ऐप की HTTP कॉल्स और WebSocket कनेक्शन पर स्पष्ट टाइमआउट्स सेट करें

• साधारण इनपुट, कैश्ड इनपुट, कैश राइट्स, आउटपुट, रेस्पॉन्स ID, और टर्न काउंट को लॉग करें

• अधूरे रनों या टर्न कैप छूने वाले रनों पर अलर्ट करें। बजट ओवररन के लिए अलग अलर्ट सेट करें

• openai SDK वर्ज़न पिन करें और अपग्रेड से पहले async, स्टीयरिंग, और configuration_update व्यवहार फिर से जाँचें

आपको GPT-6 Astra Async टूल्स या स्टीयरिंग कब उपयोग करनी चाहिए?

काम के अनुसार सबसे सरल रास्ता चुनें।

• जब टूल्स जल्दी नतीजा लौटाते हैं और आवश्यकताएँ स्थिर रहती हैं, तो सिंक्रोनस रिक्वेस्ट और स्ट्रक्चर्ड आउटपुट्स से शुरू करें।
• जब मॉडल या कोई दूसरा टूल धीमी कॉल के दौरान उपयोगी काम कर सकता हो, और बचा समय अतिरिक्त जॉब मैनेजमेंट ओवरहेड को जस्टिफाई करता हो, तब async tool calling जोड़ें।
• जब रन के दौरान आवश्यकताएँ बदलती हैं, तब मिड-टर्न स्टीयरिंग उपयोग करें।

अंतिम विचार

धीमे टूल्स को ओवरलैप करने देने के बाद सिंक्रोनस रिलीज़ चेक और उपयोगी हो गया, हालांकि नतीजा पूरी तरह क्लीन विन नहीं था। तीन रनों में, async ने औसत समय 23.40 सेकंड से 18.94 सेकंड तक घटाया, फिर एक साझा-स्टेट रेस उजागर की जिसे सीक्वेंशियल लूप ने छिपा दिया था। 

मैं ब्राउज़र और टेस्ट डेटा को आइसोलेट करूँगा, रूटीन टर्न्स को low पर रखूँगा, और केवल तब रीजनिंग एफ़र्ट बढ़ाऊँगा जब साक्ष्य को नज़दीक से देखने की ज़रूरत हो। यदि टूल्स जल्दी पूरा हो जाते हैं और आवश्यकताएँ स्थिर रहती हैं, तो स्ट्रक्चर्ड आउटपुट्स के साथ सिंक्रोनस लूप पर ही रुकें। जब स्वतंत्र काम ओवरलैप हो सके तब async का उपयोग करें, और जब रेस्पॉन्स के दौरान निर्देश बदलें तब स्टीयरिंग का।

API बेसिक्स के लिए, मैं सलाह दूँगा कि हमारा Working with the OpenAI API कोर्स लें। बड़े एजेंट सिस्टम्स के लिए, हमारा Building Scalable Agentic Systems कोर्स देखें।