Mempercepat alur kerja agentik dengan WebSockets di API Respons

Saat Anda meminta Codex untuk memperbaiki bug, Codex memindai basis kode Anda untuk mencari file yang relevan, membacanya untuk membangun konteks, melakukan pengeditan, dan menjalankan pengujian untuk memverifikasi bahwa perbaikannya berhasil. Artinya, ada lusinan permintaan API Respons bolak-balik di balik layar: hal ini menentukan tindakan model berikutnya, menjalankan alat di komputer Anda, mengirim kembali output alat ke API, lalu mengulanginya.

Semua permintaan ini dapat menambah waktu tunggu hingga beberapa menit , di mana pengguna menghabiskan waktu untuk menunggu Codex menyelesaikan tugas yang rumit. Dari perspektif latensi, loop agen Codex menghabiskan sebagian besar waktunya dalam tiga tahap utama: bekerja di layanan API (untuk memvalidasi dan memproses permintaan), inferensi model, dan waktu di sisi klien (menjalankan alat dan membangun konteks model). Inferensi adalah tahap ketika model dijalankan di GPU untuk menghasilkan token baru. Di masa lalu, menjalankan inferensi LLM pada GPU merupakan bagian yang paling lambat dari loop agen, sehingga overhead layanan API mudah disamarkan. Seiring inferensi menjadi semakin cepat, overhead API kumulatif dari rollout berbasis agen menjadi jauh lebih terasa.

Dalam postingan ini, kami akan menjelaskan bagaimana kami membuat loop agen menggunakan API menjadi 40% lebih cepat secara menyeluruh, sehingga pengguna dapat merasakan lonjakan kecepatan inferensi dari 65 menjadi hampir 1.000 token per detik. Kami melakukan pendekatan ini melalui caching, menghilangkan hop jaringan yang tidak perlu, meningkatkan lapisan keamanan kami agar dapat dengan cepat menandai masalah, dan—yang terpenting—membangun cara untuk membuat koneksi persisten ke API Respons, alih-alih harus melakukan serangkaian panggilan API sinkron.

Di Responses API, model unggulan sebelumnya seperti GPT‑5 dan GPT‑5.2 berjalan pada sekitar 65 token per detik (TPS). Untuk peluncuran GPT‑5.3‑Codex‑Spark, model pengodean yang cepat, tujuan kami adalah menjadi sepuluh kali lebih cepat: lebih dari 1.000 TPS, yang dimungkinkan oleh perangkat keras Cerebras khusus yang dioptimalkan untuk inferensi LLM. Untuk memastikan pengguna dapat merasakan kecepatan sesungguhnya dari model baru ini, kami harus mengurangi overhead API. 

Sekitar November 2025, kami memulai sprint performa pada Responses API, menghadirkan banyak pengoptimalan pada latensi jalur kritis untuk satu permintaan: 

• Menyimpan token yang dirender dan konfigurasi model dalam cache di memori untuk melewati tokenisasi dan panggilan jaringan yang mahal untuk respons multi-turn
• Mengurangi latensi hop jaringan dengan menghilangkan panggilan ke layanan perantara (misalnya, resolusi pemrosesan gambar) dan langsung memanggil layanan inferensi itu sendiri
• Meningkatkan lapisan pengamanan kami agar kami dapat menjalankan pengklasifikasi tertentu untuk menandai percakapan dengan lebih cepat

Dengan peningkatan ini, kami melihat peningkatan hampir 45% dalam waktu hingga token pertama (TTFT)—yang mencerminkan seberapa responsif API terasa—tetapi peningkatan ini masih belum cukup cepat untuk GPT‑5.3‑Codex‑Spark. Bahkan dengan peningkatan ini, overhead API Respons masih terlalu besar dibandingkan dengan kecepatan model—artinya, pengguna harus menunggu CPU yang menjalankan API kami sebelum mereka dapat menggunakan GPU yang melayani model.

Masalah yang lebih mendasar bersifat struktural: kami memperlakukan setiap permintaan Codex sebagai sesuatu yang independen, memproses status percakapan dan konteks lain yang dapat digunakan kembali dalam setiap permintaan tindak lanjut. Bahkan ketika sebagian besar percakapan tidak banyak berubah, kami tetap harus membayar untuk pekerjaan yang terkait dengan riwayat lengkap. Seiring percakapan menjadi lebih panjang, pemrosesan berulang tersebut menjadi lebih mahal.

Untuk merapikan desain, kami memikirkan ulang protokol transport: bisakah kami mempertahankan koneksi persisten dan menyimpan state dalam cache, alih-alih membuat koneksi baru melalui HTTP dan mengirim seluruh riwayat percakapan untuk setiap permintaan tindak lanjut? Idenya adalah hanya untuk mengirim informasi baru yang memerlukan validasi dan pemrosesan, serta menyimpan status yang dapat digunakan kembali di memori selama masa aktif koneksi. Ini akan mengurangi beban tambahan akibat pekerjaan yang berulang.

Kami mempertimbangkan beberapa pendekatan yang berbeda, termasuk WebSockets dan gRPC bidirectional streaming. Kami memilih WebSockets karena sebagai protokol transport pesan yang sederhana, pengguna tidak perlu mengubah struktur input dan output API Respons mereka. Solusi ini ramah bagi developer dan sesuai dengan arsitektur yang sudah ada dengan gangguan yang minimal.

Prototipe WebSocket pertama mengubah apa yang kami kira memungkinkan untuk latensi API Respons. Seorang insinyur di tim Codex dengan keahlian mendalam di seluruh stack API menyusun sebuah prototipe dengan menjalankan agen Codex semalaman.

