Az ügynöki munkafolyamatok felgyorsítása WebSockets segítségével a Responses API-ban

Amikor a Codex-et megkérjük egy hiba kijavítására, a program átvizsgálja a kódbázist a releváns fájlok után, elolvassa azokat a kontextus megértése érdekében, elvégzi a szükséges módosításokat, majd teszteket futtat, hogy ellenőrizze, a javítás működik-e. A háttérben ez oda-vissza zajló Responses API-kérések tucatjait jelenti: meghatározza a modell következő lépését, futtat egy eszközt a számítógépeden, visszaküldi az eszköz kimenetét az API-nak, majd megismétli.

Mindezek a kérések együtt akár több percnyi várakozási időt is jelenthetnek a felhasználók számára, amíg a Codex befejezi az összetett feladatokat. Késleltetési szempontból a Codex ügynök ciklusa az idő nagy részét három fő szakaszban tölti:  az API-szolgáltatásokban végzett munkával (a kérések ellenőrzése és feldolgozása), modell-inferenciával, valamint kliensoldali idővel (az eszközök futtatása és a modellkontextus felépítése). Az inferencia az a szakasz, amikor a modell GPU-kon fut új tokenek generálásához. Korábban a GPU-kon futó LLM-inferencia volt az ügynökciklus leglassabb része, ezért az API-szolgáltatási többletterhelést könnyű volt elfedni. Ahogy a következtetés gyorsabbá válik, az ügynöki bevezetésből származó kumulatív API-többletterhelés sokkal észrevehetőbbé válik.

Ebben a bejegyzésben elmagyarázzuk, hogyan tettük az API használatával működő ügynökciklusokat végponttól végpontig 40%-kal gyorsabbá, így a felhasználók is megtapasztalhatják a következtetési sebesség ugrását a másodpercenkénti 65-ről közel 1000 tokenre. Ezt gyorsítótárazással, a felesleges hálózati ugrások kiküszöbölésével, biztonsági rendszerünk fejlesztésével a problémák gyors jelzése érdekében, valamint — ami a legfontosabb — egy olyan megoldás kialakításával értük el, amely állandó kapcsolatot tud létrehozni a Responses API-val, ahelyett, hogy szinkron API-hívások sorozatát kellene indítani.

A Responses API-ban a korábbi csúcsmodellek, mint a GPT‑5 és a GPT‑5.2, körülbelül 65 token/másodperc (TPS) sebességgel működtek. A GPT‑5.3‑Codex‑Spark, egy gyors kódolási modell bevezetésekor az volt a célunk, hogy nagyságrenddel gyorsabbak legyünk: több mint 1 000 TPS-t érjünk el, amit az LLM-inferenciára optimalizált, speciális Cerebras hardver tett lehetővé. Annak érdekében, hogy a felhasználók megtapasztalhassák ennek az új modellnek a valódi sebességét, csökkentenünk kellett az API-többletterhelést. 

2025 novemberében teljesítménynövelő programot indítottunk a Responses API-n, amelynek keretében számos optimalizálást hajtottunk végre az egyes kérések kritikus útvonalának késleltetésén: 

• A feldolgozott tokenek és a modell konfigurációjának memóriában történő gyorsítótárazása a költséges tokenizálás és hálózati hívások elkerülése érdekében többfordulós válaszok esetén
• A hálózati ugrásokból eredő késleltetés csökkentése a köztes szolgáltatások hívásainak kiküszöbölésével (például képfeldolgozási felbontás), valamint az inferenciaszolgáltatás közvetlen hívásával
• Biztonsági csomagunk fejlesztése, hogy bizonyos osztályozókat futtathassunk bizonyos beszélgetések gyorsabb megjelölése érdekében

Ezekkel a fejlesztésekkel közel 45%-os javulást értünk el az első token megjelenéséhez szükséges időben (TTFT) — ami azt tükrözi, mennyire reszponzívnak érződik az API —, de ezek a fejlesztések még mindig nem voltak elég gyorsak a GPT‑5.3‑Codex‑Spark számára. Még ezekkel a fejlesztésekkel is túl nagy volt a Responses API többletterhelése a modell sebességéhez képest – vagyis a felhasználóknak meg kellett várniuk, amíg az API-t futtató CPU-k feldolgozzák a kéréseket, mielőtt használhatták volna a modellt kiszolgáló GPU-kat.

