Responses API-யில் WebSockets பயன்படுத்தி agentic workflows-ஐ வேகப்படுத்துதல்

நீங்கள் Codex-க்கு ஒரு பிழையை சரிசெய்யச் சொன்னால், அது தொடர்புடைய கோப்புகளைத் தேடி உங்கள் குறியீட்டுத் தளத்தை ஸ்கேன் செய்து, சூழலை உருவாக்க அவற்றைப் படித்து, அவற்றைப் படித்து சூழலைப் புரிந்துகொண்டு, தேவையான மாற்றங்களைச் செய்து, அந்த சரிசெய்தல் செயல்பட்டதா என்பதை உறுதிப்படுத்த சோதனைகளை இயக்கும். இதன் பின்னணியில், Responses API மூலம் டஜன் கணக்கான கொடுக்கல்-வாங்கல் கோரிக்கைகள் நடைபெறுகின்றன: மாடலின் அடுத்தக்கட்ட நடவடிக்கை என்ன என்பதைத் தீர்மானித்தல், உங்கள் கணினியில் ஒரு கருவியை இயக்குதல், அந்தக் கருவியின் முடிவை மீண்டும் API-க்கு அனுப்புதல் என இந்தச் செயல்முறை மீண்டும் மீண்டும் மாடல்தொடர்கிறது.

இந்த எல்லா கோரிக்கைகளும் சேர்ந்து, Codex கடினமான பணிகளை முடிக்க பயனர்கள் நிமிடங்கள் வரை காத்திருக்க வேண்டிய நிலையை உருவாக்கலாம். தாமத கோணத்தின அடிப்படையில் பார்த்தால், Codex ஏஜெண்ட் தனது அதிகப்படியான நேரத்தை மூன்று முக்கிய நிலைகளில் செலவிடுகிறது:  API சேவைகளில் செயல்படுதல் (கோரிக்கைகளைச் சரிபார்க்கவும் செயலாக்கவும்), மாதிரியின் அனுமானம், மற்றும் கிளையண்ட்-பக்க நேரம் (கருவிகளை இயக்குதல் மற்றும் மாதிரிக்கான சூழலை உருவாக்குதல்). இன்ஃபரன்ஸ் என்பது மாடல் GPU-களில் இயங்கி புதிய டோக்கன்-ஐ உருவாக்கும் கட்டமாகும். கடந்த காலங்களில், 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 இன்ஃபரன்ஸிற்காகவே பிரத்யேகமாக உருவாக்கப்பட்ட செரிப்ராஸ் வன்பொருள் மூலம் சாத்தியமானது. பயனர்கள் இந்த புதிய மாடலின் உண்மையான வேகத்தை அனுபவிப்பதை உறுதிசெய்ய, நாங்கள் 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-ன் தாமத நேரத்தைப் பொறுத்தவரை எங்களது எதிர்பார்ப்புகளையும் சாத்தியக்கூறுகளையும் முற்றிலுமாக மாற்றியமைத்தது. API கட்டமைப்பில் ஆழ்ந்த நிபுணத்துவம் கொண்ட Codex குழுவின் பொறியாளர் ஒருவர், ஒரு Codexagent-ஐ இரவு முழுவதும் இயக்குவதன் மூலம் அதன் முன்மாதிரியை உருவாக்கினார்.

அந்த முன்மாதிரியில், ஏஜென்டிக் ரோல்-அவுட்கள்ஒரே ஒரு நீண்ட காலப் பதிலாக வடிவமைக்கப்பட்டன. asyncio அம்சங்களைப் பயன்படுத்தும்போது, ஒரு கருவி அழைப்பு மாதிரி எடுக்கப்பட்ட பிறகு, Responses API மாதிரி எடுக்கும் சுழற்சியில் ஒத்திசைவற்ற முறையில் தடுக்கப்படும். பின்னர், Responses API response.done நிகழ்வை வாடிக்கையாளருக்கு அனுப்பும். கருவி அழைப்பை செயல்படுத்திய பிறகு, கிளையண்டுகள் கருவியின் முடிவுடன் response.append நிகழ்வை அனுப்பும். இது அழைப்பு மாதிரி தடையை நீக்கி, மாடல் தொடர அனுமதித்தது.

இங்கே உள்ளூர் கருவி அழைப்பை ஹோஸ்டட் கருவி அழைப்பாகக் கருதுவது ஒரு ஒப்புமையாகும். மாடல் இணையத் தேடலை மேற்கொள்ளும்போது, அதன் இன்ஃபெரன்ஸ் லூப் தற்காலிகமாக நின்று, இணையத் தேடல் சேவையை அழைக்கும்; பின்னர் அந்தத் தேடல் முடிவுகளை மாடல் யின் சூழலில் இணைக்கும். எங்களது வடிவமைப்பிலும் நாங்கள் அதையே செய்தோம்; ஆனால், ஒரு தொலைதூர சேவையை அழைப்பதற்குப் பதிலாக, மாடல்யின் கருவிக் காலை WebSocket வழியாக மீண்டும் கிளையண்டிற்கே அனுப்பினோம். கிளையண்ட் பதிலளித்தவுடன், அந்த கருவிக் கால் முடிவுகளை மாதிரியின் சூழலில் சேர்த்து, நாங்கள் மீண்டும் சாம்பிளிங் செய்யத் தொடங்கினோம்.

