Kuharakisha michakato ya kazi ya kiwakala kwa kutumia WebSockets katika Responses API

Unapoomba Codex kurekebisha hitilafu, huchanganua msingi wako wa msimbo kutafuta faili husika, huzisoma ili kujenga muktadha, hufanya mabadiliko, na huendesha majaribio ili kuthibitisha kuwa marekebisho yamefanikiwa. Kwa undani, hiyo inamaanisha maombi mengi ya Responses API ya kwenda na kurudi: kubaini hatua inayofuata ya muundo, kuendesha zana kwenye kompyuta yako, kutuma matokeo ya zana kurudi kwa API, na kurudia.

Maombi haya yote yanaweza kujumlisha hadi dakika kadhaa ambazo watumiaji hutumia wakisubiri Codex ikamilishe shughuli changamano. Kwa mtazamo wa ucheleweshaji, mzunguko wa wakala wa Codex hutumia muda wake mwingi katika hatua kuu tatu: kufanya kazi katika huduma za API (ili kuthibitisha na kuchakata maombi), ufasiri wa muundo, na muda wa upande wa mteja (kuendesha zana na kujenga muktadha wa muundo). Ufasiri ni hatua ambapo muundo huendeshwa kwenye GPU ili kuzalisha tokeni mpya. Hapo awali, kuendesha ukisiaji wa LLM kwenye GPU kulikuwa sehemu ya polepole zaidi ya mchakato wa wakala, hivyo mzigo wa ziada wa huduma ya API ulikuwa rahisi kuficha. Kadri uamuzi unavyozidi kuwa wa haraka, ndivyo mzigo wa ziada wa API wa jumla kutoka kwa utekelezaji wa kiwakala unavyoonekana zaidi kwa kiasi kikubwa.

Katika chapisho hili, tutaeleza jinsi tulivyofanya mizunguko ya wakala kwa kutumia API kuwa na kasi zaidi kwa 40% kutoka mwanzo hadi mwisho, na hivyo kuwawezesha watumiaji kushuhudia ongezeko la kasi ya ufasiri kutoka tokeni 65 hadi karibu tokeni 1,000 kwa sekunde. Tulishughulikia hili kupitia uhifadhi wa akiba, kuondoa hatua zisizo za lazima za mtandao, kuboresha safu yetu ya usalama ili kutambua matatizo kwa haraka, na—muhimu zaidi—kujenga njia ya kuunda muunganisho endelevu kwa Responses API, badala ya kulazimika kufanya mfululizo wa miito ya API ya usawazishaji.

Katika Responses API, miundo mikuu ya awali kama GPT‑5 na GPT‑5.2 ilifanya kazi kwa takriban tokeni 65 kwa sekunde (TPS). Kwa uzinduzi wa GPT‑5.3‑Codex‑Spark, muundo wa haraka wa uandishi wa msimbo, lengo letu lilikuwa kufikia kasi iliyokuwa kubwa kwa kiwango cha mara kumi: zaidi ya TPS 1,000, ikiwezeshwa na vifaa maalumu vya Cerebras vilivyoboreshwa kwa uingizaji hitimisho wa LLM. Ili kuhakikisha kuwa watumiaji wanaweza kufurahia kasi halisi ya muundo huu mpya, ilibidi tupunguze mzigo wa ziada wa API. 

Karibu Novemba 2025, tulianzisha mchakato wa kuboresha utendaji kwenye Responses API, tukitekeleza maboresho mengi ya muda wa kusubiri kwenye njia muhimu kwa ombi moja: 

• Kuhifadhi tokeni zilizochakatwa na usanidi wa muundo kwenye kumbukumbu ili kuepuka ugawaji wa tokeni wa gharama kubwa na miito ya mtandao kwa majibu ya zamu nyingi
• Kupunguza ucheleweshaji wa hopu za mtandao kwa kuondoa miito kwa huduma za kati (kwa mfano, uchakataji wa picha wa azimio) na kuita moja kwa moja huduma ya ubashiri yenyewe
• Kuboresha mfumo wetu wa usalama ili tuweze kuendesha waainishaji fulani kwa ajili ya kutambua mazungumzo kwa haraka zaidi

Kwa maboresho haya, tuliona ongezeko la karibu 45% katika muda wa kupata tokeni ya kwanza (TTFT)—ambayo inaonyesha mwitikio wa API—lakini maboresho haya bado hayakuwa ya haraka vya kutosha kwa GPT‑5.3‑Codex‑Spark. Hata pamoja na maboresho haya, mzigo wa ziada wa Responses API ulikuwa mkubwa mno ukilinganisha na kasi ya muundo—yaani, watumiaji walilazimika kusubiri CPU zinazoendesha API yetu kabla ya kutumia GPU zinazohudumia muundo.

