Að hraða verkflæði fulltrúa með WebSockets í Responses API

Þegar þú biður Codex um að laga villu, skannar það kóðagrunninn þinn til að finna viðeigandi skrár, les þær til að byggja upp samhengi, gerir breytingar og keyrir prófanir til að staðfesta að lagfæringin hafi virkað. Bak við tjöldin þýðir það tugi fram og til baka beiðna til Responses API: ákvarða næstu aðgerð líkansins, keyra verkfæri á tölvunni þinni, senda niðurstöður verkfærisins aftur til API og endurtaka hlutina.

Allar þessar beiðnir geta safnast upp í margar mínútur af biðtíma þar sem notendur bíða eftir því að Codex ljúki flóknum verkefnum. Frá sjónarhóli svartíma eyðir fulltrúi Codex mestum tíma sínum í þrjú meginstig: vinnu í API-þjónustum (til að staðfesta og vinna úr beiðnum), líkanályktun og tíma hjá biðlara (að keyra verkfæri og byggja upp samhengi líkansins). Ályktun er stigið þar sem líkanið keyrir á GPU til að mynda nýja tóka. Áður fyrr var það hægasti hluti fulltrúalykkjunnar að keyra LLM-ályktun á GPU-einingum, þannig að auðvelt var að fela yfirbyggingu API-þjónustunnar. Eftir því sem ályktun verður hraðari verður uppsafnaður yfirhöfuðskostnaður í API-þjónustum við fulltrúakeyrslu mun meira áberandi.

Í þessari færslu útskýrum við hvernig við gerðum fulltrúalykkjur með API 40% hraðari frá upphafi til enda, sem gerir notendum kleift að upplifa stökkið í ályktunarhraða úr 65 í nærri 1.000 tóka á sekúndu. Við nálguðumst þetta með því að nota skyndiminni, útrýma óþarfa milliliðum í netbeiðnum, bæta öryggislagið okkar til að merkja vandamál hratt og — mikilvægast af öllu — byggja leið til að koma á varanlegri tengingu við Responses API, í stað þess að þurfa að framkvæma röð samstilltra API-kalla.

Í Responses API voru fyrri flaggskipslíkön, eins og GPT‑5 og GPT‑5.2, keyrð á um það bil 65 tókum á sekúndu (TPS). Við kynningu á GPT‑5.3‑Codex‑Spark, hraðvirku líkani, var markmið okkar að verða tífalt hraðari: yfir 1.000 TPS, sem var gert mögulegt með sérhæfðum Cerebras-vélbúnaði sem er fínstilltur fyrir LLM-úrvinnslu. Til að tryggja að notendur gætu upplifað raunverulegan hraða nýja líkansins þurftum við að draga úr álagi á API. 

Í kringum nóvember 2025 hófum við afkastasprett á Responses API og innleiddum margar betrumbætur á biðtíma á markleið fyrir eina beiðni: 

• Að geyma tóka og stillingar líkans í skyndiminni til að forðast kostnaðarsama tókavæðingu og netköll fyrir svör í mörgum umferðum
• Að draga úr biðtíma netstökka með því að sleppa köllum til milliþjónusta (til dæmis myndvinnsluupplausnar) og kalla beint á ályktunarþjónustuna sjálfa
• Að bæta öryggislausnina okkar svo við gætum keyrt ákveðna flokkara til að merkja samtöl hraðar

Með þessum umbótum sáum við nálægt 45% framför í tíma að fyrstu tóka (TTFT) — sem endurspeglar hversu viðbragðsfljótt API virðist vera — en þessar framfarir voru samt ekki nógu miklar fyrir GPT‑5.3‑Codex‑Spark. Jafnvel með þessum úrbótum var yfirbygging Responses API of mikil miðað við hraða líkansins — það er að segja að notendur þurftu að bíða eftir örgjörvunum sem keyrðu API-ið okkar áður en þeir gátu notað skjákortin sem keyrðu líkanið.

