Responses API में WebSockets के साथ एजेंटिक वर्कफ़्लो को तेज़ बनाना

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

इन सभी रिक्वेस्ट्स के कारण यूज़र्स को Codex के जटिल काम पूरे होने का इंतज़ार करने में कई मिनट लग सकते हैं. लेटेंसी के नजरिए से, Codex एजेंट लूप अपना ज़्यादातर समय तीन मुख्य चरणों में बिताता है: API सर्विसेज में काम करना (रिक्वेस्ट्स को वैलिडेट और प्रोसेस करना), मॉडल इंफेरेंस, और क्लाइंट-साइड समय (टूल्स चलाना और मॉडल कॉन्टेक्स्ट बनाना). इंफेरेंस वह चरण है जहां मॉडल नए टोकन जनरेट करने के लिए GPUs पर चलता है. पहले, GPUs पर LLM इंफेरेंस चलाना एजेंटिक लूप का सबसे धीमा हिस्सा था, इसलिए API सर्विस ओवरहेड आसानी से छिप जाता था. जैसे-जैसे इंफेरेंस तेज़ होता जा रहा है, एजेंटिक रोलआउट से आने वाला कुल API ओवरहेड अब कहीं ज़्यादा स्पष्ट दिखने लगा है.

इस पोस्ट में हम बताएंगे कि हमने API का उपयोग करते हुए एजेंट लूप्स को एंड-टू-एंड 40% तक तेज़ कैसे बनाया, जिससे यूज़र्स 65 से बढ़कर लगभग 1,000 टोकन प्रति सेकंड की इंफेरेंस स्पीड का अनुभव कर सकें. हमने इसे कैशिंग, अनावश्यक नेटवर्क हॉप्स हटाकर, अपनी सेफ्टी स्टैक को बेहतर बनाकर ताकि समस्याओं को जल्दी फ़्लैग किया जा सके, और—सबसे महत्वपूर्ण—Responses API के साथ एक पर्सिस्टेंट कनेक्शन बनाने के तरीके से हासिल किया, ताकि बार-बार सिंक्रोनस API कॉल्स करने की ज़रूरत न पड़े.

Responses API में, पहले के फ्लैगशिप मॉडल्स जैसे GPT‑5 और GPT‑5.2 लगभग 65 टोकन प्रति सेकंड (TPS) की स्पीड से चलते थे. GPT‑5.3‑Codex‑Spark, एक तेज़ कोडिंग मॉडल, के लॉन्च के लिए हमारा लक्ष्य था इसे एक ऑर्डर ऑफ मैग्निट्यूड तेज़ बनाना: 1,000 TPS से अधिक, जो LLM इंफेरेंस के लिए ऑप्टिमाइज़्ड स्पेशलाइज़्ड Cerebras हार्डवेयर द्वारा संभव हुआ. यह सुनिश्चित करने के लिए कि यूज़र्स इस नए मॉडल की असली स्पीड का अनुभव कर सकें, हमें API ओवरहेड को कम करना पड़ा. 

लगभग नवंबर 2025 के आसपास, हमने Responses API पर एक परफॉर्मेंस स्प्रिंट शुरू किया, जिसमें एक सिंगल रिक्वेस्ट के लिए क्रिटिकल-पाथ लेटेंसी को कम करने के लिए कई ऑप्टिमाइज़ेशन किए: 

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

इन सुधारों के साथ, हमने टाइम टू फर्स्ट टोकन (TTFT) में लगभग 45% सुधार देखा—जो यह दिखाता है कि API कितना रिस्पॉन्सिव महसूस होता है—लेकिन ये सुधार अभी भी GPT‑5.3‑Codex‑Spark के लिए पर्याप्त तेज़ नहीं थे. इन सुधारों के बावजूद, Responses API का ओवरहेड मॉडल की स्पीड के मुकाबले बहुत अधिक था—यानी यूज़र्स को मॉडल सर्व करने वाले GPUs का उपयोग करने से पहले हमारे API चलाने वाले CPUs का इंतज़ार करना पड़ता था.

