Mempercepatkan aliran kerja ejen dengan WebSockets dalam Responses API

Apabila anda meminta Codex membaiki pepijat, ia akan mengimbas pangkalan kod anda untuk fail berkaitan, membacanya bagi membina konteks, membuat suntingan, dan menjalankan ujian untuk mengesahkan pembaikan berjaya. Di sebalik tabir, ini bermaksud berpuluh-puluh permintaan API Responses yang berulang-alik: menentukan tindakan seterusnya model, menjalankan alat pada komputer anda, menghantar output alat kembali kepada API, dan mengulanginya.

Semua permintaan ini boleh terkumpul menjadi beberapa minit yang pengguna habiskan untuk menunggu Codex menyelesaikan tugas kompleks. Dari perspektif kependaman, gelung ejen Codex menghabiskan sebahagian besar masanya dalam tiga peringkat utama: bekerja dalam perkhidmatan API (untuk mengesahkan dan memproses permintaan), inferens model, dan masa di bahagian klien (menjalankan alat dan membina konteks model). Inferens ialah peringkat di mana model berjalan pada GPU untuk menjana token baharu. Pada masa lalu, menjalankan inferens LLM pada GPU adalah bahagian paling perlahan dalam gelung ejen, jadi overhed perkhidmatan API mudah disembunyikan. Apabila inferens menjadi lebih pantas, overhed API kumulatif daripada pelancaran ejen menjadi jauh lebih ketara.

Dalam siaran ini, kami akan menerangkan bagaimana kami menjadikan gelung ejen menggunakan API 40% lebih pantas dari awal hingga akhir, membolehkan pengguna mengalami lonjakan dalam kelajuan inferens daripada 65 kepada hampir 1,000 token sesaat. Kami mendekati perkara ini melalui caching, menghapuskan network hop yang tidak perlu, menambah baik sistem keselamatan kami untuk menandakan isu dengan cepat, dan—yang paling penting—membina cara untuk mewujudkan sambungan berterusan kepada Responses API, dan bukannya perlu membuat satu siri panggilan API segerak.

Dalam Responses API, model-model terunggul terdahulu seperti GPT‑5 dan GPT‑5.2 beroperasi pada kira-kira 65 token sesaat (TPS). Bagi pelancaran GPT‑5.3‑Codex‑Spark, model pengekodan yang pantas, matlamat kami adalah untuk menjadi sepuluh kali ganda lebih pantas: melebihi 1,000 TPS, dimungkinkan oleh perkakasan Cerebras khusus yang dioptimumkan untuk inferens LLM. Untuk memastikan pengguna dapat merasai kelajuan sebenar model baharu ini, kami perlu mengurangkan overhed API. 

Sekitar 11/2025, kami melancarkan inisiatif peningkatan prestasi pada Responses API, dengan melaksanakan banyak pengoptimuman pada latensi laluan kritikal bagi satu permintaan: 

• Menyimpan token yang telah dirender dan konfigurasi model dalam memori untuk mengelakkan pentokenan dan panggilan rangkaian yang mahal bagi respons berbilang giliran
• Mengurangkan kependaman hop rangkaian dengan menghapuskan panggilan kepada perkhidmatan pertengahan (contohnya, resolusi pemprosesan imej) dan terus memanggil perkhidmatan inferens itu sendiri
• Menambah baik tumpuan keselamatan kami supaya kami dapat menjalankan pengelas tertentu untuk menandai perbualan dengan lebih pantas

Dengan penambahbaikan ini, kami melihat peningkatan hampir 45% dalam masa ke token pertama (TTFT)—yang mencerminkan sejauh mana responsifnya API itu—namun penambahbaikan ini masih belum cukup pantas untuk GPT‑5.3‑Codex‑Spark. Walaupun dengan penambahbaikan ini, overhed Responses API masih terlalu besar berbanding kelajuan model—iaitu, pengguna terpaksa menunggu CPU yang menjalankan API kami sebelum mereka dapat menggunakan GPU yang menyajikan model.

