Ускоряване на агентните работни процеси с помощта на WebSockets в Responses API

Когато помолите Codex да поправи грешка, той преглежда Вашата кодова база за свързани файлове, прочита ги, за да изгради контекст, прави промени и изпълнява тестове, за да провери дали поправката е успешна. Всъщност това означава десетки двупосочни заявки към Responses API: определяне на следващото действие на модела, изпълнение на инструмент на Вашия компютър, изпращане на изходните данни от инструмента обратно към API и повтаряне на процеса.

Всички тези заявки могат да се натрупат до минути, през които потребителите чакат Codex да завърши сложни задачи. От гледна точка на забавянето, цикълът на агента Codex прекарва по-голямата част от времето си в три основни етапа: работа в API услугите (за валидиране и обработка на заявки), инференция на модела и време от страна на клиента (изпълнение на инструменти и изграждане на контекста на модела). Инференцията е етапът, през който моделът се изпълнява на графични процесори, за да генерира нови токени. В миналото изпълнението на инференция от големи езикови модели върху GPU беше най-бавната част от агентния цикъл, така че допълнителното време от API услугите лесно оставаше незабележимо. С ускоряването на процеса на инференция натрупаното допълнително време от API заявките в рамките на един агентен процес става много по-осезаемо.

В тази публикация ще обясним как ускорихме агентните цикли, използващи API, с 40% от начало до край, позволявайки на потребителите да усетят скока в скоростта на инференция от 65 до почти 1000 токена в секунда. Решихме този проблем чрез кеширане, елиминиране на ненужните преминавания през мрежата, подобряване на стека ни за безопасност, така че бързо да откриваме проблеми, и – най-важното – създаване на начин за създаване на постоянна връзка с Responses API, вместо да се налага да извършваме поредица от синхронни API извиквания.

В Responses API предишни флагмански модели като GPT‑5 и GPT‑5.2 работеха с приблизително 65 токена в секунда (TPS). При пускането на GPT‑5.3‑Codex‑Spark, бърз модел за писане на код, целта ни беше с един порядък по-висока скорост: над 1000 TPS, което беше възможно благодарение на специализиран хардуер на Cerebras, оптимизиран за инференция на големи езикови модели. За да сме сигурни, че потребителите могат да усетят истинската скорост на този нов модел, трябваше да намалим натоварването на API. 

Около ноември 2025 г. стартирахме спринт за подобряване на производителността на Responses API, като внедрихме множество оптимизации по отношение на забавянето по критичния път за една заявка. 

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

С тези подобрения постигнахме почти 45% подобрение във времето до първия токен (TTFT) – което отразява колко бързодействащ изглежда API – но тези подобрения все още не бяха достатъчно бързи за GPT‑5.3‑Codex‑Spark. Въпреки тези подобрения, натоварването на Responses API беше прекалено голямо спрямо скоростта на модела – тоест потребителите трябваше да изчакват процесорите (CPU), на които работи нашият API, преди да могат да използват графичните процесори (GPU), обслужващи модела.

По-фундаменталният проблем беше от структурен характер: всяка заявка към Codex се третираше като самостоятелна, като при всяка последваща заявка се обработваше състоянието на разговора и друг контекст, който можеше да се използва повторно. Дори когато по-голямата част от разговора не се беше променила, ние все пак плащахме за работа, обвързана с пълната история. С удължаването на разговорите тази повтаряща се обработка ставаше по-скъпа.

За да оптимизираме дизайна, преосмислихме транспортния протокол: можехме ли да поддържаме постоянна връзка и да кешираме състоянието, вместо всеки път да установяваме нова връзка по HTTP и да изпращаме цялата история на разговора при всяка последваща заявка? Идеята беше да се изпраща само нова информация, която изисква валидиране и обработка, а повторно използваемото състояние да се кешира в паметта за целия период на връзката. Това щеше да намали излишното натоварване на системата.

Разгледахме няколко различни подхода, включително WebSockets и двупосочен стрийминг чрез gRPC. Спряхме се на WebSockets, защото като прост протокол за пренос на съобщения, потребителите нямаше да се налага да променят форматите на входните и изходните данни на Responses API. Това решение беше удобно за разработчиците и се вписа в съществуващата ни архитектура с минимални сътресения.