இந்த வடிவமைப்பு மிகவும் பயனுள்ளதாக அமைந்தது; ஏனெனில் இது ஒரு ஏஜென்ட் ரோல்-அவுட்டின் போது மீண்டும் மீண்டும் செய்யப்படும் API வேலைகளை முற்றிலுமாகத் தவிர்த்தது. எங்களால் முன்-இன்ஃபெரன்ஸ் பணிகளை ஒருமுறை செய்துவிட்டு, கருவிக் செயல்பாட்டிற்காகச் சிறிது நேரம் இடைநிறுத்தி, இறுதியாகப் பின்-இன்ஃபெரன்ஸ் பணிகளை ஒருமுறை மட்டும் செய்ய முடிந்தது.

துரதிர்ஷ்டவசமாக, இந்த வசதியைப் பெறுவதற்கு ஈடாக, API-ன் வடிவம் வழக்கத்திற்கு மாறானதாகவும் மற்றும் சற்றே சிக்கலானதாகவும் மாறியது. மென்பொருள் உருவாக்குநர்கள், தங்களது API ஒருங்கிணைப்பை ஒரு புதிய தொடர்பு முறைக்காக மீண்டும் மாற்றி எழுத வேண்டிய அவசியமில்லாமல், மிக எளிதாக WebSocket ஆதரவை இணைக்க வேண்டும் என்பதே எங்களது விருப்பமாக இருந்தது.

நாங்கள் அறிமுகப்படுத்திய பதிப்பிற்காக, மீண்டும் ஒரு பழகிய வடிவத்திற்கே மாறினோம்: அதாவது, அதே பழைய உள்ளடக்கத்துடன் response.create-ஐத் தொடர்ந்து பயன்படுத்துவது மற்றும் முந்தைய பதிலின் நிலையிலிருந்து உரையாடல் சூழலைத் தொடர previous_response_id-ஐப் பயன்படுத்துவது .

ஒரு WebSocket இணைப்பில், சர்வர் முந்தைய பதிலின் நிலையை நினைவகத்தில் உள்ள கேச்சில் (cache) இணைப்பு அளவிலான வரம்புடன் பராமரிக்கிறது. தொடர்ச்சியாக வரும் response.createகோரிக்கையில் previous_response_id இடம்பெற்றால், உரையாடல் சூழலை ஆரம்பத்திலிருந்து மீண்டும் உருவாக்காமல், கேச்-இல் இருந்து அந்த நிலையை நாங்கள் மீட்டெடுப்போம்.

அந்த தற்காலிக சேமிப்பில் உள்ள நிலை பின்வருவனவற்றை உள்ளடக்கியது:

• முந்தைய response பொருள்
• முந்தைய உள்ளீடு மற்றும் வெளியீட்டு உருப்படிகள்
• கருவி வரையறைகள் மற்றும் பெயரிடங்கள்
• மீண்டும் பயன்படுத்தக்கூடிய சாம்பிளிங் கூறுகள், அதாவது ஏற்கனவே உருவாக்கப்பட்ட டோக்கன்கள்

நினைவகத்தில் உள்ள முந்தைய பதிலின் நிலையை மீண்டும் பயன்படுத்துவதன் மூலம், எங்களால் பல முக்கியமான மேம்பாடுகளைச் செய்ய முடிந்தது:

• எங்களது சில பாதுகாப்பு வகைப்படுத்திகள் மற்றும் கோரிக்கை சரிபார்ப்பான்கள், ஒவ்வொரு முறையும் முழு வரலாற்றையும் ஆய்வு செய்யாமல், புதிய உள்ளீட்டை மட்டும் பரிசீலிக்கும்படி செய்தல்.
• தேவையற்ற டோக்கனைசேஷனைத் தவிர்ப்பதற்காக, ஏற்கனவே உருவாக்கப்பட்ட டோக்கன்களுடன் புதியவற்றைச் சேர்த்துக் கொள்ளும் வகையில், அவற்றினை நினைவகத்தில் சேமித்து வைத்தல்.
• பல்வேறு கோரிக்கைகளுக்கிடையே, எங்களது வெற்றிகரமான மாடல் ரிசொல்யூஷன்/ரூட்டிங் லாஜிக்கை மீண்டும் பயன்படுத்துதல். 
• பில்லிங் போன்ற போஸ்ட்-இன்ஃபரன்ஸ் வேலைகளை, அடுத்தடுத்த கோரிக்கைகளுடன் ஒரே நேரத்தில் தடையின்றி செயல்படுத்துதல்.

மென்பொருள் உருவாக்குநர்கள் ஏற்கனவே புரிந்து வைத்திருக்கும் மற்றும் அதற்கேற்ப கட்டமைப்புகளை உருவாக்கியுள்ள அதே API வடிவத்தைப் பயன்படுத்தி, மிகக் குறைந்த கூடுதல் சுமையுடன் கூடிய ஒரு முன்மாதிரியை உருவாக்குவதே எங்களது இலக்காக இருந்தது.