Tatizo kuu lilikuwa la kimuundo: tulichukulia kila ombi la Codex kuwa huru, tukichakata hali ya mazungumzo na muktadha mwingine unaoweza kutumika tena katika kila ombi la ufuatiliaji. Hata wakati sehemu kubwa ya mazungumzo haikuwa imebadilika, bado tulilipia kazi iliyohusishwa na historia kamili. Kadiri mazungumzo yalivyozidi kuwa marefu, uchakataji huo wa kurudiwa-rudiwa ukawa wa gharama kubwa zaidi.

Ili kuboresha muundo, tulifikiria upya itifaki ya usafirishaji: je, tunaweza kudumisha muunganisho endelevu na kuhifadhi hali kwenye akiba, badala ya kuanzisha muunganisho mpya kupitia HTTP na kutuma historia kamili ya mazungumzo kwa kila ombi la ufuatiliaji? Wazo lilikuwa kutuma tu taarifa mpya yoyote inayohitaji uthibitishaji na uchakataji, na kuhifadhi hali inayoweza kutumika tena kwenye kumbukumbu kwa muda wote wa muunganisho. Hii ingepunguza mzigo wa ziada unaotokana na kazi inayojirudia.

Tulizingatia mbinu chache tofauti, ikiwemo WebSockets na gRPC bidirectional streaming. Tulifika kwenye WebSockets kwa sababu kama itifaki rahisi ya usafirishaji wa ujumbe, watumiaji hawangelazimika kubadilisha maumbo yao ya ingizo na matokeo ya API ya Majibu. Iliwafaa wasanidi programu na iliendana na usanifu wetu uliopo kwa usumbufu mdogo.

Prototipu ya kwanza ya WebSocket ilibadilisha kile tulichodhani kinawezekana kwa muda wa kusubiri wa API ya majibu. Mhandisi mmoja kwenye timu ya Codex mwenye utaalamu wa kina katika safu ya API aliunda prototaipu kwa kuendesha wakala wa Codex usiku kucha.

Katika prototipu hiyo, utekelezaji wa mawakala uliundwa kama Jibu moja la muda mrefu. Kwa kutumia vipengele vya asyncio, Responses API ingesubiri kwa njia isiyo ya kusawazisha katika mzunguko wa uchukuaji sampuli baada ya mwito wa zana kuchukuliwa sampuli, na Responses API ingetuma tukio la response.done kurudi kwa mteja. Baada ya kutekeleza mwito wa zana, viteja vingetuma tena tukio la response.append pamoja na matokeo ya zana, jambo ambalo liliondoa kizuizi kwenye mchakato wa sampuli na kuuruhusu muundo kuendelea.

Mfano wa kulinganisha hapa ni kuchukulia mwito wa zana wa ndani kama mwito wa zana uliopangishwa. Muundo unapoita utafutaji wa wavuti, mzunguko wa ufasili husimama, huita huduma ya utafutaji wa wavuti, na huweka jibu la huduma katika muktadha wa muundo. Katika muundo wetu, tulifanya vivyo hivyo; lakini badala ya kuita huduma ya mbali, tulituma wito wa zana wa muundo kurudi kwa kiteja kupitia WebSocket. Mteja alipotoa jibu, tuliweka jibu la mwito wa zana la mteja kwenye muktadha na tukaendelea kufanya sampuli.

Muundo huu ulikuwa na ufanisi mkubwa sana kwa sababu uliondoa kazi ya API iliyojirudia katika uzinduzi wa wakala. Tunaweza kufanya kazi ya utangulizi mara moja, kusitisha utekelezaji wa zana, na kufanya kazi ya utangulizi mara moja mwishoni.

Kwa bahati mbaya, hili lilikuja kwa gharama ya muundo wa API usiozoeleka sana na mgumu zaidi. Tulitaka wasanidi programu waweze kuongeza usaidizi wa WebSocket kwa urahisi bila kulazimika kuandika upya ujumuishaji wao wa API ili kuendana na mbinu mpya ya mwingiliano.

Kwa toleo tulilolizindua, tulirudi kwenye umbo linalofahamika: endelea kutumia response.create kwa kutumia mwili uleule, na tumia previous_response_id ili kuendelea na muktadha wa mazungumzo kutoka kwa hali ya jibu lililopita.

