Responses API-യിൽ WebSockets ഉപയോഗിച്ച് ഏജന്റിക് വർക്ക്‌ഫ്ലോകൾ വേഗത്തിലാക്കൽ

നിങ്ങൾ Codex-നോട് ഒരു ബഗ് പരിഹരിക്കാൻ ആവശ്യപ്പെടുമ്പോൾ, അത് ബന്ധപ്പെട്ട ഫയലുകൾക്കായി നിങ്ങളുടെ കോഡ്ബേസ് സ്കാൻ ചെയ്യുകയും, സന്ദർഭം മനസ്സിലാക്കാൻ അവ വായിക്കുകയും, തിരുത്തലുകൾ നടത്തുകയും, പരിഹാരം പ്രവർത്തിച്ചതാണെന്ന് സ്ഥിരീകരിക്കാൻ ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നു. ആന്തരികമായി നോക്കുമ്പോൾ, അതിന്റെ അർത്ഥം ഡസൻ കണക്കിന് അങ്ങോട്ടും ഇങ്ങോട്ടുമായ Responses API അഭ്യർത്ഥനകളാണ്: മോഡലിന്റെ അടുത്ത പ്രവർത്തനം നിർണയിക്കുക, നിങ്ങളുടെ കമ്പ്യൂട്ടറിൽ ഒരു ടൂൾ പ്രവർത്തിപ്പിക്കുക, ടൂളിന്റെ ഔട്ട്പുട്ട് API-യിലേക്ക് തിരികെ അയയ്ക്കുക, തുടർന്ന് ഇത് ആവർത്തിക്കുക.

ഈ എല്ലാ അഭ്യർത്ഥനകളും ചേർന്ന്, സങ്കീർണ്ണമായ ടാസ്കുകൾ Codex പൂർത്തിയാക്കുന്നതിന് ഉപയോക്താക്കൾ കാത്തിരിക്കേണ്ട മിനിറ്റുകൾ വർദ്ധിപ്പിക്കാം. ലേറ്റൻസിയുടെ കാഴ്ചപ്പാടിൽ, Codex ഏജന്റ് ലൂപ്പ് തന്റെ സമയത്തിന്റെ ഭൂരിഭാഗവും മൂന്ന് പ്രധാന ഘട്ടങ്ങളിലാണ് ചെലവഴിക്കുന്നത്: API സേവനങ്ങളിൽ പ്രവർത്തിക്കുന്നത് (അഭ്യർത്ഥനകൾ സാധൂകരിക്കാനും പ്രോസസ് ചെയ്യാനും), മോഡൽ ഇൻഫറൻസ്, ക്ലയന്റ്-സൈഡ് സമയം (ടൂളുകൾ പ്രവർത്തിപ്പിക്കുകയും മോഡൽ കോൺടെക്സ്റ്റ് നിർമ്മിക്കുകയും ചെയ്യുന്നത്). പുതിയ ടോക്കണുകൾ സൃഷ്ടിക്കാൻ GPU-കളിൽ മോഡൽ പ്രവർത്തിക്കുന്ന ഘട്ടമാണ് ഇൻഫറൻസ്. മുൻപ്, GPU-കളിൽ LLM ഇൻഫറൻസ് പ്രവർത്തിപ്പിക്കുന്നത് ഏജന്റിക് ലൂപ്പിലെ ഏറ്റവും മന്ദഗതിയിലുള്ള ഭാഗമായിരുന്നു, അതിനാൽ API സേവന ഓവർഹെഡ് എളുപ്പത്തിൽ മറച്ചുവെക്കാനാകുമായിരുന്നു. ഇൻഫറൻസ് കൂടുതൽ വേഗത്തിലാകുന്നതോടെ, ഏജന്റിക് റോൾഔട്ടിൽ നിന്നുള്ള സഞ്ചിത API ഓവർഹെഡ് കൂടുതൽ ശ്രദ്ധേയമാകുന്നു.