Isu yang lebih mendalam adalah bersifat struktur: kami menganggap setiap permintaan Codex sebagai bebas, memproses keadaan perbualan dan konteks lain yang boleh digunakan semula dalam setiap permintaan susulan. Walaupun kebanyakan perbualan tidak berubah, kami masih perlu membayar untuk kerja yang terikat dengan sejarah sembang lengkap. Apabila perbualan menjadi lebih panjang, pemprosesan berulang itu menjadi lebih mahal.

Untuk memperkemaskan reka bentuk, kami memikirkan semula protokol pengangkutan: bolehkah kami mengekalkan sambungan berterusan dan menyimpan cache keadaan, dan bukannya mewujudkan sambungan baharu melalui HTTP serta menghantar sejarah perbualan penuh bagi setiap permintaan susulan? Ideanya adalah untuk hanya menghantar sebarang maklumat baharu yang memerlukan pengesahan dan pemprosesan serta menyimpan keadaan yang boleh digunakan semula dalam cache memori sepanjang tempoh sambungan itu. Ini akan mengurangkan overhed daripada kerja yang berlebihan.

Kami mempertimbangkan beberapa pendekatan yang berbeza, termasuk WebSockets dan penstriman dua hala gRPC. Kami memilih WebSockets kerana ia adalah protokol pengangkutan mesej yang ringkas, pengguna tidak perlu mengubah bentuk input dan output Responses API mereka. Ia mesra pembangun dan sesuai dengan seni bina sedia ada kami dengan sedikit gangguan.

Prototaip WebSocket yang pertama mengubah apa yang kami fikir mungkin bagi latensi Responses API. Seorang jurutera dalam pasukan Codex yang mempunyai kepakaran mendalam merentasi timbunan API telah menghasilkan sebuah prototaip dengan menjalankan ejen Codex semalaman.

Dalam prototaip itu, pelaksanaan agentik dimodelkan sebagai satu respons tunggal yang berjalan lama. Dengan menggunakan ciri asyncio, API respons akan menyekat secara tak segerak dalam gelung pensampelan, selepas panggilan alat telah disampel, dan API respons akan menghantar peristiwa response.done kembali kepada klien. Selepas melaksanakan panggilan alat, klien akan menghantar semula peristiwa response.append dengan hasil alat, yang menyahsekat gelung pensampelan dan membolehkan model meneruskan.

Analogi di sini adalah menganggap panggilan alat setempat sebagai panggilan alat yang dihoskan. Apabila model memanggil carian web, gelung inferens disekat, memanggil perkhidmatan carian web, dan memasukkan respons perkhidmatan ke dalam konteks model. Dalam reka bentuk kami, kami melakukan perkara yang sama; tetapi bukannya memanggil perkhidmatan jauh, kami menghantar panggilan alat model kembali kepada klien melalui WebSocket. Apabila klien memberikan respons, kami memasukkan respons panggilan alat klien ke dalam konteks dan meneruskan pensampelan.

Reka bentuk ini amat berkesan kerana ia menghapuskan kerja API yang berulang sepanjang pelancaran ejen. Kita boleh melakukan kerja pra-inferens sekali, berhenti seketika untuk pelaksanaan alat, dan melakukan kerja pasca-inferens sekali pada penghujungnya.

Malangnya, hal ini mengorbankan bentuk API yang kurang dikenali dan lebih kompleks. Kami mahu pembangun dapat menambahkan sokongan WebSocket tanpa perlu menulis semula integrasi API mereka berdasarkan mod interaksi baharu.

Untuk versi yang kami lancarkan, kami kembali kepada bentuk yang biasa: terus gunakan response.create dengan badan yang sama, dan gunakan previous_response_id untuk meneruskan konteks perbualan daripada keadaan respons sebelumnya.

