Responses API-дегі WebSockets арқылы агенттік жұмыс ағындарын жеделдету

Codex-тен қатені түзетуді сұрағанда, ол код базаңыздан қатысты файлдарды іздейді, контекст құру үшін оларды оқиды, түзетулер енгізеді және түзетудің жұмыс істегенін тексеру үшін тесттерді іске қосады. Ішкі жағында бұл ондаған рет алмасатын Responses API сұрауын білдіреді: модельдің келесі әрекетін анықтау, компьютеріңізде құралды іске қосу, құралдың шығысын API-ге кері жіберу және қайталау.

Осы сұраулардың бәрі қосылып, пайдаланушылар Codex-тің күрделі тапсырмаларды аяқтауын күтуге жұмсайтын минуттарға айналуы мүмкін. Кідіріс тұрғысынан қарағанда, Codex агент циклі уақытының басым бөлігін үш негізгі кезеңде өткізеді: API қызметтеріндегі жұмыс (сұрауларды тексеру және өңдеу үшін), модель инференсі және клиент жағындағы уақыт (құралдарды іске қосу және модель контекстін құру). Инференс — модель жаңа токендерді генерациялау үшін GPU-ларда орындалатын кезең. Бұрын GPU-ларда LLM (үлкен тілдік модель) инференсін іске қосу агенттік циклдің ең баяу бөлігі болатын, сондықтан API қызметінің үстеме шығынын жасыру оңай еді. Инференс жылдамдаған сайын, агенттік орындаудан туатын жиынтық API үстеме шығыны әлдеқайда айқын бола түсті.

Бұл жазбада API-ді қолданатын агент циклдерін басынан аяғына дейін 40% жылдамырақ еткенімізді, соның арқасында пайдаланушылардың инференс жылдамдығының секундына 65-тен 1 000-ға жуық токенге дейін секіргенін қалай сезіне алғанын түсіндіреміз. Біз бұған кэштеу, қажетсіз желілік өтулерді жою, мәселелерді жылдам белгілеу үшін қауіпсіздік стекімізді жақсарту және — ең бастысы — синхронды API қоңырауларының тізбегін жасаудың орнына Responses API-ге тұрақты қосылым құру тәсілін жасау арқылы қол жеткіздік.

Responses API-де GPT‑5 және GPT‑5.2 сияқты алдыңғы негізгі модельдер шамамен секундына 65 токенмен (TPS) жұмыс істеді. Жылдам кодтау моделі GPT‑5.3‑Codex‑Spark‑ты іске қосу үшін біздің мақсатымыз бұдан бір реттік шамаға жылдамырақ, яғни 1 000 TPS-тен жоғары болды; бұған LLM инференсі үшін оңтайландырылған мамандандырылған Cerebras жабдығы мүмкіндік берді. Пайдаланушылар осы жаңа модельдің шынайы жылдамдығын сезіне алуы үшін, API үстеме шығынын азайтуымыз қажет болды.

2025 жылдың қарашасы шамасында біз Responses API бойынша өнімділік спринтін бастадық және бір сұраудың критикалық жол кідірісін азайтатын көптеген оңтайландыруларды енгіздік:

• Көп айналымды жауаптар үшін қымбат токенизация мен желілік қоңырауларды өткізіп жіберу мақсатында рендерленген токендер мен модель конфигурациясын жадта кэштеу
• Аралық қызметтерге қоңырауларды (мысалы, кескін өңдеу ажыратымдылығы) алып тастап, тікелей инференс қызметінің өзіне жүгіну арқылы желілік өтудің кідірісін азайту
• Белгілі бір классификаторларды сөйлесулерді жылдамырақ белгілеу үшін іске қоса алуымыз мақсатында қауіпсіздік стекімізді жақсарту

Осы жақсартулардың арқасында біз бірінші токенге дейінгі уақытта (TTFT) шамамен 45% жақсаруды көрдік — бұл API-дің қаншалықты жедел сезілетінін көрсетеді, бірақ бұл жақсартулар GPT‑5.3‑Codex‑Spark үшін әлі де жеткілікті жылдам болмады. Осы жақсартулардың өзімен де Responses API үстеме шығыны модель жылдамдығына қатысты тым үлкен болды — яғни пайдаланушылар модельге қызмет көрсететін GPU-ларды қолданбас бұрын, біздің API-ді іске қосатын CPU-лардың жұмысын күтуге мәжбүр болды.

