Responses API मध्ये WebSockets चा वापर करून एजंट-आधारित कार्यप्रवाहांना गती देणे

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

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

या पोस्टमध्ये, API वापरून आम्ही एजंट लूप्स एंड-टू-एंड 40% जलद कसे केले ते स्पष्ट करू. यामुळे इन्फरन्सचा वेग 65 टोकन प्रति सेकंदावरून जवळपास 1,000 टोकन प्रति सेकंद इतका वाढल्याचा अनुभव वापरकर्त्यांना घेता येतो. आम्ही हे कॅशिंग, अनावश्यक नेटवर्क हॉप्स काढून टाकणे, समस्या पटकन फ्लॅग करता याव्यात म्हणून आमचा सेफ्टी स्टॅक सुधारणे, आणि—सर्वात महत्त्वाचे म्हणजे—समकालिक API कॉल्सची मालिका करण्याऐवजी Responses API शी persistent connection तयार करण्याची पद्धत उभारणे, अशा मार्गांनी केले.

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 bidirectional streaming यांसह काही वेगवेगळ्या दृष्टिकोनांचा विचार केला. आम्ही WebSockets निवडले, कारण साधा संदेश वाहतूक प्रोटोकॉल म्हणून वापरकर्त्यांना त्यांच्या Responses API च्या इनपुट आणि आउटपुटची रचना बदलावी लागली नसती. ते डेव्हलपरसाठी अनुकूल होते आणि फारसा व्यत्यय न आणता आमच्या विद्यमान आर्किटेक्चरमध्ये बसले.

पहिल्या WebSocket प्रोटोटाइपने Responses API लेटन्सीबद्दल आमच्या शक्यतांच्या कल्पना बदलल्या. Codex टीममधील API स्टॅकवर सखोल तज्ज्ञता असलेल्या अभियंत्याने रात्रभर Codex एजंट चालवून एक प्रोटोटाइप तयार केला.

त्या प्रोटोटाइपमध्ये, एजेंटिक रोलआउट्सना एकाच दीर्घकाळ चालणाऱ्या रिस्पॉन्स म्हणून मॉडेल केले गेले. 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 समाविष्ट असते, तेव्हा आम्ही संपूर्ण संभाषण शून्यातून पुन्हा तयार करण्याऐवजी ती स्थिती कॅशमधून मिळवतो.

त्या कॅश केलेल्या स्थितीत समाविष्ट आहे:

• मागील प्रतिसाद (response) ऑब्जेक्ट
• मागील इनपुट आणि आउटपुट घटक
• टूल व्याख्या आणि नेमस्पेसेस
• पुन्हा वापरता येण्याजोगे सॅम्पलिंग घटक, जसे पूर्वी रेंडर केलेले टोकन

मेमरीतील मागील प्रतिसादाची स्थिती पुन्हा वापरल्यामुळे, आम्ही अनेक महत्त्वपूर्ण कार्यक्षमतेत सुधारणा साध्य केल्या:

• आमच्या काही सुरक्षा वर्गीकरण साधनांनी आणि विनंती प्रमाणीकरण साधनांनी प्रत्येक वेळी पूर्ण इतिहासाऐवजी फक्त नवीन इनपुटवर प्रक्रिया केली
• रेंडर केलेल्या टोकनसाठी इन-मेमरी कॅशे ठेवणे, ज्यामध्ये आम्ही सतत भर घालतो, जेणेकरून अनावश्यक टोकनायझेशन टाळता येईल
• विनंत्यांमध्ये आमचे यशस्वी मॉडेल रिझोल्यूशन/राउटिंग लॉजिक पुन्हा वापरणे 
• बिलिंगसारखे अनुमानानंतरचे अवरोध न करणारे काम पुढील विनंत्यांसह ओव्हरलॅप करणे