A mélyebb probléma strukturális volt: minden egyes Codex-kérést függetlennek tekintettünk, ezért a beszélgetés állapotát és más újra felhasználható kontextust minden további kérésben újra feldolgoztuk. Még akkor is, amikor a beszélgetés nagy része nem változott, továbbra is olyan munkáért fizettünk, amely a teljes beszélgetési előzményekhez kapcsolódott. Ahogy a beszélgetések hosszabbá váltak, az ismételt feldolgozás egyre költségesebbé vált.

Hogy letisztultabbá tegyük a kialakítást, újragondoltuk az átviteli protokollt: fenn tudnánk tartani egy tartós kapcsolatot, és gyorsítótárazni tudnánk az állapotot ahelyett, hogy minden utánkövető kéréshez új kapcsolatot létesítenénk HTTP-n keresztül, és elküldenénk a teljes beszélgetési előzményt? Az elképzelés az volt, hogy csak az új, ellenőrzést és feldolgozást igénylő információkat küldjék el, és az újra felhasználható állapotot a kapcsolat teljes élettartama alatt a memóriában tárolják. Ezzel csökkenthető lenne a felesleges munkából származó többletterhelés.

Több különböző megközelítést is fontolóra vettünk, beleértve a WebSockets használatát és a gRPC kétirányú streamelést. A WebSockets mellett döntöttünk, mert egyszerű üzenettovábbítási protokollként a felhasználóknak nem kellene módosítaniuk a Responses API bemeneti és kimeneti struktúráit. Fejlesztőbarát volt, és kevés fennakadással illeszkedett a meglévő architektúránkhoz.

Az első WebSocket-prototípus megváltoztatta azt, amit a Responses API késleltetése kapcsán lehetségesnek tartottunk. A Codex csapatának egyik mérnöke, aki mély szakértelemmel rendelkezik az API-stack terén, egy Codex-ügynök egész éjszakás futtatásával állított össze egy prototípust.

Abban a prototípusban az ügynöki bevezetéseket egyetlen, hosszú ideig futó Response-ként modelleztük. Az asyncio funkcióit használva a Responses API aszinkron módon blokkolna a mintavételezési ciklusban, miután egy eszközhívás mintavételezésre került, és a Responses API visszaküldene egy response.done eseményt az ügyfélnek. Az eszközhívás végrehajtása után az ügyfelek egy response.append eseményt küldenének vissza az eszköz eredményével, ami feloldotta a mintavételezési ciklust, és lehetővé tette, hogy a modell folytassa.

Ehhez hasonlóan a helyi eszközhívást is úgy kezeljük, mint egy hosztolt eszközhívást. Amikor a modell webes keresést hív meg, az inferencia-hurok blokkolódik, meghív egy webes keresési szolgáltatást, és a szolgáltatás válaszát a modell kontextusába helyezi. A mi kialakításunkban ugyanezt tettük; de egy távoli szolgáltatás meghívása helyett a modell eszközhívását visszaküldtük a kliensnek a WebSocketen keresztül. Amikor a kliens válaszolt, beillesztettük a kliens eszközhívásra adott válaszát a kontextusba, és folytattuk a mintavételezést.

Ez a kialakítás rendkívül hatékony volt, mert egy ügynök bevezetése során megszüntette az ismétlődő API-munkát. Elvégezhetjük az inferencia előtti munkát egyszer, szünetet tarthatunk az eszköz végrehajtása miatt, majd a végén elvégezhetjük az inferencia utáni munkát.

Sajnos ez egy kevésbé ismerős és bonyolultabb API-formával járt. Azt szerettük volna, hogy a fejlesztők egyszerűen beépíthessék a WebSocket-támogatást anélkül, hogy új interakciós mód köré kelljen átírniuk az API-integrációjukat.

A most kiadott verzióban visszatértünk a megszokott megoldáshoz: továbbra is a response.create metódust használjuk ugyanazzal a testtel, és a previous_response_id paramétert alkalmazzuk, hogy az előző válasz állapotából folytassuk a beszélgetés kontextusát.

