Responses API માં WebSockets સાથે એજન્ટિક વર્કફ્લો ઝડપથી ચલાવવું

જ્યારે તમે Codex ને બગ ઠીક કરવા કહો છો, ત્યારે તે સંબંધિત ફાઇલો માટે તમારા કોડબેઝમાં શોધ કરે છે, સંદર્ભ બનાવવા માટે તેમને વાંચે છે, ફેરફારો કરે છે અને સુધારો કાર્યરત રહ્યો છે તેની ખાતરી કરવા ટેસ્ટ ચલાવે છે. અંદરથી જુઓ તો, તેનો અર્થ થાય છે Responses API માટે ડઝનેક આગળ-પાછળ વિનંતીઓ: મોડલની આગલી ક્રિયા નક્કી કરવી, તમારા કમ્પ્યુટર પર ટૂલ ચલાવવું, ટૂલનું આઉટપુટ પાછું API ને મોકલવું અને આ ક્રમને દોહરાવવો.

આ બધી વિનંતીઓ મળીને એવા મિનિટોમાં ફેરવાઈ શકે છે જેમાં વપરાશકર્તાઓ Codex જટિલ કાર્યો પૂર્ણ કરે તેની રાહ જુએ છે. લેટન્સીના દૃષ્ટિકોણથી, Codex એજન્ટ લૂપ પોતાનો મોટાભાગનો સમય ત્રણ મુખ્ય તબક્કાઓમાં વિતાવે છે: API સેવાઓમાં કામ (વિનંતીઓ માન્ય કરવા અને પ્રક્રિયા કરવા), મોડલ ઇન્ફરન્સ અને ક્લાયન્ટ-સાઇડ સમય (ટૂલ ચલાવવી અને મોડલ સંદર્ભ બનાવવો). ઇન્ફરન્સ એ તબક્કો છે જ્યાં મોડલ નવા ટોકન જનરેટ કરવા GPUs પર ચાલે છે. અગાઉ, GPUs પર LLM ઇન્ફરન્સ ચલાવવું એ એજન્ટિક લૂપનો સૌથી ધીમો ભાગ હતો, તેથી API સેવા ઓવરહેડ છુપાવવો સરળ હતો. જેમ ઇન્ફરન્સ વધુ ઝડપી બને છે, તેમ એજન્ટિક રોલઆઉટમાંથી થતો કુલ API ઓવરહેડ ઘણો વધુ નોંધપાત્ર બને છે.

આ પોસ્ટમાં, અમે સમજાવીશું કે API વાપરતા એજન્ટ લૂપને અમે એન્ડ-ટુ-એન્ડ 40% ઝડપી કેવી રીતે બનાવ્યા, જેથી વપરાશકર્તાઓ 65 થી લગભગ 1,000 ટોકન પ્રતિ સેકન્ડની ઇન્ફરન્સ ગતિમાં થયેલી છલાંગનો અનુભવ કરી શકે. અમે આ માટે કેશિંગ, અનાવશ્યક નેટવર્ક હોપ્સ દૂર કરવા, અમારા સેફ્ટી સ્ટેકમાં સુધારાઓ કરીને સમસ્યાઓને ઝડપથી ફ્લેગ કરવા અને—સૌથી મહત્વપૂર્ણ—સિંક્રોનસ API કૉલ્સની શ્રેણી કરવાની જરૂરિયાતને બદલે Responses API સાથે સ્થાયી કનેક્શન બનાવવાનો માર્ગ તૈયાર કર્યો.