Dýpra vandamálið var kerfislægt: við meðhöndluðum hverja Codex-beiðni sem sjálfstæða og unnum samtalsstöðu og annað endurnýtanlegt samhengi í hverri eftirfylgnibeiðni. Jafnvel þegar mest af samtalinu hafði ekki breyst, greiddum við samt fyrir vinnu sem tengdist öllum ferlinum. Eftir því sem samtölin urðu lengri varð þessi endurtekna vinnsla kostnaðarsamari.

Til að herða hönnunina endurhugsuðum við flutningsreglurnar: gætum við viðhaldið varanlegri tengingu og skyndiminni, frekar en að koma á nýrri tengingu í gegnum HTTP og senda alla samtalssöguna fyrir hverja eftirfylgnibeiðni? Hugmyndin var að senda aðeins nýjar upplýsingar sem krefðust staðfestingar og vinnslu og geyma endurnýtanlegt ástand í minni út líftíma tengingarinnar. Þetta myndi draga úr óþarfa vinnu og minnka yfirbyggingu.

Við íhuguðum nokkrar mismunandi aðferðir, þar á meðal WebSockets og tvíátta streymi með gRPC. Við völdum WebSockets vegna þess að sem einfaldur skilaboðaflutningssamskiptamáti myndu notendur ekki þurfa að breyta inntaks- og úttakssniði sínu fyrir Responses API. Það var forritaravænt og féll vel að núverandi högun okkar með lágmarksröskun.

Fyrsta WebSocket-frumgerðin breytti því sem við töldum mögulegt fyrir biðtíma API viðbragða. Verkfræðingur í Codex-teyminu með djúpa sérþekkingu á öllum API-staflanum setti saman frumgerð með því að keyra Codex-fulltrúa yfir nótt.

Í þeirri frumgerð voru fulltrúakeyrslur mótaðar sem eitt langvarandi svar. Með því að nota eiginleika asyncio myndi Responses API stöðvast ósamstillt í sýnatökulykkjunni eftir að verkfærakall hafði verið sýnatekið, og Responses API myndi senda response.done -atburð til baka til viðskiptavinarins. Eftir að hafa framkvæmt verkfærakallið myndu viðskiptavinir senda aftur response.append -atburð með niðurstöðu verkfærisins, sem aflæsti sýnatökulykkjunni og leyfði líkaninu að halda áfram.

Samlíkingin hér er að líta á staðbundið verkfærakall sem hýst verkfærakall. Þegar líkanið kallar á vefleit stöðvast ályktunarlykkjan, kallar á vefleitarþjónustu og setur svar þjónustunnar í samhengi líkansins. Í hönnun okkar gerðum við það sama, en í stað þess að kalla á fjartengda þjónustu sendum við verkfærakall líkansins aftur til viðskiptavinarins yfir WebSocket-tenginguna. Þegar viðskiptavinurinn svaraði settum við svar við verkfærakalli hans í samhengi og héldum áfram að taka sýni.

Þessi hönnun var afar áhrifarík vegna þess að hún útrýmdi endurtekinni API-vinnu við innleiðingu fulltrúa. Við gætum unnið vinnu fyrir ályktun einu sinni, gert hlé á meðan verkfæri eru keyrð og unnið vinnu eftir ályktun einu sinni í lokin.

Því miður hafði þetta í för með sér ókunnugra og flóknara API-form. Við vildum að forritarar gætu bætt við WebSocket-stuðningi án þess að þurfa að endurskrifa API-samþættinguna sína fyrir nýtt samskiptaform.

Í útgáfunni sem við settum í loftið færðum við okkur aftur yfir í kunnuglegt form: haldið áfram að nota response.create með sama innihaldi og notið previous_response_id til að halda áfram samhenginu í samtalinu út frá stöðu fyrra svarsins.

