Nyepetake workflow agen nganggo WebSockets ing Responses API

Nalika sampeyan njaluk Codex ndandani bug, Codex mindhai codebase sampeyan kanggo file sing relevan, maca file-file kuwi kanggo mbangun konteks, ngowahi, lan mbukak tes kanggo mriksa apa perbaikane kasil. Ing balik layar, iki tegesé ana puluhan panjalukan Responses API bolak-balik: nemtokake tumindak sabanjuré saka model, mbukak tool ing komputer sampeyan, ngirim output tool bali menyang API, lan mbaleni maneh.

Kabeh panjalukan iki bisa akumulasi dadi menit-menit wektu nunggu pangguna supaya Codex ngrampungake tugas sing kompleks. Saka sudut pandang latensi, loop agen Codex nggunakke akèh-akèhé wektu ing telung tahap utama: nggarap ing layanan API (kanggo validasi lan ngolah panjalukan), inferensi model, lan wektu sisih klien (mbukak tool lan mbangun konteks model). Inferensi yaiku tahap nalika model mlaku ing GPU kanggo ngasilake token anyar. Mbiyèn, inferensi LLM ing GPU iku bagean paling alon saka loop agentic, mula overhead layanan API gampang didhelikake. Nalika inferensi saya cepet, overhead API kumulatif saka rollout agentic dadi luwih katon.

Ing kiriman iki, kita bakal nerangake carane nggawe loop agen nganggo API dadi 40% luwih cepet saka ujung nganti ujung, supaya pangguna bisa ngrasakake loncatan kacepetan inferensi saka 65 dadi meh 1.000 token per detik. Kita nyedhaki iki liwat caching, mbusak network hop sing ora perlu, ningkatake safety stack supaya cepet nandhani masalah, lan—sing paling penting—mbangun cara kanggo nggawe sambungan persisten menyang Responses API, tinimbang kudu nggawe rangkaian telpon API sinkron.

Ing Responses API, model unggulan sadurungé kaya GPT‑5 lan GPT‑5.2 mlaku kira-kira 65 token per detik (TPS). Kanggo peluncuran GPT‑5.3‑Codex‑Spark, model coding sing cepet, target kita yaiku luwih cepet sepuluh kaping: luwih saka 1.000 TPS, dimungkinkan déning hardware Cerebras khusus sing dioptimalake kanggo inferensi LLM. Kanggo mesthekake pangguna bisa ngrasakake kacepetan sejati saka model anyar iki, kita kudu nyuda overhead API.

Sekitar November 2025, kita miwiti sprint kinerja ing Responses API, nerapake akèh optimisasi kanggo latensi critical path saka siji panjalukan:

• Nyimpen token sing wis dirender lan konfigurasi model ing memori supaya bisa ngliwati tokenisasi lan network call sing larang kanggo respons multi-turn
• Nyuda latensi network hop kanthi ngilangi telpon menyang layanan perantara (contone, resolusi pemrosesan gambar) lan langsung nelpon layanan inferensi dhewe
• Ningkatake safety stack supaya kita bisa mbukak classifier tartamtu kanggo nandhani obrolan luwih cepet

Kanthi perbaikan iki, kita ndeleng meh 45% peningkatan ing time to first token (TTFT)—sing nuduhake sepira responsife API—nanging perbaikan iki isih durung cukup cepet kanggo GPT‑5.3‑Codex‑Spark. Sanajan wis ana perbaikan iki, overhead Responses API isih kegedhen dibandhingake karo kacepetan model—tegese, pangguna kudu ngenteni CPU sing mbukak API kita sadurunge bisa nggunakake GPU sing nglayani model.

Masalah sing luwih jero iku struktural: saben panjalukan Codex kita anggep mandiri, kanthi ngolah state obrolan lan konteks liyane sing bisa digunakake maneh ing saben panjalukan susulan. Sanajan mayoritas obrolan ora owah, kita isih mbayar kerja sing gegandhengan karo riwayat lengkap. Nalika obrolan saya dawa, pangolahan sing dibaleni iki dadi luwih larang.

Kanggo ngrapetake desain, kita mikir maneh protokol transport: apa kita bisa njaga sambungan persisten lan nyimpen state ing cache, tinimbang nggawe sambungan anyar liwat HTTP lan ngirim riwayat obrolan lengkap kanggo saben panjalukan susulan? Gagasane yaiku mung ngirim informasi anyar apa wae sing mbutuhake validasi lan pangolahan lan nyimpen state sing bisa digunakake maneh ing memori sajrone umur sambungan. Iki bakal nyuda overhead saka kerja sing redundan.

Kita nimbang sawetara pendekatan beda, kalebu WebSockets lan streaming bidirectional gRPC. Pungkasane kita milih WebSockets amarga minangka protokol transport pesen sing sederhana, pangguna ora perlu ngganti bentuk input lan output Responses API. Iki ramah pangembang lan cocog karo arsitektur sing wis ana kanthi gangguan sing sithik.

Prototipe WebSocket pisanan ngowahi apa sing kita kira mungkin kanggo latensi Responses API. Sijining insinyur ing tim Codex sing nduwèni keahlian jero ing sakabèhé stack API nyusun prototipe kanthi mbukak agen Codex sewengi.

