Забрзување на агентските работни текови со WebSockets во Responses API

Кога ќе побараш од Codex да поправи грешка, тој ја пребарува твојата кодна база за релевантни датотеки, ги чита за да изгради контекст, прави измени и извршува тестови за да потврди дека поправката функционира. Зад сцената, тоа значи десетици наизменични барања до Responses API: да се одреди следното дејство на моделот, да се изврши алатка на вашиот компјутер, да се испрати резултатот од алатката назад до API и да се повтори.

Сите овие барања можат да се претворат во минути што корисниците ги поминуваат чекајќи Codex да заврши сложени задачи. Од перспектива на латенцијата, циклусот на агентот Codex го поминува најголемиот дел од времето во три главни фази: работа во API услугите (за валидација и обработка на барањата), инференција на моделот и време на страната на клиентот (извршување алатки и градење контекст за моделот). Инференција е фазата во која моделот се извршува на графички процесори за да генерира нови токени. Во минатото, извршувањето на инференција на големи јазични модели (LLM) на графички процесори беше најбавниот дел од циклусот на агентот, па дополнителниот трошок на API услугата лесно можеше да се прикрие. Како што инференцијата станува побрза, кумулативниот дополнителен товар од API при агентско воведување станува многу позабележлив.

Во оваа објава, ќе објасниме како ги направивме циклусите на агентите со користење на API за 40 % побрзи од почеток до крај, овозможувајќи им на корисниците да го почувствуваат скокот во брзината на инференција од 65 до речиси 1.000 токени во секунда. Кон ова пристапивме преку кеширање, елиминирање на непотребните мрежни скокови, подобрување на нашиот безбедносен стак за брзо означување на проблеми и, што е најважно, создавање начин за воспоставување постојана врска со Responses API, наместо да мора да се прави серија синхрони API повици.

Во Responses API, претходните водечки модели како GPT‑5 и GPT‑5.2 работеа со приближно 65 токени во секунда (TPS). За лансирањето на GPT‑5.3‑Codex‑Spark, брз модел за кодирање, нашата цел беше да биде за цел ред на големина побрз: над 1.000 TPS, овозможено од специјализиран хардвер на Cerebras оптимизиран за изведување на заклучоци со големи јазични модели (LLM). За да се увериме дека корисниците ќе можат да ја искусат вистинската брзина на овој нов модел, моравме да го намалиме оптоварувањето на API. 

Околу ноември 2025 г., започнавме спринт за перформанси на Responses API, воведувајќи многу оптимизации на латенцијата на критичната патека за едно барање: 

• Кеширање на рендерирани токени и конфигурацијата на моделот во меморија за да се прескокнат скапата токенизација и мрежните повици за повеќекратни одговори
• Намалување на латенцијата на мрежните скокови со елиминирање на повиците кон посредни услуги (на пример, резолуција на обработка на слики) и со директно повикување на самата услуга за инференција
• Подобрување на нашиот безбедносен систем за да можеме да извршуваме одредени класификатори за побрзо означување разговори

Со овие подобрувања, забележавме подобрување од речиси 45% во времето до првиот токен (TTFT), што одразува колку одзивно делува AP, но овие подобрувања сè уште не беа доволно брзи за GPT‑5.3‑Codex‑Spark. Дури и со овие подобрувања, дополнителниот товар на Responses API беше преголем во однос на брзината на моделот, односно, корисниците мораа да чекаат на CPU што го извршуваа нашиот API пред да можат да ги користат GPU што го опслужуваа моделот.

Подлабокиот проблем беше структурен: секое барање до Codex го третиравме како независно, обработувајќи ја состојбата на разговорот и друг контекст што може повторно да се употреби во секое следно барање. Дури и кога поголемиот дел од разговорот не беше променет, сепак плаќавме за работа што беше поврзана со целосната историја. Како што разговорите стануваа подолги, тоа повторено обработување стануваше поскапо.

За да го поедноставиме и подобриме дизајнот, повторно го осмисливме транспортниот протокол: дали можевме да одржуваме постојана врска и да ја кешираме состојбата, наместо за секое дополнително барање повторно да воспоставуваме нова врска преку HTTP и да ја испраќаме целосната историја на разговорот? Идејата беше да се испраќаат само новите информации што бараат валидација и обработка, а повторно употребливата состојба да се кешира во меморија за времетраењето на врската. Ова би го намалило оптоварувањето од непотребна работа.