Тереңірек мәселе құрылымдық еді: біз әр Codex сұрауын тәуелсіз деп қарап, сөйлесу күйін және басқа да қайта пайдаланылатын контексті әрбір кейінгі сұрауда өңдедік. Сөйлесудің басым бөлігі өзгермесе де, біз бәрібір толық тарихқа байланысты жұмыстың құнын төледік. Сөйлесулер ұзарған сайын, бұл қайталанатын өңдеу қымбаттай түсті.

Дизайнды ықшамдау үшін біз тасымалдау протоколын қайта ойластырдық: HTTP арқылы әр кейінгі сұрау үшін жаңа қосылым орнатып, сөйлесудің толық тарихын жіберудің орнына, тұрақты қосылым ұстап, күйді кэштей аламыз ба? Идея тек тексеру мен өңдеуді қажет ететін жаңа ақпаратты жіберіп, қайта пайдаланылатын күйді қосылым өмірі бойы жадта кэштеу болды. Бұл артық жұмыстан туатын үстеме шығынды азайтар еді.

Біз бірнеше түрлі тәсілді, соның ішінде WebSockets пен gRPC екіжақты ағынмен жіберуді қарастырдық. Біз WebSockets-ке тоқтадық, себебі қарапайым хабарлама тасымалдау протоколы ретінде ол пайдаланушылардан Responses API кіріс және шығыс пішіндерін өзгертуді талап етпейді. Ол әзірлеушіге ыңғайлы болды және біздің бар архитектурамызға аз ғана өзгеріспен сай келді.

Алғашқы WebSocket прототипі Responses API кідірісі туралы мүмкін деп ойлағанымызды өзгертті. API стегі бойынша терең тәжірибесі бар Codex командасының инженері бір түн ішінде Codex агентін іске қосып, прототипті жинақтады.

Бұл прототипте агенттік орындаулар бір ұзақ жұмыс істейтін Response ретінде модельденді. asyncio мүмкіндіктерін пайдаланып, құрал шақыруы таңдалғаннан кейін Responses API sampling циклінде асинхронды түрде бөгелетін, ал Responses API клиентке response.done оқиғасын қайта жіберетін. Құрал шақыруын орындағаннан кейін клиенттер құрал нәтижесімен response.append оқиғасын қайта жіберетін, бұл sampling циклін бұғаттан шығарып, модельге жалғастыруға мүмкіндік беретін.

Мұндағы ұқсастық — жергілікті құрал шақыруын hosted tool call ретінде қарастыру. Модель веб-іздеуді шақырғанда, инференс циклі бөгеледі, веб-іздеу қызметін шақырады және қызмет жауабын модель контекстіне енгізеді. Біздің дизайнда да дәл солай істедік; бірақ қашықтағы қызметті шақырудың орнына, модельдің құрал шақыруын клиентке WebSocket арқылы кері жібердік. Клиент жауап бергенде, біз клиенттің құрал шақыруы жауабын контекстке енгізіп, sampling-ті жалғастырдық.

Бұл дизайн өте тиімді болды, өйткені ол агенттік орындау барысында қайталанатын API жұмысын жойды. Біз инференске дейінгі жұмысты бір рет орындай алдық, құрал орындалуы үшін кідіріп, инференстен кейінгі жұмысты соңында бір рет атқара алдық.

Өкінішке қарай, бұл онша таныс емес әрі күрделірек API пішіні есебінен келді. Біз әзірлеушілердің жаңа өзара әрекеттесу режиміне сай API интеграциясын қайта жазбай-ақ WebSocket қолдауын қоса алуын қаладық.

Іске қосқан нұсқада біз қайтадан таныс пішінге оралдық: сол денемен response.create қолдануды жалғастырып, сөйлесу контекстін алдыңғы жауап күйінен жалғастыру үшін previous_response_id пайдаландық.