Pada sambungan WebSocket, pelayan mengekalkan cache dalam memori pada skop sambungan bagi keadaan respons sebelumnya. Apabila response.create susulan merangkumi previous_response_id, kami mendapatkan keadaan tersebut daripada cache dan bukannya membina semula keseluruhan perbualan dari awal.

Keadaan yang di-cache itu merangkumi:

• Objek response sebelumnya
• Item input dan output terdahulu
• Definisi alat dan ruang nama
• Artifak pensampelan yang boleh digunakan semula, seperti token yang dijanakan sebelum ini

Dengan menggunakan semula keadaan respons terdahulu yang disimpan dalam memori, kami dapat melaksanakan beberapa pengoptimuman utama:

• Menjadikan sesetengah pengelas keselamatan dan pengesah permintaan kami memproses hanya input baharu, bukan keseluruhan sejarah setiap kali
• Menyimpan cache dalam memori bagi token yang telah dirender yang kami tambahkan supaya kami dapat melangkau pentokenan yang tidak diperlukan
• Menggunakan semula logik penyelesaian/penghalaan model kami yang berjaya merentasi permintaan 
• Menindankan kerja pasca-inferens yang tidak menyekat seperti pengebilan dengan permintaan berikutnya

Matlamatnya adalah untuk mendekati sehabis mungkin dengan prototaip overhed minimum, tetapi dengan bentuk API yang sudah difahami oleh pembangun dan telah mereka bina di sekelilingnya.

Selepas tempoh pecutan selama dua bulan membina mod WebSocket, kami melancarkan versi alfa bersama syarikat pemula ejen pengekodan utama supaya mereka dapat mengintegrasikannya ke dalam infrastruktur mereka dan meningkatkan trafik secara selamat. Pengguna alfa amat menyukainya dengan melaporkan peningkatan sehingga 40%⁠(dibuka dalam tetingkap baru) dalam aliran kerja agentik mereka. Memandangkan maklum balas positif daripada versi alfa, kami sudah bersedia untuk melancarkan.

Hasil pelancaran itu adalah serta-merta. Codex dengan cepat mengalihkan sebahagian besar trafik Responses API kepada mod WebSocket, dan menyaksikan peningkatan kependaman yang ketara. Bagi GPT‑5.3‑Codex‑Spark, kami mencapai sasaran 1,000 TPS kami dan melihat lonjakan sehingga 4,000 TPS, menunjukkan bahawa Responses API mampu mengikuti inferens yang jauh lebih pantas dalam trafik pengeluaran sebenar. Kesan itu turut kelihatan dengan cepat dalam komuniti pembangun:

• Codex dengan cepat mengalihkan sebahagian besar trafik mereka kepada WebSockets. Pengguna Codex yang menjalankan model terkini seperti GPT‑5.3‑Codex⁠(dibuka dalam tetingkap baru), GPT‑5.4⁠(dibuka dalam tetingkap baru), dan seterusnya mendapat manfaat daripada peningkatan kelajuan mod WebSocket.
• Vercel menyepadukan mod WebSocket ke dalam AI SDK dan menyaksikan kependaman berkurang sehingga 40%⁠(dibuka dalam tetingkap baru).
• Aliran kerja berbilang fail Cline adalah 39% lebih pantas⁠(dibuka dalam tetingkap baru).
• Model OpenAI dalam Cursor kini sehingga 30% lebih pantas⁠(dibuka dalam tetingkap baru).

Mod WebSocket ialah salah satu keupayaan baharu yang paling penting dalam Responses API sejak pelancarannya pada Mac 2025. Kami beralih daripada idea kepada pelaksanaan dalam persekitaran produksi dalam hanya beberapa minggu melalui kerjasama rapat antara pasukan API OpenAI dan Codex. Ia bukan sahaja meningkatkan kependaman pelancaran ejen secara dramatik, tetapi juga menyokong keperluan yang semakin meningkat bagi pembangun: apabila inferens model menjadi lebih pantas, perkhidmatan dan sistem yang mengelilingi inferens juga perlu dipercepatkan untuk menyalurkan manfaat ini kepada pengguna.