WebSocket mode முறையை உருவாக்குவதற்கான இரண்டு மாத தீவிர முயற்சிக்குப் பிறகு, முன்னணி கோடிங் ஏஜென்ட் ஸ்டார்ட்அப்களுடன் இணைந்து இதன் ஆல்ஃபா பதிப்பை நாங்கள் அறிமுகப்படுத்தினோம்; இதன் மூலம் அவர்கள் இந்த வசதியைத் தங்களது உள்கட்டமைப்பில் ஒருங்கிணைத்து, பாதுகாப்பான முறையில் பயன்பாட்டுப் போக்குவரத்தை அதிகரிக்க முடிந்தது. ஆல்பா பயனர்கள் இதனை மிகவும் விரும்பினர்; அவர்களின் ஏஜென்டிக் பணிச்சூழல்களில் 40% வரை மேம்பாடுகள்⁠(புதிய சாளரத்தில் திறக்கும்) ஏற்பட்டதாக தெரிவித்தனர். ஆல்ஃபா பதிப்பிற்குக் கிடைத்த நேர்மறையான கருத்துக்களுக்குப் பிறகு, நாங்கள் இதனை அறிமுகப்படுத்தத் தயாராக இருந்தோம்.

அறிமுகத்தின் முடிவுகள் உடனடியாகத் தெரிந்தன. Codex நிறுவனம் தனது Responses API பயன்பாட்டின் பெரும்பகுதியை விரைவாக WebSocket முறைக்கு மாற்றியது, இதன் மூலம் அதன் வேகத்தில் குறிப்பிடத்தக்க முன்னேற்றங்களைக் கண்டது. GPT‑5.3‑Codex‑Spark மாடலைப் பொறுத்தவரை, நாங்கள் வினாடிக்கு 1,000 கோரிக்கைகள் (1,000 TPS) என்ற எங்களது இலக்கை எட்டியதோடு, 4,000 TPS வரை உயர்வையும் கண்டோம்; இதன் மூலம் உண்மையான புரொடக்ஷன் டிராஃபிக்கில், அதிவேக இன்ஃபரன்ஸிற்கு இணையாக Responses API செயல்பட முடியும் என்பது நிரூபிக்கப்பட்டுள்ளது. டெவலப்பர் சமூகத்திலும் இதற்கான தாக்கம் மிக விரைவாகத் தெரிந்தது:

• Codex தங்களின் பெரும்பாலான டிராஃபிக்கைக் WebSockets-க்கு மிக விரைவாக மாற்றியது. சமீபத்திய மாடல்களைப் பயன்படுத்தும் Codex பயனர்கள், உதாரணமாக GPT‑5.3‑Codex⁠(புதிய சாளரத்தில் திறக்கும்), GPT‑5.4⁠(புதிய சாளரத்தில் திறக்கும்), மேலும், அதற்கும் அப்பால் அனைவரும் WebSocket பயன்முறையின் வேக அதிகரிப்பால் பயனடைவார்கள்.
• Vercel, AI SDK இல் WebSocket பயன்முறையை ஒருங்கிணைத்து, தாமதம் 40% வரை குறைந்தது⁠(புதிய சாளரத்தில் திறக்கும்) என்பதைக் கண்டது.
• Cline-இன் பல-கோப்பு பணிப்பாய்வுகள் 39% வேகமானவை⁠(புதிய சாளரத்தில் திறக்கும்).
• Cursor-இல் உள்ள OpenAI மாடல்கள் அதிகபட்சம் 30% வேகமானதாக ஆனது⁠(புதிய சாளரத்தில் திறக்கும்).

மார்ச் 2025-இல் அறிமுகப்படுத்தப்பட்டதில் இருந்து, Responses API சேர்க்கப்பட்ட மிக முக்கியமான புதிய திறன்களில் ஒன்றாக WebSocket முறை விளங்குகிறFது. OpenAI-இன் API மற்றும் Codex குழுக்களுக்கு இடையேயான நெருக்கமான ஒத்துழைப்பின் மூலம், சில வாரங்களிலேயே ஒரு யோசனையைச் செயல்படுத்தி புரொடக்ஷனில் வெற்றிகரமாக இயக்க முடிந்தது. இது ஏஜென்ட் வெளியீட்டு வேகத்தை வியக்கத்தக்க வகையில் மேம்படுத்துவது மட்டுமல்லாமல், மென்பொருள் உருவாக்குநர்களின் வளர்ந்து வரும் ஒரு தேவையையும் பூர்த்தி செய்கிறது: மாடல் இன்ஃபரன்ஸ் வேகம் அதிகரிக்கும் போது, அதன் பலன்களைப் பயனர்களுக்குக் கொண்டு சேர்க்க, இன்ஃபரன்ஸைச் சுற்றியுள்ள பிற சேவைகளும் அமைப்புகளும் தங்களது வேகத்தை அதிகரிக்க வேண்டியது அவசியமாகிறது