Í WebSocket-tengingu heldur netþjónninn skyndiminni í vinnsluminni sem er bundið við tenginguna og geymir fyrra svarástand. Þegar eftirfylgjandi response.create inniheldur previous_response_id, sækjum við ástandið úr skyndiminni í stað þess að endurbyggja allt samtalið frá grunni.

Sú staða í skyndiminni felur í sér:

• Fyrri response hlutur
• Fyrri þættir inntaks og úttaks
• Verkfæraskilgreiningar og nafnasvæði
• Endurnýtanlegar hlutir til sýnatöku, eins og áður myndaðir tókar

Með því að endurnýta fyrra svarsástand í vinnsluminni gátum við gert nokkrar stórar hagræðingar:

• Að láta suma af öryggisflokkurunum okkar og beiðnistaðfesturunum okkar vinna aðeins úr nýju inntaki, en ekki öllum ferlinum í hvert skipti
• Halda skyndiminni í minni fyrir myndaðar tóka sem við bætum við, svo við getum sleppt óþarfa tókavæðingu.
• Að endurnýta árangursríka úrlausnar-/beiningarrökfræði líkansins okkar milli beiðna 
• Samhliða óhindrandi vinnu eftir úrvinnslu, eins og gjaldtöku, við síðari beiðnir

Markmiðið var að komast eins nálægt frumgerð með lágmarksumsýslu og mögulegt var, en með gerð forritaskila sem forritarar þekktu og höfðu þegar aðlagað að sínum þörfum.

Eftir tveggja mánaða sprett við þróun WebSocket-stillingar settum við alfaútgáfu í loftið með lykilnýsköpunarfyrirtækjum á sviði kóðunar svo þau gætu samþætt hana við innviði sína og aukið umferðina á öruggan hátt. Alfanotendur voru mjög ánægðir með þetta og greindu frá allt að 40% umbótum⁠(opnast í nýjum glugga) á verkflæði fulltrúa sinna. Í ljósi jákvæðra viðbragða við alfaútgáfunni vorum við tilbúin að hefja útgáfu.

Niðurstöður kynningarinnar komu strax í ljós. Codex færði hratt meirihluta umferðar sinnar á Responses API yfir á WebSocket-stillingu og sá verulegar framfarir í biðtíma. Fyrir GPT‑5.3‑Codex‑Spark náðum við markmiði okkar um 1.000 TPS og sáum toppa upp í 4.000 TPS, sem sýnir að Responses API gæti haldið í við mun hraðari ályktunarvinnslu í raunverulegri framleiðsluumferð. Áhrifin komu líka fljótt fram í samfélagi þróunaraðila:

• Codex færði hratt meirihluta umferðar sinnar yfir á WebSockets. Codex-notendur sem keyra nýjustu líkönin eins og GPT‑5.3‑Codex⁠(opnast í nýjum glugga), GPT‑5.4⁠(opnast í nýjum glugga), og víðar njóta góðs af hraðaaukningu WebSocket-stillingarinnar.
• Vercel samþætti WebSocket-stillingu í AI SDK og sá biðtíma minnka um allt að 40%⁠(opnast í nýjum glugga).
• Vinnuflæði Cline fyrir margar skrár eru 39% hraðari⁠(opnast í nýjum glugga).
• OpenAI-líkön í Cursor urðu allt að 30% hraðari⁠(opnast í nýjum glugga).

WebSocket-stilling er ein mikilvægasta nýja getan í Responses API frá því að það var sett á markað í mars 2025. Við fórum frá hugmynd að lausn sem var komin í notkun í framleiðsluumhverfi á aðeins nokkrum vikum með nánu samstarfi milli API-teymis OpenAI og Codex-teymisins. Það bætir ekki aðeins biðtíma við útbreiðslu fulltrúa verulega, heldur styður það einnig við vaxandi þörf þróunaraðila: eftir því sem ályktun líkans verður hraðari þurfa þjónusturnar og kerfin sem umlykja ályktunina einnig að hraða sér til að skila þessum ávinningi til notenda.