Разгледавме неколку различни пристапи, вклучувајќи WebSockets и двонасочно стримување со gRPC. Се одлучивме за WebSockets бидејќи, како едноставен протокол за пренос на пораки, корисниците нема да мора да ги менуваат влезните и излезните структури во Responses API. Беше лесно за програмерите и се вклопуваше во нашата постојна архитектура со мали нарушувања.

Првиот WebSocket прототип го промени она што мислевме дека е можно во однос на латенцијата на Responses API. Инженер од тимот на Codex со длабоко познавање на API стaкот создаде прототип со извршување на агент на Codex преку ноќ.

Во тој прототип, агентските извршувања беа моделирани како еден единствен долготраен одговор. Користејќи ги функциите на asyncio, Responses API асинхроно ќе се блокираше во јамката за земање примероци откако ќе се земеше примерок од повикот на алатката, а Responses API ќе испратеше настан response.done назад до клиентот. По извршувањето на повикот на алатката, клиентите ќе испратеа настан response.append со резултатот од алатката, што ја деблокираше јамката за земање примероци и му овозможи на моделот да продолжи.

Аналогијата тука е дека локалниот повик на алатка се третира како хостиран повик на алатка. Кога моделот повикува веб-пребарување, циклусот на изведување се блокира, повикува услуга за веб-пребарување и го става одговорот од услугата во контекстот на моделот. Во нашиот дизајн, го направивме истото; но наместо да повикуваме оддалечена услуга, го испративме повикот на алатка на моделот назад до клиентот преку WebSocket. Кога клиентот одговори, го ставивме одговорот на клиентот за повикот на алатката во контекстот и продолживме со земање примероци.

Овој дизајн беше исклучително ефикасен затоа што ја елиминираше повторената работа со API при воведување на агент. Можевме еднаш да извршиме пред-инференциска работа, да паузираме за извршување на алатката и еднаш да извршиме пост-инференциска работа на крајот.

За жал, ова имаше цена: помалку позната и посложена форма на API. Сакавме програмерите да можат лесно да додадат поддршка за WebSocket без да мораат да ја преработуваат својата интеграција на API за нов начин на интеракција.

За верзијата што ја објавивме, се вративме на позната форма: продолжете да го користите response.create со истото тело, и користете previous_response_id за да го продолжите контекстот на разговорот од состојбата на претходниот одговор.

На WebSocket врска, серверот чува кеш во меморија, ограничен на врската, за претходната состојба на одговорот. Кога последователен response.create вклучува previous_response_id, ја преземаме таа состојба од кешот наместо повторно да го градиме целиот разговор од почеток.

Таа кеширана состојба вклучува:

• Претходниот response објект
• Претходни влезни и излезни ставки
• Дефиниции на алатки и именски простори
• Артефакти за повеќекратна употреба за семплирање, како претходно рендерирани токени

Со повторна употреба на состојбата од претходниот одговор во меморија, успеавме да имплементираме неколку големи оптимизации:

• Ги правиме дел од нашите безбедносни класификатори и валидатори на барања да обработуваат само нови податоци, а не целата историја секојпат
• Одржување кеш во меморија од рендерирани токени што го надополнуваме за да можеме да прескокнеме непотребна токенизација
• Повторна употреба на нашата успешна логика за решавање и насочување на модел за различни барања 
• Преклопување на неблокирачката работа по инференцијата како што е наплата со следните барања

Целта беше да се доближи што е можно повеќе до прототипот со минимални дополнителни трошоци, но со форма на 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 % побрзи⁠(се отвора во нов прозорец).
• Моделите на OpenAI во Cursor станаа до 30 % побрзи⁠(се отвора во нов прозорец).

Режимот WebSocket е една од најзначајните нови можности во Responses API од неговото лансирање на 01.03.2025 г. За само неколку недели, од идеја стигнавме до продукција преку тесна соработка меѓу тимовите за API и Codex на OpenAI. Тоа не само што драматично ја подобрува латенцијата при пуштање на агентите во употреба, туку и поддржува растечка потреба кај програмерите: како што инференцијата на моделите станува побрза, услугите и системите што ја опкружуваат исто така треба да се забрзаат за овие придобивки да им се пренесат на корисниците.