Прискорення агентних робочих процесів за допомогою WebSockets в API Responses

Коли ви просите Codex виправити помилку, він сканує вашу кодову базу в пошуках релевантних файлів, читає їх, аби зрозуміти контекст, вносить зміни та запускає тести, щоб перевірити, чи спрацювало виправлення. На практиці це означає десятки обмінів запитами до API Responses між клієнтом та API: визначити наступну дію моделі, запустити інструмент на вашому комп’ютері, надіслати вивід інструмента назад до API і повторити.

Усі ці запити можуть складатися в хвилини, які користувачі витрачають на очікування, поки Codex виконає складні завдання. З погляду затримки цикл агента Codex витрачає більшу частину часу на трьох основних етапах: роботу в сервісах API (для перевірки й обробки запитів), інференцію моделі та час на боці клієнта (запуск інструментів і побудову контексту моделі). Інференція — це етап, на якому модель працює на GPU, щоб генерувати нові токени. У минулому виконання інференції LLM на GPU було найповільнішою частиною циклу роботи агента, і накладні витрати на API-сервіс було легко приховати. У міру того, як інференс стає швидшим, сукупні накладні витрати API від агентного розгортання стають значно помітнішими.

У цьому дописі ми пояснимо, як нам вдалося зробити цикли агента з використанням API на 40% швидшими наскрізно, давши користувачам змогу відчути стрибок швидкості інференсу з 65 до майже 1 000 токенів за секунду. Ми досягли цього за допомогою кешування, усунення зайвих мережевих переходів, удосконалення нашого стеку безпеки для швидкого виявлення проблем, і що найважливіше — створення способу встановлювати постійне з’єднання з API Responses, замість того, щоб виконувати серію синхронних викликів API.

В API Responses попередні флагманські моделі, як-от GPT‑5 і GPT‑5.2, працювали зі швидкістю приблизно 65 токенів за секунду (TPS). На момент запуску GPT‑5.3‑Codex‑Spark, швидкої моделі для програмування, нашою метою було досягти на порядок вищої швидкості — понад 1 000 TPS, завдяки спеціалізованому обладнанню Cerebras, оптимізованому для інференсу LLM. Щоб користувачі могли відчути швидкість цієї нової моделі по-справжньому, нам довелося зменшити накладні витрати API. 

Приблизно в листопаді 2025 року ми запустили спринт із підвищення продуктивності для API Responses, реалізувавши багато оптимізацій затримки на критичному шляху для єдиного запиту: 

• Кешування оброблених токенів і конфігурації моделі у пам’яті задля уникнення ресурсомісткої токенізації та мережевих викликів для багатокрокових відповідей
• Зменшення затримки мережевих переходів завдяки усуненню викликів до проміжних сервісів (наприклад, обробки зображень для зміни роздільної здатності) та безпосередньому виклику сервісу інференції
• Удосконалення нашого стеку безпеки, щоб ми могли запускати певні класифікатори й швидше позначати розмови

Завдяки цим удосконаленням нам вдалося майже на 45% скоротити час до першого токена (TTFT) — показник, що відображає те, наскільки швидкодійним здається API. Та навіть цих покращень усе ще було недостатньо для GPT‑5.3‑Codex‑Spark. Навіть із цими покращеннями накладні витрати API Responses були надто великими порівняно зі швидкістю моделі: користувачам доводилося чекати на CPU, на яких працював наш API, перш ніж вони могли скористатися GPU, що обслуговували модель.

Глибша проблема була структурною: ми розглядали кожен запит до Codex як незалежний, обробляючи стан розмови та інший повторно використовуваний контекст у кожному наступному запиті. Навіть коли більша частина розмови не змінювалася, ми все одно платили за роботу, пов’язану з усією історією. Зі збільшенням тривалості розмов росла й вартість повторної обробки.

Аби вдосконалити архітектуру, ми переосмислили транспортний протокол: чи могли б ми підтримувати постійне з’єднання й кешувати стан, замість того щоб щоразу встановлювати нове з’єднання через HTTP і надсилати повну історію розмови для кожного наступного запиту? Ідея полягала в тому, щоб надсилати лише нову інформацію, яка потребує перевірки й обробки, і кешувати повторно використовуваний стан у пам’яті протягом усього часу існування з’єднання. Це зменшило б накладні витрати на зайву роботу.

Ми розглянули кілька різних підходів, зокрема WebSockets і двонаправлене потокове передавання gRPC. Ми зупинилися на WebSockets, оскільки в разі використання простого протоколу транспортування повідомлень користувачам не довелося б змінювати структури вхідних і вихідних даних в API Responses. Він був зручним для розробників і добре вписувався в нашу наявну архітектуру з мінімальними змінами.

Перший прототип WebSocket змінив наше уявлення про можливості зменшення затримки API Responses. Інженер команди Codex зі значним досвідом роботи з API створив прототип, запустивши агента Codex за одну ніч.

У згаданому прототипі агентні розгортання моделювалися як одна довготривала відповідь. За рахунок можливостей asyncio API Responses асинхронно блокувався в циклі вибірки після виклику інструмента й надсилав клієнту 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 швидко перевів більшість трафіку API Responses на режим WebSocket, досягнувши значного зменшення затримки. Для GPT‑5.3‑Codex‑Spark ми досягли цільового показника в 1 000 TPS і спостерігали пікові сплески до 4 000 TPS, що показало, що API Responses могло встигати за значно швидшим інференсом в умовах реального продакшен-трафіку. У спільноті розробників вплив також швидко став помітним:

• 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 ми пройшли шлях від ідеї до запуску в продакшен усього за кілька тижнів. Це не лише значно зменшує затримку розгортання агентів, а й відповідає зростаючій потребі розробників: у міру того як інференс моделі пришвидшується, сервіси й системи, що його оточують, також мають працювати швидше, щоб передати ці переваги користувачам.