असली समस्या स्ट्रक्चरल थी: हम हर Codex रिक्वेस्ट को अलग मानते थे और हर फॉलो-अप रिक्वेस्ट में बातचीत की स्टेट और अन्य री-यूज़ेबल कॉन्टेक्स्ट को फिर से प्रोसेस करते थे. भले ही बातचीत का ज़्यादातर हिस्सा नहीं बदला था, फिर भी हमें पूरे हिस्ट्री से जुड़े काम की लागत चुकानी पड़ती थी. जैसे-जैसे बातचीत लंबी होती गई, यह बार-बार होने वाली प्रोसेसिंग और ज़्यादा महंगी होती गई.

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

हमने कुछ अलग-अलग अप्रोच पर विचार किया, जिनमें WebSockets और gRPC बायडायरेक्शनल स्ट्रीमिंग शामिल थे. हमने WebSockets चुना क्योंकि यह एक सिंपल मैसेज ट्रांसपोर्ट प्रोटोकॉल है, जिसमें यूज़र्स को अपने Responses API के इनपुट और आउटपुट शेप्स बदलने की ज़रूरत नहीं पड़ती. यह डेवलपर-फ्रेंडली था और हमारे मौजूदा आर्किटेक्चर में कम बदलाव के साथ फिट हो गया.

पहले WebSocket प्रोटोटाइप ने यह बदल दिया कि हम Responses API लेटेंसी के लिए क्या संभव मानते थे. Codex टीम के एक इंजीनियर ने, जिनके पास API स्टैक में गहरी एक्सपर्टीज़ थी, रात भर Codex एजेंट चलाकर एक प्रोटोटाइप तैयार किया.

उस प्रोटोटाइप में, एजेंटिक रोलआउट्स को एक सिंगल लंबे समय तक चलने वाले Response के रूप में मॉडल किया गया. asyncio फीचर्स का उपयोग करते हुए, Responses API टूल कॉल सैंपल होने के बाद सैंपलिंग लूप में असिंक्रोनस रूप से ब्लॉक हो जाता था, और Responses API क्लाइंट को response.done इवेंट वापस भेजता था. टूल कॉल को एक्जीक्यूट करने के बाद, क्लाइंट्स टूल रिज़ल्ट के साथ response.append इवेंट वापस भेजते थे, जिससे सैंपलिंग लूप अनब्लॉक हो जाता था और मॉडल आगे जारी रख पाता था.

यहां एक समानता यह है कि लोकल टूल कॉल को एक होस्टेड टूल कॉल की तरह ट्रीट किया जाए. जब मॉडल वेब सर्च कॉल करता है, तो इंफेरेंस लूप ब्लॉक हो जाता है, एक वेब सर्च सर्विस को कॉल करता है, और उस सर्विस का रिस्पॉन्स मॉडल कॉन्टेक्स्ट में डालता है. हमारे डिज़ाइन में, हमने यही किया; लेकिन रिमोट सर्विस को कॉल करने के बजाय, हमने मॉडल की टूल कॉल को WebSocket के ज़रिए क्लाइंट को वापस भेज दिया. जब क्लाइंट ने जवाब दिया, तो हमने क्लाइंट के टूल कॉल रिस्पॉन्स को कॉन्टेक्स्ट में डाल दिया और सैंपलिंग जारी रखी.

यह डिज़ाइन बहुत प्रभावी था क्योंकि इसने एजेंट रोलआउट के दौरान बार-बार होने वाले API काम को खत्म कर दिया. हम प्री-इंफेरेंस काम एक बार कर सकते थे, टूल एक्जीक्यूशन के लिए रुक सकते थे, और पोस्ट-इंफेरेंस काम अंत में एक बार कर सकते थे.

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

जिस वर्ज़न को हमने लॉन्च किया, उसमें हम एक परिचित शेप पर वापस आए: उसी बॉडी के साथ response.create का उपयोग जारी रखें, और पिछले रिस्पॉन्स की स्टेट से बातचीत का कॉन्टेक्स्ट जारी रखने के लिए previous_response_id का उपयोग करें.

WebSocket कनेक्शन पर, सर्वर पिछले रिस्पॉन्स की स्टेट का कनेक्शन-स्कोप्ड, इन-मेमोरी कैश बनाए रखता है. जब किसी फॉलो-अप response.create में previous_response_id शामिल होता है, तो हम पूरी बातचीत को फिर से बनाने के बजाय उस स्टेट को कैश से प्राप्त करते हैं.

