Responses APIలో WebSocketsతో ఏజెంట్ ఆధారిత వర్క్‌ఫ్లోలను వేగవంతం చేయడం

మీరు Codex ను బగ్‌ను సరిచేయమని అడిగినప్పుడు, అది సంబంధిత ఫైల్‌ల కోసం మీ కోడ్‌బేస్‌ను స్కాన్ చేసి, సందర్భాన్ని అర్థం చేసుకోవడానికి వాటిని చదివి, మార్పులు చేసి, పరిష్కారం పనిచేసిందో లేదో నిర్ధారించడానికి టెస్ట్‌లను నడుపుతుంది. అంతర్గతంగా, దాని అర్థం డజన్ల కొద్దీ ముందుకు-వెనుకకు జరిగే Responses API రిక్వెస్ట్స్: మోడల్ యొక్క తదుపరి చర్యను నిర్ణయించడం, మీ కంప్యూటర్‌లో ఒక టూల్‌ను రన్ చేయడం, టూల్ అవుట్‌పుట్‌ను తిరిగి APIకి పంపించడం, మరియు దీన్ని మళ్లీ మళ్లీ పునరావృతం చేయడం.

ఈ అన్ని రిక్వెస్ట్‌లు కలిపి, Codex సంక్లిష్టమైన పనులను పూర్తి చేయడానికి వినియోగదారులు వేచి ఉండే సమయం మొత్తంగా నిమిషాల వరకు చేరవచ్చు. లేటెన్సీ దృష్టికోణంలో చూస్తే, Codex ఏజెంట్ లూప్ తన సమయాన్ని ప్రధానంగా మూడు ముఖ్య దశల్లో గడుపుతుంది: API సర్వీసుల్లో పని చేయడం (అభ్యర్థనలను ధృవీకరించి ప్రాసెస్ చేయడానికి), మోడల్ ఇన్‌ఫెరన్స్, మరియు క్లయింట్-సైడ్ సమయం (టూల్స్‌ను అమలు చేయడం మరియు మోడల్ కాంటెక్స్ట్‌ను నిర్మించడం). ఇన్‌ఫరెన్స్ అనేది మోడల్ GPUs పై నడిచి కొత్త టోకెన్స్‌ను రూపొందించే దశ. గతంలో, GPUలపై 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 నవంబర్ ప్రాంతంలో, మేము ప్రతిస్పందనల 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 చేర్చబడినప్పుడు, మొత్తం సంభాషణను మొదటి నుండి మళ్లీ నిర్మించడానికి బదులుగా మేము ఆ స్థితిని క్యాష్ నుండి పొందుతాము.

ఆ క్యాష్ చేయబడిన స్థితిలో ఇవి ఉంటాయి:

• మునుపటి రెస్పాన్స్ ఆబ్జెక్ట్
• మునుపటి ఇన్‌పుట్ మరియు అవుట్‌పుట్ అంశాలు
• టూల్ నిర్వచనాలు మరియు నేమ్‌స్పేస్‌లు
• ముందుగా రెండర్ చేసిన టోకెన్స్ వంటి మళ్లీ ఉపయోగించగల సాంప్లింగ్ ఆర్టిఫాక్ట్స్.

మెమరీలో ఉన్న మునుపటి ప్రతిస్పందన స్థితిని మళ్లీ ఉపయోగించడం ద్వారా, మేము అనేక ముఖ్యమైన ఆప్టిమైజేషన్‌లను సాధించగలిగాం:

• మా సేఫ్టీ క్లాసిఫయర్లు మరియు రిక్వెస్ట్ వాలిడేటర్లలో కొన్ని ప్రతిసారీ పూర్తి చరిత్రను కాకుండా, కొత్త ఇన్‌పుట్‌ను మాత్రమే ప్రాసెస్ చేసేలా చేయడం
• అనవసరమైన టోకనైజేషన్‌ను దాటవేయడానికి, మేము జోడిస్తూ ఉండే రెండర్ చేసిన టోకెన్‌ల యొక్క ఇన్-మెమరీ క్యాష్‌ను ఉంచడం
• రిక్వెస్ట్స్ అంతటా మా విజయవంతమైన మోడల్ రిజల్యూషన్/రూటింగ్ లాజిక్‌ను మళ్లీ ఉపయోగించడం 
• బిల్లింగ్ వంటి నిరోధించని పోస్ట్‌ఇన్‌ఫరెన్స్ పనిని తదుపరి అభ్యర్థనలతో అతివ్యాప్తి చేయడం

లక్ష్యం కనిష్ట ఓవర్‌హెడ్ ప్రోటోటైప్‌కు సాధ్యమైనంత దగ్గరగా చేరుకోవడం, కానీ డెవలపర్లు ఇప్పటికే అర్థం చేసుకుని, దాని చుట్టూ నిర్మించుకున్న 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% వేగవంతమయ్యాయి⁠(కొత్త విండోలో తెరుచుకుంటుంది).

మార్చి 2025లో ప్రారంభమైనప్పటి నుండి, Responses APIలోని అత్యంత ముఖ్యమైన కొత్త సామర్థ్యాల్లో WebSocket మోడ్ ఒకటి. OpenAI యొక్క API మరియు Codex టీమ్‌ల మధ్య సన్నిహిత సహకారంతో, మేము కేవలం కొన్ని వారాల్లోనే ఒక ఆలోచన నుండి ప్రొడక్షన్‌లో నడుస్తున్న దశకు చేరుకున్నాము. ఇది ఏజెంట్ రోలౌట్ లేటెన్సీని గణనీయంగా మెరుగుపరచడమే కాకుండా, బిల్డర్ల పెరుగుతున్న అవసరాన్ని కూడా సమర్థిస్తుంది: మోడల్ ఇన్‌ఫరెన్స్ వేగంగా మారుతున్న కొద్దీ, ఈ లాభాలు యూజర్లకు చేరేలా ఇన్‌ఫరెన్స్‌ను చుట్టుముట్టే సర్వీసులు మరియు సిస్టమ్స్ కూడా వేగవంతం కావాలి.