Ing prototipe kuwi, rollout agentic dimodelake dadi siji Response sing mlaku suwé. Nggunakake fitur asyncio, Responses API bakal mblokir kanthi asinkron ing loop sampling sawisé tool call disampel, lan Responses API bakal ngirim event response.done bali menyang klien. Sawisé ngeksekusi tool call, klien bakal ngirim bali event response.append kanthi asil tool, sing mbukak maneh loop sampling lan ngidini model nerusake.

Analogi ing kéné yaiku nganggep tool call lokal kaya tool call sing di-host. Nalika model nelpon web search, loop inferensi mandheg, nelpon layanan web search, lan nyelehake respons layanan menyang konteks model. Ing desain kita, kita nindakake perkara sing padha; nanging tinimbang nelpon layanan remote, kita ngirim tool call saka model menyang klien liwat WebSocket. Nalika klien mangsuli, kita nyelehake respons tool call saka klien menyang konteks lan nerusake sampling.

Desain iki efektif banget amarga ngilangi kerja API sing bola-bali sajrone rollout agen. Kita bisa nindakake kerja pra-inferensi sepisan, ngaso kanggo eksekusi tool, lan nindakake kerja pasca-inferensi sepisan ing pungkasan.

Nanging, iki dibayar kanthi bentuk API sing kurang familier lan luwih rumit. Kita pengin pangembang bisa langsung nambah dukungan WebSocket tanpa kudu nulis ulang integrasi API ing mode interaksi anyar.

Kanggo versi sing kita luncurake, kita bali menyang bentuk sing familier: tetep nggunakake response.create kanthi body sing padha, lan nggunakake previous_response_id kanggo nerusake konteks obrolan saka state respons sadurungé.

Ing sambungan WebSocket, server njaga cache state respons sadurungé ing memori sing cakupane sambungan. Nalika response.create susulan ngemot previous_response_id, kita njupuk state kuwi saka cache tinimbang mbangun maneh obrolan lengkap saka nol.

State cache kuwi kalebu:

• Objek response sadurungé
• Item input lan output sadurungé
• Definisi tool lan namespace
• Artefak sampling sing bisa digunakake maneh, kaya token sing wis dirender sadurungé

Kanthi nggunakke maneh state respons sadurungé ing memori, kita bisa nerapake sawetara optimisasi utama:

• Nggawe sawetara classifier safety lan validator panjalukan mung ngolah input anyar, dudu riwayat lengkap saben wektu
• Njaga cache token sing wis dirender ing memori lan terus ditambahi supaya bisa ngliwati tokenisasi sing ora perlu
• Nggunakke maneh logika resolusi/routing model sing wis sukses antar-panjalukan
• Numpangtindihake kerja pasca-inferensi sing ora mblokir kaya billing karo panjalukan sabanjuré

Tujuane yaiku nyedhaki sabisane prototipe kanthi overhead minimal, nanging kanthi bentuk API sing wis dimangerteni lan wis dienggo mbangun déning para pangembang.

Sawisé sprint rong wulan kanggo mbangun mode WebSocket, kita ngluncurake alpha karo startup agen coding utama supaya bisa ngintegrasikake menyang infrastrukturé lan nambah traffic kanthi aman. Pangguna alpha seneng banget, lan nglaporake nganti 40% peningkatan⁠(mbukak ing jendhela anyar) ing workflow agentic. Amarga umpan balik alpha positif, kita siap ngluncurake.

Asil peluncuran langsung katon. Codex kanthi cepet ngalihaké mayoritas traffic Responses API menyang mode WebSocket, lan ndeleng peningkatan latensi sing signifikan. Kanggo GPT‑5.3‑Codex‑Spark, kita nggayuh target 1.000 TPS lan ndeleng burst nganti 4.000 TPS, nuduhake yen Responses API bisa ngetutake inferensi sing luwih cepet ing traffic produksi nyata. Dampake uga cepet katon ing komunitas pangembang:

• Codex kanthi cepet ngalihaké mayoritas trafficé menyang WebSockets. Pangguna Codex sing mbukak model paling anyar kaya GPT‑5.3‑Codex⁠(mbukak ing jendhela anyar), GPT‑5.4⁠(mbukak ing jendhela anyar), lan liya-liyané kabèh entuk manfaat saka percepatan mode WebSocket.
• Vercel ngintegrasikake mode WebSocket menyang AI SDK lan ndeleng latensi mudhun nganti 40%⁠(mbukak ing jendhela anyar).
• Workflow multi-file Cline dadi 39% luwih cepet⁠(mbukak ing jendhela anyar).
• Model OpenAI ing Cursor dadi nganti 30% luwih cepet⁠(mbukak ing jendhela anyar).

Mode WebSocket iku salah siji kapabilitas anyar sing paling wigati ing Responses API wiwit peluncurane ing Maret 2025. Kita mlaku saka gagasan nganti mlaku ing produksi mung sajrone sawetara minggu liwat kolaborasi cedhak antara tim API lan tim Codex OpenAI. Iki ora mung ningkatake latensi rollout agen kanthi dramatis, nanging uga ndhukung kabutuhan para builder sing saya tuwuh: nalika inferensi model saya cepet, layanan lan sistem ing saubengé inferensi uga kudu nyepetake supaya keuntungan iki bisa tekan pangguna.