ഈ പോസ്റ്റിൽ, API ഉപയോഗിച്ച് ഞങ്ങൾ ഏജന്റ് ലൂപ്പുകൾ എങ്ങനെ എൻഡ്-ടു-എൻഡ് 40% വേഗത്തിലാക്കി എന്നത് വിശദീകരിക്കുന്നു. ഇതിലൂടെ, ഇൻഫറൻസ് വേഗത 65-ൽ നിന്ന് ഏകദേശം 1,000 ടോക്കൺ വരെ ഉയർന്നത് ഉപയോക്താക്കൾക്ക് അനുഭവിക്കാൻ സാധിക്കും. ഞങ്ങൾ ഇത് കാഷിംഗ് ഉപയോഗിച്ചും, അനാവശ്യമായ നെറ്റ്‌വർക്ക് ഇടനില ഘട്ടങ്ങൾ ഒഴിവാക്കിയും, പ്രശ്നങ്ങൾ വേഗത്തിൽ ഫ്ലാഗ് ചെയ്യുന്നതിനായി ഞങ്ങളുടെ സേഫ്റ്റി സ്റ്റാക്ക് മെച്ചപ്പെടുത്തിയും, Responses API-യിലേക്ക് ഒരു സ്ഥിരമായ കണക്ഷൻ സൃഷ്ടിക്കുന്ന ഒരു മാർഗം നിർമ്മിച്ചുമാണ് സമീപിച്ചത്.

Responses API-യിൽ, GPT‑5, GPT‑5.2 പോലുള്ള മുൻ ഫ്ലാഗ്ഷിപ്പ് മോഡലുകൾ ഏകദേശം ഒരു സെക്കന്ഡിന് 65 ടോക്കൺ (TPS) വേഗത്തിൽ പ്രവർത്തിച്ചു. വേഗമേറിയ കോഡിംഗ് മോഡലായ GPT‑5.3‑Codex‑Spark‑ന്റെ ലോഞ്ചിനായി, ഞങ്ങളുടെ ലക്ഷ്യം വളരെ കൂടുതൽ വേഗതയുള്ള ഒരു ഓർഡർ ഓഫ് മാഗ്നിട്യൂഡ് കൈവരിക്കുകയായിരുന്നു: LLM ഇൻഫറൻസിനായി ഒപ്റ്റിമൈസ് ചെയ്ത പ്രത്യേക Cerebras ഹാർഡ്‌വെയർ ഉപയോഗിച്ച്1,000 TPS-നു മുകളിൽ. ഉപയോക്താക്കൾക്ക് ഈ പുതിയ മോഡലിന്റെ യഥാർത്ഥ വേഗത അനുഭവിക്കാൻ കഴിയുമെന്ന് ഉറപ്പാക്കാൻ, API ഓവർഹെഡ് കുറയ്ക്കേണ്ടിവന്നു. 

2025 നവംബർ മാസത്തോടെ, Responses API-യിൽ ഞങ്ങൾ ഒരു പ്രകടന മെച്ചപ്പെടുത്തൽ സ്പ്രിന്റ് ആരംഭിച്ചു, ഒറ്റ അഭ്യർത്ഥനയ്ക്കുള്ള ക്രിറ്റിക്കൽ-പാത്ത് ലാറ്റൻസിക്കായി നിരവധി ഒപ്റ്റിമൈസേഷനുകൾ നടപ്പിലാക്കി: 

• മൾട്ടി-ടേൺ പ്രതികരണങ്ങൾക്കായി ചെലവേറിയ ടോക്കനൈസേഷനും നെറ്റ്‌വർക്ക് കോളുകളും ഒഴിവാക്കുന്നതിനായി റെൻഡർ ചെയ്ത ടോക്കണുകളും മോഡൽ കോൺഫിഗറേഷനും മെമ്മറിയിൽ കാഷ് ചെയ്യൽ
• ഇടനില സേവനങ്ങളിലേക്കുള്ള കോളുകൾ (ഉദാഹരണത്തിന്, ഇമേജ് പ്രോസസ്സിംഗ് റെസല്യൂഷൻ) ഒഴിവാക്കി ഇൻഫറൻസ് സേവനത്തെ തന്നെ നേരിട്ട് വിളിക്കുന്നതിലൂടെ നെറ്റ്‌വർക്ക് ഹോപ്പ് ലേറ്റൻസി കുറയ്ക്കൽ
• ചില ക്ലാസിഫയറുകൾ പ്രവർത്തിപ്പിച്ച് സംഭാഷണങ്ങൾ കൂടുതൽ വേഗത്തിൽ ഫ്ലാഗ് ചെയ്യാൻ കഴിയുന്നവിധം ഞങ്ങളുടെ സുരക്ഷാ സ്റ്റാക്ക് മെച്ചപ്പെടുത്തൽ