Първият прототип на WebSocket промени представата ни за това какво е възможно по отношение на забавянето на API за отговори. Инженер от екипа на Codex със задълбочени експертни познания в целия стек на API създаде прототип, като остави Codex агента да работи през нощта.

В този прототип внедряването на агентите беше моделирано като един дълго изпълняващ се отговор. Използвайки функциите на asyncio, Responses API асинхронно блокираше в цикъла за семплиране, след като бъде извикан инструмент, и изпращаше събитие response.done обратно към клиента. След изпълнението на извикването на инструмента клиентите изпращаха обратно събитие response.append с резултата от инструмента, което деблокираше цикъла за семплиране и позволяваше на модела да продължи.

Аналогията тук е да се разглежда локалното извикване на инструмент като извикване на хостван инструмент. Когато моделът извика уеб търсене, цикълът за инференция се блокира, извиква услуга за уеб търсене и поставя отговора от услугата в контекста на модела. В нашия дизайн направихме същото, но вместо да извикаме отдалечена услуга, изпратихме заявката на инструмента на модела обратно към клиента през WebSocket. Когато клиентът отговори, поставихме отговора на извикването на инструмента на клиента в контекста и продължавахме да семплираме.

Този дизайн беше изключително ефективен, защото елиминира повтаряемата работа по API при внедряването на агента. Можехме да извършим предварителната обработка преди инференцията веднъж, да направим пауза за изпълнение на инструментите и да извършим постобработката след инференцията веднъж в края.

За съжаление, това беше за сметка на по-малко позната и по-сложна форма на API. Искахме разработчиците да могат лесно да добавят поддръжка за WebSocket, без да се налага да пренаписват интеграцията си с API за нов режим на взаимодействие.

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

При WebSocket връзка сървърът поддържа ограничен до връзката кеш в паметта на състоянието на предишния на отговор. Когато последващ response.create включва previous_response_id, извличаме това състояние от кеша, вместо да изграждаме отново целия разговор от нулата.

Това кеширано състояние включва:

• Обектът на предишния отговор
• Предишни входни и изходни елементи
• Определения на инструменти и пространства от имена
• Артефакти за повторно използване за семплиране като предварително рендерирани токени

Чрез повторно използване на състоянието на предишния отговор в паметта успяхме да постигнем няколко значителни оптимизации:

• Направихме така, че някои от нашите класификатори за безопасност и валидатори на заявки да обработват само нови входни данни, а не цялата история всеки път
• Поддържане на кеш в паметта на рендирани токени, към които добавяме, за да можем да пропуснем ненужната токенизация
• Повторно използване на успешната ни логика за разрешаване/маршрутизиране на модели при различните заявки 
• Паралелно изпълнение на неблокиращи задачи след инференция, като например фактуриране, с последващи заявки

Целта беше да се доближи максимално до прототипа с минимално допълнително натоварване, но с API структура, която разработчиците вече разбират и използват за изграждане на решения.

След двумесечен спринт за изграждане на режим WebSocket, пуснахме алфа-версия с ключови стартъпи, разработващи агенти за кодиране, за да могат да я интегрират в своята инфраструктура и безопасно да увеличат трафика. Потребителите на алфа-версията я харесаха, като отчетоха подобрения до 40%⁠(отваря се в нов прозорец) в своите работни процеси с агенти. Предвид положителната обратна връзка за алфа версията, бяхме готови за пускане.

Резултатите бяха незабавни. Codex бързо пренасочи по-голямата част от трафика си към Responses API в режим WebSocket, като отбеляза значително подобрение по отношение на забавянето. При GPT‑5.3‑Codex‑Spark постигнахме целта си от 1000 TPS и наблюдавахме пикове до 4000 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 е една от най-значимите нови възможности в API Responses от пускането му през март 2025 г. Преминахме от идеята до работещо решение в продукционна среда само за няколко седмици благодарение на тясното сътрудничество между екипите на API на OpenAI и Codex. Той не само драстично подобрява забавянето при внедряването на агенти, но и отговаря на нарастваща нужда на разработчиците: с ускоряването на инференцията на моделите услугите и системите, които я обграждат, също трябва да се ускорят, за да могат потребителите да усетят тези подобрения.