WebSocket-kapcsolat esetén a szerver a kapcsolathoz kötött, memóriában tárolt gyorsítótárban őrzi meg az előző válaszok állapotát. Ha egy utólagos response.create tartalmazza a previous_response_id értéket, akkor azt az állapotot a gyorsítótárból kérjük le ahelyett, hogy a teljes beszélgetést a nulláról építenénk újra.

Ez a gyorsítótárazott állapot a következőket tartalmazza:

• Az előző response objektum
• Előző beviteli és kimeneti elemek
• Eszközdefiníciók és névterek
• Újrafelhasználható mintavételezési elemek, például korábban renderelt tokenek

A memóriában tárolt korábbi válaszállapot újrafelhasználásával több jelentős optimalizálást tudtunk megvalósítani:

• Bizonyos biztonsági osztályozók és kérésérvényesítők mostantól csak az új bemenetet dolgozzák fel, nem minden alkalommal a teljes előzményt.
• A renderelt tokenek memóriabeli gyorsítótárának fenntartása, amelyhez hozzáadunk, hogy elkerüljük a szükségtelen tokenizálást
• Sikeres modellfeloldási/irányítási logikánk újrafelhasználása a kérések között 
• Nem blokkoló, inferencia utáni műveletek, például a számlázás, átfedésben a későbbi kérésekkel.

A cél az volt, hogy a lehető legközelebb kerüljünk a minimális többletterheléssel járó prototípushoz, de olyan API-felépítéssel, amelyet a fejlesztők már ismertek, és amelyre már építettek.

A WebSocket mód két hónapos intenzív fejlesztése után elindítottunk egy alfaverziót a vezető kódolóügynök-startupok számára, hogy integrálhassák azt az infrastruktúrájukba, és biztonságosan növelhessék a forgalmat. Az alfa felhasználók imádták, és akár 40%-os javulásról számoltak be⁠(új ablakban nyílik meg) ügynöki munkafolyamataikban. A pozitív alfa visszajelzések alapján készen álltunk az indulásra.

A bevezetés azonnali eredményeket hozott. A Codex gyorsan átállította a Responses API-forgalmának nagy részét WebSocket módra, és jelentős késleltetési javulást tapasztalt. A GPT‑5.3‑Codex‑Spark esetében elértük az 1000 TPS-es célunkat, és rövid ideig akár 4000 TPS-es kiugrásokat is tapasztaltunk, ami azt mutatja, hogy a Responses API képes lépést tartani a jóval gyorsabb inferenciával valós éles üzemi forgalomban. A hatás a fejlesztői közösségben is gyorsan megmutatkozott:

• A Codex gyorsan átterelte forgalmának nagy részét a WebSocketekre. A legújabb modelleket, például a GPT‑5.3‑Codex⁠(új ablakban nyílik meg) futtató Codex-felhasználók, GPT‑5.4⁠(új ablakban nyílik meg), és azon túl mindenki élvezheti a WebSocket mód sebességnövekedésének előnyeit.
• A Vercel integrálta a WebSocket módot az AI SDK-ba, és a késleltetés akár 40%-kal csökkent⁠(új ablakban nyílik meg).
• A Cline többfájlos munkafolyamatai 39%-kal gyorsabbak⁠(új ablakban nyílik meg).
• A Cursor OpenAI modelljei akár 30%-kal gyorsabbak lettek⁠(új ablakban nyílik meg).

A WebSocket mód a Responses API egyik legjelentősebb új képessége a 2025. márciusi indulása óta. Az OpenAI API- és Codex-csapatainak szoros együttműködésével mindössze néhány hét alatt jutottunk el az ötlettől az éles üzemi működésig. Nemcsak drámai mértékben javítja az ügynökök bevezetési késleltetését, hanem a fejlesztők egyre növekvő igényét is támogatja: ahogy a modellinferenciák gyorsulnak, az inferenciát körülvevő szolgáltatásoknak és rendszereknek is fel kell gyorsulniuk ahhoz, hogy ezek az előnyök a felhasználókhoz is eljussanak.