उस कैश्ड स्टेट में शामिल है:

• पिछला रिस्पॉन्स ऑब्जेक्ट
• पहले के इनपुट और आउटपुट आइटम्स
• टूल डेफिनिशन्स और नेमस्पेसेस
• री-यूज़ेबल सैंपलिंग आर्टिफैक्ट्स, जैसे पहले से रेंडर्ड टोकन

इन-मेमोरी पिछले रिस्पॉन्स स्टेट को री-यूज़ करके, हम कई बड़े ऑप्टिमाइज़ेशन हासिल कर पाए:

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

लक्ष्य था कि हम मिनिमल-ओवरहेड प्रोटोटाइप के जितना हो सके करीब पहुँचें, लेकिन ऐसी API शेप के साथ जिसे डेवलपर्स पहले से समझते हैं और जिसके आसपास उन्होंने काम बनाया है.

WebSocket मोड बनाने के दो महीने के स्प्रिंट के बाद, हमने प्रमुख कोडिंग एजेंट स्टार्टअप्स के साथ एक अल्फा लॉन्च किया ताकि वे इसे अपनी इंफ्रास्ट्रक्चर में इंटीग्रेट कर सकें और सुरक्षित तरीके से ट्रैफिक बढ़ा सकें. अल्फा यूज़र्स को यह बहुत पसंद आया, और उन्होंने अपने एजेंटिक वर्कफ़्लो में 40% तक सुधार⁠(एक नई विंडो में खुलेगा) की रिपोर्ट दी. सकारात्मक अल्फा फीडबैक को देखते हुए, हम लॉन्च के लिए तैयार थे.

लॉन्च के नतीजे तुरंत दिखाई दिए. Codex ने जल्दी ही अपने Responses API ट्रैफिक का ज़्यादातर हिस्सा WebSocket मोड पर शिफ्ट कर दिया, जिससे लेटेंसी में बड़ा सुधार देखा गया. GPT‑5.3‑Codex‑Spark के लिए, हमने अपना 1,000 TPS का लक्ष्य हासिल किया और 4,000 TPS तक के बर्स्ट्स देखे, जिससे यह साबित हुआ कि Responses API वास्तविक प्रोडक्शन ट्रैफिक में तेज़ इंफेरेंस के साथ तालमेल बिठा सकता है. इसका प्रभाव डेवलपर कम्युनिटी में भी जल्दी दिखने लगा:

• Codex ने जल्दी ही अपने ज़्यादातर ट्रैफिक को WebSockets पर शिफ्ट कर दिया.Codex यूज़र्स जो GPT‑5.3‑Codex⁠(एक नई विंडो में खुलेगा) जैसे लेटेस्ट मॉडल्स चला रहे हैं, GPT‑5.4⁠(एक नई विंडो में खुलेगा), और आगे के सभी मॉडल्स WebSocket मोड की स्पीड का फायदा उठाते हैं.
• Vercel ने WebSocket मोड को AI SDK में इंटीग्रेट किया और लेटेंसी में 40% तक कमी⁠(एक नई विंडो में खुलेगा) देखी.
• Cline के मल्टी-फाइल वर्कफ़्लो 39% तेज़⁠(एक नई विंडो में खुलेगा) हो गए.
• Cursor में OpenAI मॉडल्स 30% तक तेज़⁠(एक नई विंडो में खुलेगा) हो गए.

WebSocket मोड, मार्च 2025 में लॉन्च के बाद से, Responses API की सबसे महत्वपूर्ण नई क्षमताओं में से एक है. हमने OpenAI की API और Codex टीमों के बीच करीबी सहयोग से, कुछ ही हफ्तों में आइडिया से प्रोडक्शन तक का सफर तय किया. यह न सिर्फ एजेंट रोलआउट लेटेंसी को काफी बेहतर बनाता है, बल्कि बिल्डर्स की बढ़ती ज़रूरत को भी सपोर्ट करता है: जैसे-जैसे मॉडल इंफेरेंस तेज़ होता है, वैसे-वैसे उससे जुड़े सर्विसेज और सिस्टम्स को भी तेज़ होना पड़ता है ताकि ये फायदे यूज़र्स तक पहुँच सकें.