Responses API માં, GPT‑5 અને GPT‑5.2 જેવા અગાઉના ફ્લેગશિપ મોડેલ્સ લગભગ 65 ટોકન પ્રતિ સેકન્ડ (TPS)ની ગતિએ ચાલતા હતા. ઝડપી કોડિંગ મોડલ GPT‑5.3‑Codex‑Spark ના લોન્ચ માટે, અમારું લક્ષ્ય દસ ગણું ઝડપી હતું: 1,000 TPS થી વધુ, જે LLM ઇન્ફરન્સ માટે ઑપ્ટિમાઇઝ કરાયેલા વિશિષ્ટ Cerebras હાર્ડવેર દ્વારા શક્ય બન્યું. વપરાશકર્તાઓ આ નવા મોડલની સાચી ઝડપ અનુભવી શકે તે માટે, અમારે API ઓવરહેડ ઘટાડવો પડ્યો.

2025ના નવેમ્બર આસપાસ, અમે Responses API પર પરફોર્મન્સ સ્પ્રિન્ટ શરૂ કરી, જેમાં એક જ વિનંતીની ક્રિટિકલ-પાથ લેટન્સી માટે ઘણા ઑપ્ટિમાઇઝેશન અમલમાં મુક્યા:

• મલ્ટી-ટર્ન પ્રતિસાદો માટે ખર્ચાળ ટોકનાઇઝેશન અને નેટવર્ક કૉલ્સ ટાળવા મેમરીમાં રેન્ડર કરેલા ટોકન અને મોડલ કન્ફિગરેશનનું કેશિંગ
• મધ્યવર્તી સેવાઓને કૉલ્સ દૂર કરીને નેટવર્ક હોપ લેટન્સી ઘટાડવી (ઉદાહરણ તરીકે, ઇમેજ પ્રોસેસિંગ રિઝોલ્યુશન) અને સીધા ઇન્ફરન્સ સેવાને જ કૉલ કરવી
• અમારા સેફ્ટી સ્ટેકમાં સુધારો જેથી અમુક ક્લાસિફાયર વધુ ઝડપથી વાતચીતોને ફ્લેગ કરી શકે