WebSocket қосылымында сервер алдыңғы жауап күйінің қосылым ауқымындағы жадтағы кэшін сақтайды. Кейінгі response.create ішінде previous_response_id болғанда, біз бұл күйді бүкіл сөйлесуді нөлден қайта құрудың орнына кэштен аламыз.

Бұл кэштелген күйге мыналар кіреді:

• Алдыңғы response нысаны
• Алдыңғы кіріс және шығыс элементтері
• Құрал анықтамалары мен атау кеңістіктері
• Бұрын рендерленген токендер сияқты қайта пайдаланылатын sampling артефактілері

Жадтағы алдыңғы жауап күйін қайта пайдалану арқылы біз бірнеше ірі оңтайландыруды іске асыра алдық:

• Кейбір қауіпсіздік классификаторлары мен сұрау валидаторларын әр жолы толық тарихты емес, тек жаңа кірісті өңдейтін ету
• Қажетсіз токенизацияны өткізіп жіберу үшін үстіне қосып отыратын рендерленген токендердің жадтағы кэшін сақтау
• Сұраулар арасында модельді сәтті айқындау/маршруттау логикасын қайта пайдалану
• Есепшот шығару сияқты бөгемейтін инференстен кейінгі жұмысты кейінгі сұраулармен қабаттастыру

Мақсат — әзірлеушілер бұрыннан түсініп, соның айналасында құрып қойған API пішінін сақтай отырып, ең аз үстеме шығынды прототипке барынша жақындау болды.

WebSocket режимін құруға арналған екі айлық спринттен кейін біз оны негізгі кодтау агент стартаптарымен бірге альфа ретінде іске қостық, олар оны өз инфрақұрылымына біріктіріп, трафикті қауіпсіз түрде біртіндеп арттыра алсын дедік. Альфа пайдаланушылары оны жоғары бағалап, агенттік жұмыс ағындарында 40%-ға дейінгі жақсару⁠(жаңа терезеде ашылады) туралы хабарлады. Альфадағы оң пікірлерді ескере отырып, біз іске қосуға дайын болдық.

Іске қосудың нәтижелері бірден байқалды. Codex өздерінің Responses API трафигінің басым бөлігін WebSocket режиміне жылдам ауыстырып, кідірістің елеулі жақсарғанын көрді. GPT‑5.3‑Codex‑Spark үшін біз 1 000 TPS мақсатымызға жеттік және 4 000 TPS-ке дейінгі шарықтауларды көрдік, бұл Responses API-дің нақты өндірістік трафикте анағұрлым жылдам инференске ілесе алатынын көрсетті. Бұл әсер әзірлеушілер қауымдастығында да тез байқалды:

• Codex өз трафигінің басым бөлігін WebSockets-ке тез ауыстырды. GPT‑5.3‑Codex⁠(жаңа терезеде ашылады), GPT‑5.4⁠(жаңа терезеде ашылады) және одан кейінгі ең жаңа модельдерді қолданатын Codex пайдаланушыларының бәрі WebSocket режимінің жеделдеуінен пайда көреді.
• Vercel WebSocket режимін AI SDK-ға біріктіріп, кідірістің 40%-ға дейін⁠(жаңа терезеде ашылады) азайғанын көрді.
• Cline-ның көп файлды жұмыс ағындары 39% жылдамырақ⁠(жаңа терезеде ашылады) болды.
• Cursor ішіндегі OpenAI модельдері 30%-ға дейін жылдамырақ⁠(жаңа терезеде ашылады) болды.

WebSocket режимі — 2025 жылдың наурызында іске қосылғаннан бергі Responses API-дегі ең маңызды жаңа мүмкіндіктердің бірі. OpenAI-дің API және Codex командалары арасындағы тығыз ынтымақтастықтың арқасында біз идеядан өндірісте іске қосуға дейін небәрі бірнеше аптада жеттік. Бұл агенттік орындау кідірісін күрт жақсартып қана қоймай, жасаушылардың өсіп келе жатқан қажеттілігін де қолдайды: модель инференсі жылдамдаған сайын, осы артықшылықтарды пайдаланушыларға жеткізу үшін инференсті қоршаған қызметтер мен жүйелер де жылдамдауы керек.