Dalam prototipe tersebut, agentic rollouts dimodelkan sebagai satu Response yang berjalan terus-menerus. Dengan menggunakan fitur asyncio, API Respons akan memblokir secara asinkron dalam loop sampling setelah panggilan alat di-sampling, dan API Respons mengirimkan event response.done kembali ke klien. Setelah mengeksekusi pemanggilan alat, klien akan mengirim kembali event response.append beserta hasil alat, yang membuka blokir loop sampling dan memungkinkan model melanjutkan.

Analoginya seperti memperlakukan pemanggilan alat lokal sebagai pemanggilan alat yang di-host. Saat model memanggil pencarian web, loop inferensi terhenti, memanggil layanan pencarian web, dan menempatkan respons layanan ke dalam konteks model. Dalam desain kami, kami melakukan hal yang sama; tetapi alih-alih memanggil layanan jarak jauh, kami mengirimkan pemanggilan alat model kembali ke klien melalui WebSocket. Saat klien merespons, kami memasukkan respons pemanggilan alat klien ke dalam konteks dan melanjutkan sampling.

Desain ini sangat efektif karena menghilangkan pekerjaan API yang berulang selama peluncuran agen. Kami dapat melakukan pekerjaan pra-inferensi sekali, memberi jeda untuk eksekusi alat, dan melakukan pekerjaan pasca-inferensi satu kali di akhir.

Sayangnya, hal ini harus dibayar dengan bentuk API yang kurang familiar dan lebih rumit. Kami ingin para pengembang dapat menambahkan dukungan WebSocket tanpa harus menulis ulang integrasi API mereka agar sesuai dengan mode interaksi baru.

Untuk versi yang kami luncurkan, kami kembali ke bentuk yang sudah familiar: tetap gunakan response.create dengan body yang sama, dan gunakan previous_response_id untuk melanjutkan konteks percakapan dari status respons sebelumnya.

Pada koneksi WebSocket, server menyimpan cache dalam memori yang dicakup oleh koneksi untuk status respons sebelumnya. Saat response.create lanjutan menyertakan previous_response_id, kami mengambil status tersebut dari cache alih-alih membangun ulang seluruh percakapan dari awal.

Status yang di-cache mencakup:

• Objek response sebelumnya
• Item masukan dan keluaran sebelumnya
• Definisi alat dan namespace
• Artefak sampling yang dapat digunakan kembali, seperti token yang sebelumnya dirender

Dengan menggunakan kembali status respons sebelumnya yang tersimpan di memori, kami dapat menerapkan beberapa pengoptimalan besar:

• Membuat beberapa pengklasifikasi keselamatan dan validator permintaan kami hanya memproses masukan baru, bukan seluruh riwayat setiap kali
• Menyimpan cache dalam memori untuk token yang telah dirender, yang terus kami tambahi agar kami dapat melewati tokenisasi yang tidak perlu
• Menggunakan kembali logika penyelesaian/pengaturan rute model kami yang berhasil di seluruh permintaan 
• Menumpangtindihkan pekerjaan pascainferensi non-pemblokiran seperti penagihan dengan permintaan berikutnya

Tujuannya adalah untuk mendekati prototipe dengan overhead minimal, tetapi dengan bentuk API yang sudah dipahami oleh pengembang dan menjadi dasar pengembangan mereka.

Setelah sprint selama dua bulan membangun mode WebSocket, kami meluncurkan versi alfa bersama startup agen koding utama agar mereka dapat mengintegrasikannya ke dalam infrastruktur mereka dan meningkatkan lalu lintas secara aman. Pengguna alfa menyukainya, melaporkan peningkatan hingga 40%⁠(terbuka di jendela baru) dalam alur kerja agentik mereka. Berdasarkan umpan balik positif dari versi alfa, kami siap meluncurkannya.

Hasil peluncurannya langsung terlihat. Codex dengan cepat mengalihkan sebagian besar traffic API Respons mereka ke mode WebSocket, dan mengalami peningkatan latensi yang signifikan. Untuk GPT‑5.3‑Codex‑Spark, kami mencapai target 1.000 TPS dan mencatat lonjakan hingga 4.000 TPS, yang menunjukkan bahwa Responses API mampu mengimbangi inferensi yang jauh lebih cepat dalam lalu lintas produksi nyata. Dampaknya juga muncul dengan cepat di komunitas developer:

• Codex dengan cepat mengalihkan sebagian besar lalu lintas mereka ke WebSockets. Pengguna Codex yang menjalankan model terbaru seperti GPT‑5.3‑Codex⁠(terbuka di jendela baru), GPT‑5.4⁠(terbuka di jendela baru), dan semuanya diuntungkan oleh peningkatan kecepatan dari mode WebSocket.
• Vercel mengintegrasikan mode WebSocket ke dalam AI SDK dan melihat latensi menurun hingga 40%⁠(terbuka di jendela baru).
• Alur kerja multi-file Cline 39% lebih cepat⁠(terbuka di jendela baru).
• Model OpenAI di Cursor menjadi hingga 30% lebih cepat⁠(terbuka di jendela baru).

Mode WebSocket adalah salah satu kemampuan baru yang paling signifikan di API Respons sejak peluncurannya pada bulan Maret 2025. Dari ide hingga produksi, kami capai hanya dalam beberapa minggu berkat kolaborasi erat antara tim API dan Codex di OpenAI. Hal ini tidak hanya secara dramatis meningkatkan latensi peluncuran agen, tetapi juga mendukung kebutuhan yang terus berkembang bagi para pengembang: seiring inferensi model menjadi lebih cepat, layanan dan sistem yang mengelilingi inferensi juga perlu dipercepat untuk meneruskan peningkatan ini kepada pengguna.