ഈ മെച്ചപ്പെടുത്തലുകളോടെ, ആദ്യ ടോക്കൺ ലഭിക്കാൻ എടുക്കുന്ന സമയത്തിൽ (TTFT) ഏകദേശം 45% മെച്ചപ്പെടുത്തൽ ഞങ്ങൾ കണ്ടു—ഇത് API എത്ര പ്രതികരണശേഷിയുള്ളതായി അനുഭവപ്പെടുന്നു എന്ന് പ്രതിഫലിപ്പിക്കുന്നു—എന്നാൽ ഈ മെച്ചപ്പെടുത്തലുകൾ GPT‑5.3‑Codex‑Spark‑നായി ഇപ്പോഴും മതിയായ വേഗത്തിലായിരുന്നില്ല. ഈ മെച്ചപ്പെടുത്തലുകൾ ഉണ്ടായിരുന്നിട്ടും, മോഡലിന്റെ വേഗതയുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ Responses API ഓവർഹെഡ് വളരെ കൂടുതലായിരുന്നു—അതായത്, മുൻപ് ഉപയോക്താക്കൾക്ക് മോഡലിനെ സേവനം ചെയ്യുന്ന GPU-കൾ ഉപയോഗിക്കാൻ ഞങ്ങളുടെ API പ്രവർത്തിപ്പിക്കുന്ന CPU-കൾക്കായി കാത്തിരിക്കേണ്ടിവന്നു.

കൂടുതൽ ആഴത്തിലുള്ള പ്രശ്നം ഘടനാപരമായതായിരുന്നു: ഓരോ Codex അഭ്യർത്ഥനയെയും സ്വതന്ത്രമായതായി കണക്കാക്കി, ഓരോ തുടർ അഭ്യർത്ഥനയിലും സംഭാഷണത്തിന്റെ നിലയും വീണ്ടും ഉപയോഗിക്കാവുന്ന മറ്റ് സന്ദർഭങ്ങളും പ്രോസസ്സ് ചെയ്തു. സംഭാഷണത്തിന്റെ ഭൂരിഭാഗവും മാറിയിരുന്നില്ലെങ്കിലും, മുഴുവൻ ചരിത്രവുമായി ബന്ധപ്പെട്ട ജോലിക്കായി ഞങ്ങൾ ഇപ്പോഴും പണം നൽകി. സംഭാഷണങ്ങൾ ദൈർഘ്യമേറിയതോടെ, ആ ആവർത്തിച്ചുള്ള പ്രോസസ്സിംഗ് കൂടുതൽ ചെലവേറിയതായി മാറി.