આ સુધારાઓ સાથે, અમને time to first token (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 લેટન્સી માટે શું શક્ય છે તે વિશેની અમારી ધારણા બદલી નાખી. API સ્ટેકમાં ઊંડો અનુભવ ધરાવતા Codex ટીમના એક ઇજનેરે Codex એજન્ટને આખી રાત ચલાવીને એક પ્રોટોટાઇપ તૈયાર કર્યો.

તે પ્રોટોટાઇપમાં, એજન્ટિક રોલઆઉટ્સને એક જ લાંબા સમય સુધી ચાલતા Response તરીકે મોડેલ કરવામાં આવ્યા. asyncio સુવિધાઓનો ઉપયોગ કરીને, ટૂલ કૉલ સેમ્પલ થયા પછી Responses API સેમ્પલિંગ લૂપમાં અસંક્રિય રીતે બ્લોક થતું, અને Responses API ક્લાયન્ટને પાછું response.done ઇવેન્ટ મોકલતું. ટૂલ કૉલ ચલાવ્યા પછી, ક્લાયન્ટ્સ ટૂલ પરિણામ સાથે પાછું response.append ઇવેન્ટ મોકલતા, જે સેમ્પલિંગ લૂપને અનબ્લોક કરીને મોડલને આગળ ચાલુ રાખવા દેતું.

અહીં એક સરખામણી એ છે કે સ્થાનિક ટૂલ કૉલને hosted tool call તરીકે જોવું. જ્યારે મોડલ web search કૉલ કરે છે, ત્યારે ઇન્ફરન્સ લૂપ બ્લોક થાય છે, web search સેવા કૉલ કરે છે અને સેવાનો પ્રતિભાવ મોડલ સંદર્ભમાં મૂકે છે. અમારા ડિઝાઇનમાં, અમે આ જ કામ કર્યું; પણ રિમોટ સેવા કૉલ કરવા બદલે, અમે મોડલનો ટૂલ કૉલ WebSocket પર પાછો ક્લાયન્ટને મોકલ્યો. જ્યારે ક્લાયન્ટે પ્રતિભાવ આપ્યો, ત્યારે અમે ક્લાયન્ટનો ટૂલ કૉલ પ્રતિભાવ સંદર્ભમાં મૂક્યો અને સેમ્પલિંગ ચાલુ રાખ્યું.

આ ડિઝાઇન અત્યંત અસરકારક હતી કારણ કે તેણે એજન્ટ રોલઆઉટ દરમિયાન વારંવાર થતું API કામ દૂર કર્યું. અમે preinference કામ એકવાર કરી શકતા, ટૂલ એક્ઝિક્યુશન માટે થોભી શકતા અને અંતે postinference કામ એકવાર કરી શકતા.

દુર્ભાગ્યે, તેની કિંમત ઓછી ઓળખાણવાળા અને વધુ જટિલ API આકારના રૂપમાં આવી. અમે ઇચ્છતા હતા કે ડેવલપર્સ નવી ઇન્ટરૅક્શન પદ્ધતિને આધારે આખી API ઇન્ટિગ્રેશન ફરીથી લખ્યા વિના WebSocket સપોર્ટ સીધો અપનાવી શકે.

અમે લોન્ચ કરેલી આવૃત્તિ માટે, અમે ફરી પરિચિત આકાર અપનાવ્યો: એ જ બોડી સાથે response.create નો ઉપયોગ ચાલુ રાખવો, અને અગાઉના response ની સ્ટેટમાંથી વાતચીતનો સંદર્ભ આગળ વધારવા previous_response_id નો ઉપયોગ કરવો.

WebSocket કનેક્શન પર, સર્વર અગાઉની response સ્ટેટનો કનેક્શન-સ્કોપવાળો, ઇન-મેમરી કેશ જાળવે છે. જ્યારે અનુગામી response.create માં previous_response_id શામેલ હોય, ત્યારે અમે સંપૂર્ણ વાતચીત ફરીથી શરૂથી બાંધવાના બદલે તે સ્ટેટ કેશમાંથી લવીએ છીએ.

તે કેશ કરેલી સ્ટેટમાં આ શામેલ છે:

• અગાઉનું response ઑબ્જેક્ટ
• અગાઉના ઇનપુટ અને આઉટપુટ આઇટમ્સ
• ટૂલ ડિફિનિશન અને નેમસ્પેસ
• ફરી વાપરી શકાય તેવી સેમ્પલિંગ આર્ટિફેક્ટ્સ, જેમ કે અગાઉ રેન્ડર કરેલા ટોકન

ઇન-મેમરી અગાઉની response સ્ટેટને ફરી વાપરીને, અમે કેટલાક મોટા ઑપ્ટિમાઇઝેશન્સ અમલમાં મૂકી શક્યા:

• અમારા કેટલાક સેફ્ટી ક્લાસિફાયર અને રિક્વેસ્ટ વેલિડેટર્સને દરેક વખતે સંપૂર્ણ ઇતિહાસને બદલે માત્ર નવી ઇનપુટ જ પ્રોસેસ કરાવે તેવી વ્યવસ્થા કરવી
• રેન્ડર કરેલા ટોકનનો ઇન-મેમરી કેશ રાખવો, જેમાં અમે ઉમેરો કરતા જઈએ જેથી અનાવશ્યક ટોકનાઇઝેશન ટાળી શકાય
• વિનંતીઓ વચ્ચે અમારી સફળ મોડલ રિઝોલ્યુશન/રાઉટિંગ લોજિકને ફરી વાપરવી
• બિલિંગ જેવા non-blocking postinference કામને અનુગામી વિનંતીઓ સાથે ઓવરલૅપ કરવું

લક્ષ્ય એ હતું કે ડેવલપર્સ જે API આકાર પહેલેથી સમજે છે અને જેને ધ્યાનમાં રાખીને બનાવી ચૂક્યા છે, તે જાળવી રાખીને ઓછામાં ઓછા ઓવરહેડવાળા પ્રોટોટાઇપની શક્ય તેટલી નજીક પહોંચી શકાય.

WebSocket મોડ બનાવવાની બે મહિનાની સ્પ્રિન્ટ બાદ, અમે મુખ્ય કોડિંગ એજન્ટ સ્ટાર્ટઅપ્સ સાથે એક અલ્ફા લોન્ચ કર્યો જેથી તેઓ તેને પોતાની ઇન્ફ્રાસ્ટ્રક્ચરમાં ઇન્ટિગ્રેટ કરી શકે અને ટ્રાફિકને સુરક્ષિત રીતે ધીમે ધીમે વધારી શકે. અલ્ફા વપરાશકર્તાઓએ તેને ખૂબ પસંદ કર્યું અને તેમના એજન્ટિક વર્કફ્લોમાં 40% સુધીનો સુધારો⁠(નવી વિન્ડોમાં ખૂલે છે) નોંધાવ્યો. સકારાત્મક અલ્ફા પ્રતિસાદને ધ્યાનમાં લઈને, અમે લોન્ચ માટે તૈયાર હતા.

લોન્ચના પરિણામો તરત જ દેખાયા. Codex એ ઝડપથી તેમના Responses API ટ્રાફિકનો મોટો ભાગ WebSocket મોડ પર ખસેડ્યો અને લેટન્સીમાં નોંધપાત્ર સુધારો જોયો. GPT‑5.3‑Codex‑Spark માટે, અમે 1,000 TPS નું લક્ષ્ય હાંસલ કર્યું અને 4,000 TPS સુધીના બર્સ્ટ્સ જોયા, જે દર્શાવે છે કે Responses API વાસ્તવિક પ્રોડક્શન ટ્રાફિકમાં ઘણી વધુ ઝડપી ઇન્ફરન્સ સાથે ગતિ રાખી શકે છે. તેનો પ્રભાવ ડેવલપર સમુદાયમાં પણ ઝડપથી જોવા મળ્યો:

• Codex એ ઝડપથી તેમનો મોટાભાગનો ટ્રાફિક WebSockets પર ખસેડ્યો. GPT‑5.3‑Codex⁠(નવી વિન્ડોમાં ખૂલે છે), GPT‑5.4⁠(નવી વિન્ડોમાં ખૂલે છે) અને આગળના તાજા મોડલ્સ ચલાવતા Codex વપરાશકર્તાઓને WebSocket મોડની ઝડપનો લાભ મળે છે.
• Vercel એ AI SDK માં WebSocket મોડ ઇન્ટિગ્રેટ કર્યો અને લેટન્સીમાં 40% સુધીનો ઘટાડો⁠(નવી વિન્ડોમાં ખૂલે છે) જોયો.
• Cline ના multi-file workflows 39% ઝડપી⁠(નવી વિન્ડોમાં ખૂલે છે) બન્યા.
• Cursor માં OpenAI મોડલ્સ 30% સુધી ઝડપી⁠(નવી વિન્ડોમાં ખૂલે છે) બન્યા.

માર્ચ 2025 માં લોન્ચ થયા બાદથી WebSocket મોડ Responses API ની સૌથી મહત્વપૂર્ણ નવી ક્ષમતાઓમાંની એક છે. OpenAI ની API અને Codex ટીમો વચ્ચેના નજીકના સહકારથી અમે વિચારથી લઈને માત્ર થોડા અઠવાડિયામાં પ્રોડક્શનમાં ચલતી વ્યવસ્થા સુધી પહોંચી ગયા. તે માત્ર એજન્ટ રોલઆઉટ લેટન્સીમાં ભારે સુધારો કરતું નથી, પરંતુ બિલ્ડર્સની વધતી જરૂરિયાતને પણ સમર્થન આપે છે: જેમ મોડલ ઇન્ફરન્સ વધુ ઝડપી બને છે, તેમ ઇન્ફરન્સને ઘેરતી સેવાઓ અને સિસ્ટમ્સને પણ આ લાભો વપરાશકર્તાઓ સુધી પહોંચાડવા માટે ઝડપ વધારવી પડે છે.