उद्दिष्ट असे होते की किमान ओव्हरहेड असलेल्या प्रोटोटाइपच्या शक्य तितक्या जवळ पोहोचावे, पण त्याच वेळी विकसकांना आधीपासूनच समजलेली आणि ज्याभोवती त्यांनी आधीच बांधणी केली होती अशी API ची रचना असावी.

WebSocket मोड तयार करण्यासाठी दोन महिन्यांच्या वेगवान प्रयत्नांनंतर, आम्ही प्रमुख कोडिंग एजंट स्टार्टअप्ससह एक अल्फा लॉन्च केला, जेणेकरून ते त्यांच्या पायाभूत सुविधांमध्ये समाकलित करू शकतील आणि सुरक्षितपणे रहदारी वाढवू शकतील. अल्फा वापरकर्त्यांना ते खूप आवडले आणि त्यांनी त्यांच्या एजंटिक कार्यप्रवाहांमध्ये 40% पर्यंत सुधारणा झाल्याचे⁠(नवीन विंडोमध्ये उघडेल) नोंदवले. अल्फा टप्प्यातील सकारात्मक अभिप्रायामुळे, आम्ही लाँच करण्यासाठी तयार होतो.

सुरुवातीचे परिणाम तात्काळ दिसून आले. Codex ने त्यांच्या Responses API ट्रॅफिकपैकी बहुतांश ट्रॅफिक जलदगतीने WebSocket mode वर स्थलांतरित केले, ज्यामुळे विलंबात लक्षणीय सुधारणा दिसून आली. GPT‑5.3‑Codex‑Spark साठी, आम्ही आमचे 1,000 TPS चे लक्ष्य गाठले आणि 4,000 TPS पर्यंतचे स्पाइक्स दिसले, ज्यामुळे Responses API वास्तविक प्रॉडक्शन ट्रॅफिकमध्ये खूप जलद इन्फरन्सशी जुळवून घेऊ शकते हे दिसून आले. हा परिणाम विकसक समुदायातही पटकन दिसून आला:

• Codex ने त्यांची बहुतेक रहदारी वेगाने WebSockets वर हलवली. GPT‑5.3‑Codex⁠(नवीन विंडोमध्ये उघडेल) सारखी नवीन मॉडेल्स वापरणारे Codex वापरकर्ते, GPT‑5.4⁠(नवीन विंडोमध्ये उघडेल), आणि त्यापलीकडेही WebSocket mode च्या वेगवाढीचा लाभ मिळतो.
• Vercel ने AI SDK मध्ये WebSocket मोड समाकलित केला आणि विलंब 40% पर्यंत⁠(नवीन विंडोमध्ये उघडेल) कमी झाला.
• Cline चे बहु-फाइल कार्यप्रवाह 39% अधिक जलद आहेत⁠(नवीन विंडोमध्ये उघडेल).
• Cursor मधील OpenAI मॉडेल्स 30% पर्यंत अधिक जलद झाले⁠(नवीन विंडोमध्ये उघडेल).

मार्च 2025 मध्ये लॉन्च झाल्यापासून, WebSocket mode हे Responses API मधील सर्वात महत्त्वपूर्ण नवीन क्षमतांपैकी एक आहे. OpenAI च्या API आणि Codex टीम्समधील घनिष्ठ सहकार्यामुळे आम्ही केवळ काही आठवड्यांत कल्पनेपासून प्रॉडक्शनमध्ये Go करण्यापर्यंतचा प्रवास केला. यामुळे एजंट रोलआउट विलंबात केवळ लक्षणीय सुधारणा होत नाही, तर बिल्डर्सच्या वाढत्या गरजेलाही ते समर्थन देते: मॉडेल इन्फरन्स अधिक वेगवान होत असताना, या वाढीव फायद्यांचा वापरकर्त्यांपर्यंत पोहोचवण्यासाठी इन्फरन्सभोवतीच्या सेवा आणि प्रणालींनाही अधिक वेगवान होणे आवश्यक आहे.