ഡിസൈൻ കൂടുതൽ മെച്ചപ്പെടുത്താൻ, ഞങ്ങൾ ട്രാൻസ്‌പോർട്ട് പ്രോട്ടോക്കോൾ പുനഃപരിശോധിച്ചു: HTTP വഴി ഓരോ ഫോളോ-അപ്പ് അഭ്യർത്ഥനയ്ക്കും പുതിയൊരു കണക്ഷൻ സ്ഥാപിച്ച് മുഴുവൻ സംഭാഷണ ചരിത്രവും അയയ്ക്കുന്നതിനുപകരം, സ്ഥിരമായ ഒരു കണക്ഷൻ നിലനിർത്തുകയും കാഷെ സ്റ്റേറ്റ് സൂക്ഷിക്കുകയും ചെയ്യാമോ എന്ന് പരിശോധിച്ചു. സാധൂകരിക്കലും പ്രോസസ്സിംഗും ആവശ്യമായ പുതിയ വിവരങ്ങൾ മാത്രം അയയ്ക്കുകയും, വീണ്ടും ഉപയോഗിക്കാവുന്ന സ്റ്റേറ്റ് കണക്ഷൻ നിലനിൽക്കുന്ന മുഴുവൻ സമയത്തേക്ക് മെമ്മറിയിൽ കാഷ് ചെയ്യുകയും ചെയ്യുക എന്നതായിരുന്നു ആശയം. ഇത് ആവർത്തനമായ ജോലികളിൽ നിന്നുള്ള അധികഭാരം കുറയ്ക്കും.

WebSockets ഉം gRPC ബൈഡയറക്ഷണൽ സ്ട്രീമിംഗും ഉൾപ്പെടെ, ചില വ്യത്യസ്ത സമീപനങ്ങൾ ഞങ്ങൾ പരിഗണിച്ചു. സന്ദേശങ്ങൾ കൈമാറുന്നതിനുള്ള ലളിതമായ ഒരു പ്രോട്ടോക്കോൾ എന്ന നിലയിൽ, ഉപയോക്താക്കൾക്ക് അവരുടെ Responses API-യുടെ input, output ഘടനകൾ മാറ്റേണ്ടിവരില്ലാത്തതിനാലാണ് ഞങ്ങൾ WebSockets തിരഞ്ഞെടുത്തത്. ഇത് ഡെവലപ്പർ-സൗഹൃദപരമായിരുന്നു, കൂടാതെ വളരെ കുറച്ച് തടസ്സങ്ങളോടെ ഞങ്ങളുടെ നിലവിലുള്ള ആർക്കിടെക്ചറുമായി യോജിച്ചു.

ആദ്യത്തെ WebSocket പ്രോട്ടോടൈപ്പ് Responses API ലേറ്റൻസിയെക്കുറിച്ച് ഞങ്ങളുടെ ധാരണയെ മാറ്റിമറിച്ചു. API സ്റ്റാക്കിൽ ആഴത്തിലുള്ള വൈദഗ്ധ്യമുള്ള Codex ടീമിലെ ഒരു എഞ്ചിനീയർ, 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 ഉൾപ്പെടുമ്പോൾ, മുഴുവൻ സംഭാഷണവും ആദ്യം മുതൽ വീണ്ടും നിർമ്മിക്കുന്നതിനുപകരം, ആ നില കാഷിൽ നിന്ന് ഞങ്ങൾ ലഭ്യമാക്കുന്നു.

ആ കാഷ് ചെയ്ത അവസ്ഥയിൽ ഉൾപ്പെടുന്നത്:

• മുൻപത്തെ പ്രതികരണ ഒബ്ജക്റ്റ്
• മുൻപത്തെ ഇൻപുട്ട്, ഔട്ട്പുട്ട് ഇനങ്ങൾ
• ടൂൾ നിർവചനങ്ങളും നെയിംസ്പേസുകളും
• മുൻപ് റെൻഡർ ചെയ്ത ടോക്കൺ പോലുള്ള പുനരുപയോഗിക്കാവുന്ന സാമ്പ്ലിംഗ് ആർട്ടിഫാക്റ്റുകൾ

മെമ്മറിയിൽ സൂക്ഷിച്ചിരുന്ന മുൻ പ്രതികരണത്തിന്റെ നില വീണ്ടും ഉപയോഗിച്ചതിലൂടെ, നിരവധി പ്രധാന മെച്ചപ്പെടുത്തലുകൾ നേടാൻ ഞങ്ങൾക്ക് സാധിച്ചു:

• ഞങ്ങളുടെ ചില സുരക്ഷാ ക്ലാസിഫയറുകളും അഭ്യർത്ഥന വാലിഡേറ്ററുകളും ഓരോ തവണയും മുഴുവൻ ചരിത്രം പ്രോസസ് ചെയ്യാതെ, പുതിയ ഇൻപുട്ട് മാത്രം പ്രോസസ് ചെയ്യുന്നതാക്കൽ
• അനാവശ്യമായ ടോക്കനൈസേഷൻ ഒഴിവാക്കാൻ, കൂട്ടിച്ചേർക്കുന്ന റെൻഡർ ചെയ്ത ടോക്കണുകളുടെ ഇൻ-മെമ്മറി കാഷ് നിലനിർത്തുന്നു
• അഭ്യർത്ഥനകളിലുടനീളം ഞങ്ങളുടെ വിജയകരമായ മോഡൽ റെസല്യൂഷൻ/റൂട്ടിംഗ് ലോജിക് പുനരുപയോഗിക്കൽ 
• തുടർന്നുള്ള അഭ്യർത്ഥനകളുമായി ബില്ലിംഗ് പോലുള്ള ബ്ലോക്ക് ചെയ്യാത്ത ഇൻഫറൻസിന് ശേഷമുള്ള പ്രവർത്തനങ്ങൾ ഓവർലാപ്പ് ചെയ്യൽ

ലക്ഷ്യം ഏറ്റവും കുറഞ്ഞ ഓവർഹെഡുള്ള പ്രോട്ടോടൈപ്പിനോട് കഴിയുന്നത്ര അടുത്തതായി എത്തുക എന്നതായിരുന്നു, എന്നാൽ അതോടൊപ്പം ഡെവലപ്പർമാർ ഇതിനകം മനസ്സിലാക്കി അതിന്റെ അടിസ്ഥാനത്തിൽ നിർമ്മിച്ച 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 mode-ന്റെ വേഗവർദ്ധനയിൽ നിന്ന് പ്രയോജനം ലഭിക്കുന്നു.
• Vercel WebSocket മോഡ് AI SDK-ലേക്ക് സംയോജിപ്പിക്കുകയും ലേറ്റൻസി 40% വരെ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) കുറയുന്നതായി കണ്ടെത്തുകയും ചെയ്തു.
• Cline-ന്റെ മൾട്ടി-ഫയൽ പ്രവാഹങ്ങൾ 39% കൂടുതൽ വേഗതയുള്ളതാണ്⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു).
• കഴ്‌സറിലെ OpenAI മോഡൽ പരമാവധി 30% വരെ വേഗത്തിലായി⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു).

2025 മാർച്ചിൽ ലോഞ്ച് ചെയ്തതിനുശേഷം, Responses API-യിലെ ഏറ്റവും പ്രധാനപ്പെട്ട പുതിയ കഴിവുകളിൽ ഒന്നാണ് WebSocket mode. OpenAI-യുടെ API, Codex ടീമുകൾ തമ്മിലുള്ള അടുത്ത സഹകരണത്തിലൂടെ, വെറും ഏതാനും ആഴ്ചകൾക്കുള്ളിൽ ഞങ്ങൾ ആശയത്തിൽ നിന്ന് പ്രൊഡക്ഷനിൽ പ്രവർത്തിക്കുന്ന നിലയിലേക്ക് എത്തി. ഇത് ഏജന്റ് റോൾഔട്ട് ലേറ്റൻസിയെ നാടകീയമായി മെച്ചപ്പെടുത്തുന്നതിന് പുറമെ, ഡെവലപ്പർമാർക്കുള്ള വർദ്ധിച്ചുവരുന്ന ഒരു ആവശ്യത്തെയും പിന്തുണയ്ക്കുന്നു: മോഡൽ ഇൻഫറൻസ് കൂടുതൽ വേഗത്തിലാകുമ്പോൾ, ഈ നേട്ടങ്ങൾ ഉപയോക്താക്കൾക്ക് കൈമാറുന്നതിനായി ഇൻഫറൻസിനെ ചുറ്റിപ്പറ്റിയിരിക്കുന്ന സേവനങ്ങളും സിസ്റ്റങ്ങളും കൂടി വേഗത്തിലാകേണ്ടതുണ്ട്.