Katika muunganisho wa WebSocket, seva huhifadhi akiba ya kumbukumbu ya hali ya awali ya majibu inayohusiana na muunganisho huo. Wakati response.create ya ufuatiliaji inajumuisha previous_response_id, tunarejesha hali hiyo kutoka kwenye akiba badala ya kujenga upya mazungumzo yote kutoka mwanzo.

Hali iliyowekwa akiba inajumuisha:

• Kitu cha jibu kilichotangulia
• Vipengee vya awali vya ingizo na matokeo
• Ufafanuzi wa zana na nafasi za majina
• Vifaa vya kuchukua sampuli vinavyoweza kutumika tena, kama tokeni zilizotolewa hapo awali

Kwa kutumia tena hali ya awali ya jibu iliyohifadhiwa kwenye kumbukumbu, tuliweza kufanikisha maboresho makubwa kadhaa:

• Kufanya baadhi ya viainishaji vyetu vya usalama na vithibitishaji vya maombi vichakate ingizo jipya pekee, si historia kamili kila wakati
• Kuweka akiba ya kumbukumbu ya tokeni zilizotolewa ambazo tunaziambatanisha ili tuweze kuruka ugawaji wa tokeni usio wa lazima
• Kutumia tena mantiki yetu iliyofaulu ya utatuzi/uelekezaji wa muundo katika maombi mbalimbali 
• Kuingiliana kwa ubashiri wa baada ya kutozuia hufanya kazi kama vile bili na maombi yanayofuata

Lengo lilikuwa kufikia kwa karibu iwezekanavyo prototaipu yenye gharama ndogo zaidi za ziada, lakini ikiwa na muundo wa API ambao wasanidi programu tayari waliuelewa na walikuwa wameunda mifumo yao kuuzingatia.

Baada ya miezi miwili ya kujenga hali ya WebSocket kwa kasi, tulizindua alpha yenye kampuni changa za mawakala muhimu wa usimbaji ili waweze kuiunganisha katika miundombinu yao na kuongeza trafiki kwa usalama. Watumiaji wa alpha waliipenda, wakiripoti maboresho ya hadi 40%⁠(fungua katika dirisha jipya) katika taratibu zao za kazi za mawakala. Kutokana na maoni chanya ya alpha, tulikuwa tayari kuzindua.

Matokeo ya uzinduzi yalikuwa ya mara moja. Codex ilihamisha kwa haraka sehemu kubwa ya trafiki yao ya Responses API hadi kwenye hali ya WebSocket, na ikaona maboresho makubwa ya ucheleweshaji. Kwa GPT‑5.3‑Codex‑Spark, tulifikia lengo letu la TPS 1,000 na tukashuhudia milipuko ya hadi TPS 4,000, jambo lililoonyesha kwamba Responses API iliweza kuendana na uelekezaji wa hitimisho wa kasi zaidi katika trafiki halisi ya uzalishaji. Matokeo yalionekana haraka pia katika jumuiya ya wasanidi programu:

• Codex ilihamisha haraka sehemu kubwa ya trafiki yake kwenda WebSockets. Watumiaji wa Codex wanaotumia muundo mpya zaidi kama vile GPT‑5.3‑Codex⁠(fungua katika dirisha jipya), GPT‑5.4⁠(fungua katika dirisha jipya), na zaidi ya hapo kunufaika kutokana na ongezeko la kasi la hali ya WebSocket.
• Vercel iliunganisha hali ya WebSocket kwenye AI SDK na ikashuhudia ucheleweshaji ukipungua kwa hadi 40%⁠(fungua katika dirisha jipya).
• Mitiririko ya kazi ya faili nyingi ya Cline ni haraka kwa 39%⁠(fungua katika dirisha jipya).
• Muundo wa OpenAI katika Cursor ikawa na kasi zaidi kwa hadi 30%⁠(fungua katika dirisha jipya).

Hali ya WebSocket ni mojawapo ya uwezo mpya muhimu zaidi katika Responses API tangu kuzinduliwa kwake mnamo Machi 2025. Tulitoka kwenye wazo hadi kufanya kazi katika mazingira ya uzalishaji ndani ya wiki chache tu kupitia ushirikiano wa karibu kati ya timu za API na Codex za OpenAI. Si tu kwamba inapunguza kwa kiasi kikubwa muda wa kusubiri wa uzinduzi wa wakala, bali pia inasaidia hitaji linaloongezeka la wajenzi: kadri utambuzi wa muundo unavyokuwa wa haraka zaidi, huduma na mifumo inayozunguka utambuzi huo pia inahitaji kuharakishwa ili kuhamisha manufaa haya kwa watumiaji.