Apa Itu Open Responses?

Open Responses adalah spesifikasi terbuka, yang diterbitkan sebagai dokumen OpenAPI 3.1, yang menjelaskan satu bentuk permintaan dan respons untuk memanggil model bahasa di berbagai penyedia. Spesifikasi ini didasarkan pada OpenAI Responses API: Anda mengirim model, input dan opsional tools ke POST /v1/responses, dan Anda menerima kembali item bertipe dan event streaming semantik alih-alih format khusus penyedia. OpenAI meluncurkan Open Responses pada 2026-01-15, lisensinya Apache 2.0, dan pada 2026-10-22 OpenAI menyumbangkannya ke Agentic AI Foundation (AAIF), badan Linux Foundation yang juga menaungi MCP.

Langkah terakhir itulah beritanya: spesifikasi ini kini memiliki piagam teknis, komite pengarah, dan rumah netral. Artikel ini membahas apa yang didefinisikannya, siapa yang mengimplementasikannya, apa yang berubah dengan langkah AAIF, dan cara memeriksa apakah endpoint yang Anda andalkan sesuai. Jika Anda baru mengenal API yang mendasarinya, mulailah dengan cara menggunakan OpenAI Responses API.

Apa yang didefinisikan Open Responses

Spesifikasi ini menjelaskan masalahnya secara gamblang: para penyedia telah konvergen pada blok bangunan yang sama (pesan, pemanggilan tool, streaming, input multimodal) tetapi masing-masing mengodekannya secara berbeda. Open Responses memilih satu pengodean dan menuliskannya.

Dokumen OpenAPI saat ini adalah versi 2026-04-24 dan mencakup permukaan yang kecil:

Bodi permintaan menerima field yang Anda harapkan jika Anda pernah menggunakan API OpenAI: model, input, instructions, tools, tool_choice, stream, store, previous_response_id, reasoning, text, truncation, temperature, top_p, max_output_tokens, prompt_cache_key dan beberapa lagi. Objek respons (ResponseResource) membawa id, status, output, usage, error dan gema dari pengaturan yang Anda kirim. Dokumen tersebut mendefinisikan 108 skema secara total, sebagian besar adalah tipe item dan event streaming.

Tiga gagasan membawa desain ini.

Item adalah unit konteks

Segala sesuatu yang dibaca atau dihasilkan model adalah item: sebuah message, sebuah function_call, sebuah function_call_output, sebuah item reasoning. Item bersifat dua arah, sehingga keluaran dari satu giliran dapat langsung dikembalikan sebagai input untuk giliran berikutnya. Setiap tipe item dibedakan berdasarkan field type-nya dan memiliki skemanya sendiri.

Item juga merupakan mesin status: masing-masing bergerak dari in_progress ke completed atau incomplete (anggaran token habis), dan item incomplete harus menjadi item terakhir yang dikeluarkan, dengan keseluruhan respons ditandai tidak lengkap. Status tidak menyatakan apakah server menyimpan item tersebut; persistensi adalah urusan terpisah.

Streaming adalah event semantik, bukan delta mentah

Saat Anda menetapkan stream: true, server harus menjawab dengan Content-Type: text/event-stream dan urutan event yang telah ditentukan. Sebuah item keluaran dibuka dengan response.output_item.added; teks di dalamnya tiba sebagai response.content_part.added, lalu event response.output_text.delta berulang, lalu response.output_text.done dan response.content_part.done; item ditutup dengan response.output_item.done. Stream harus diakhiri dengan event terminal: response.completed, response.failed atau response.incomplete. [DONE] di akhir bersifat opsional, dan klien harus menangani stream yang berakhir tanpa itu.

Hal ini paling penting untuk kode klien: jika dua penyedia mengeluarkan event yang sama dalam urutan yang sama, satu parser SSE dapat digunakan untuk keduanya. Panduan pengujian SSE kami menunjukkan cara memeriksa stream ini event demi event.

Inti yang stabil dengan ekstensi ber-namespace

Penyedia dapat menambahkan tipe item, tool, dan event streaming mereka sendiri, tetapi mereka harus memberi awalan dengan slug penyedia. Contoh dari spesifikasi itu sendiri adalah openai:web_search_call. Klien yang tidak mengenali tipe berawalan dapat melewatinya tanpa rusak. Inilah cara spesifikasi ini tetap portabel sementara tool yang dihosting seperti web search atau file search tetap menjadi fitur penyedia.

Sisa kontrak

Beberapa aturan lagi perlu diketahui sebelum Anda membangun di atas spesifikasi ini:

• Dua jenis tool. Tool yang dihosting secara eksternal (fungsi, server MCP) berjalan di luar penyedia; untuk fungsi, model mengeluarkan function_call, Anda menjalankannya, dan Anda mengirim kembali function_call_output dengan call_id yang cocok. Tool yang dihosting secara internal (misalnya file search OpenAI) berjalan di dalam penyedia tanpa mengembalikan kendali.
• tool_choice dan allowed_tools. tool_choice menerima auto (default), required, none, atau objek yang menyebutkan satu fungsi. allowed_tools membatasi tool mana yang boleh dipanggil model sambil tetap menampilkan semuanya, sehingga Anda tidak membatalkan prompt yang di-cache dengan mengedit array tools. Server harus menegakkannya sebagai batas keras.
• previous_response_id. Server harus memperlakukan permintaan baru sebagai previous_response.input + previous_response.output + input, dalam urutan itu, sehingga Anda tidak perlu mengirim ulang transkrip.
• Item reasoning dapat membawa content mentah, blob encrypted_content yang buram, summary yang aman bagi pengguna, atau campuran apa pun.
• Error membawa type (server_error, invalid_request, not_found, model_error, too_many_requests), plus code, param dan message; di tengah stream, error diikuti oleh response.failed.

Revisi 2026-04-24 (changelog) menambahkan transport WebSocket: setiap giliran dimulai dengan pesan response.create, satu koneksi memproses satu respons pada satu waktu, koneksi dibatasi maksimal 60 menit (kode error websocket_connection_limit_reached), dan lanjutan store: false hidup di memori lokal koneksi, gagal dengan previous_response_not_found begitu status tersebut hilang. Revisi yang sama menambahkan /responses/compact, field phase opsional pada pesan asisten (commentary atau final_answer), dan menjadikan logprobs opsional.

Open Responses vs Chat Completions

Chat Completions masih menjadi antarmuka LLM yang paling banyak ditiru. Perbedaannya ada pada bentuk: Chat Completions mengembalikan choices yang berisi pesan, dengan pemanggilan tool terselip di dalamnya, sedangkan model Responses mengembalikan daftar datar item bertipe. Sebuah langkah reasoning, tiga pemanggilan tool dan pesan akhir menjadi objek terpisah dan berurutan dengan statusnya masing-masing, yang lebih cocok untuk loop agen.

Kami membandingkan tiga format dominan secara berdampingan, dengan permintaan nyata, dalam Chat Completions vs Anthropic Messages vs Responses API. Jika Anda memilih di antara permukaan milik OpenAI sendiri, uraian Agents API vs Responses API vs Agents SDK membahas posisi Responses.

Siapa yang mengimplementasikannya

Daftar pendukung mencakup AWS Bedrock, Databricks, Hugging Face, LM Studio, Nvidia, Ollama, OpenRouter, Red Hat, Vercel dan vLLM, bersama OpenAI. Anthropic dan Google tidak termasuk di antara pendukung yang disebutkan; keduanya masih mengirimkan format asli mereka sendiri.

“Mendukung” mencakup rentang yang luas, jadi periksa detailnya untuk runtime yang Anda gunakan:

• Ollama menambahkan POST /v1/responses di v0.13.3. Dokumentasi kompatibilitasnya menyatakan “hanya varian non-stateful yang didukung”: streaming, tool fungsi dan ringkasan reasoning berfungsi, tetapi previous_response_id, conversation dan truncation tidak. Anda mengirim ulang riwayat sendiri.
• LM Studio membuat endpoint http://localhost:1234/v1/responses-nya kompatibel pada versi 0.3.39, termasuk previous_response_id, URL gambar jarak jauh untuk model visi dan logprobs. Lihat panduan LM Studio kami untuk penyiapan.

Untuk gambaran skala, API Evangelist mengambil baseline pada 13 September: dari 120 penyedia yang mengklaim kompatibilitas OpenAI yang menerbitkan dokumen OpenAPI yang dapat dibaca, 26 mendeklarasikan POST /responses, dibandingkan 105 yang mendeklarasikan POST /chat/completions. Inti dari baseline ini adalah mengukur apakah tata kelola netral menggerakkan angka itu.

Apa yang berubah dengan langkah Agentic AI Foundation

AAIF mengumumkan Open Responses pada 2026-10-22 di AGNTCon + MCPCon North America di San Jose, bersama tiga proyek baru lainnya: Agent Skills (dari Anthropic), OpenEnv (dari Hugging Face) dan OpenSandbox (dari Alibaba). Ini menjadikan AAIF memiliki 10 proyek yang dinaungi pada tahun pertamanya, di samping MCP, protokol Agent2Agent, AGENTS.md, goose, agentgateway dan Agent Router. Jika Anda sedang memilah bagaimana semuanya saling terkait, penjelasan MCP vs A2A kami adalah awal yang baik.

Apa yang berubah:

• Tata kelola. Proyek ini sekarang menjadi “Open Responses a Series of LF Projects, LLC,” dengan piagam teknis yang diadopsi pada 2026-10-21. Sebuah Technical Steering Committee, yang awalnya adalah para maintainer proyek, memiliki keputusan teknis, dan partisipasi terbuka bagi siapa saja yang mengikuti piagam.
• Kredibilitas bagi vendor lain. Spesifikasi yang dimiliki satu perusahaan adalah sebuah produk. Spesifikasi di bawah yayasan lebih mudah diadopsi oleh pesaing tanpa terlihat mengikuti rival.

Apa yang tidak berubah:

• API milik OpenAI sendiri. Responses API di api.openai.com mempertahankan fitur dan jadwal rilisnya sendiri. Open Responses menjelaskan inti yang portabel; tool khusus OpenAI tetap berada di balik prefiks openai:.
• Format wire. Tidak ada versi spesifikasi baru yang menyertai langkah ini. Rilis terbaru masih 2026-04-24, dan rilis bertanggal bersifat immutable.
• Kesesuaian. Berada di daftar pendukung tidak berarti sebuah endpoint lulus pengujian. Belum ada yang menerbitkan indeks lulus/gagal, jadi Anda memeriksa sendiri endpoint yang Anda andalkan.

Periksa endpoint dengan acceptance test

Proyek ini menyertakan acceptance test-nya sendiri. Halaman kepatuhan menjalankan 10 pengujian di browser terhadap base URL, model, dan key apa pun: respons teks dasar, streaming, system prompt, pemanggilan tool, input gambar, riwayat multi-giliran, label phase asisten, endpoint pemadatan dan pengujian negatif untuk permintaan compact yang kehilangan model. Tujuh pengujian WebSocket lagi (giliran berurutan, lanjutan store: false, pemulihan sambung ulang, eviksi cache setelah lanjutan yang gagal) hanya berjalan dari CLI:

git clone https://github.com/openresponses/openresponses
cd openresponses && bun install
bun run test:compliance --base-url http://localhost:11434/v1 --api-key ollama

Setiap permintaan HTTP dan setiap giliran WebSocket mendapat batas waktu 30 detik, dan timeout hanya menggagalkan pengujian itu saja. Perkirakan runtime non-stateful seperti Ollama akan gagal dalam pengujian lanjutan secara by design.

Biarkan coding agent Anda mengujinya dengan Apidog CLI

Acceptance test memberi tahu Anda apakah server mengikuti spesifikasi hari ini. Mereka tidak mengawasi endpoint yang dipanggil aplikasi Anda setiap kali Anda men-deploy, meningkatkan Ollama, atau beralih penyedia. Untuk itu, impor spesifikasi ke proyek Apidog dan biarkan coding agent Anda menulis dan menjalankan pengujian regresi terhadapnya dengan Apidog CLI.

Instal CLI dan agent skill sekali saja:

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
npx -y skills add https://apidog.com   # pick your agent when prompted

Lalu beri Claude Code, Codex atau Cursor satu prompt:

Download https://www.openresponses.org/openapi/openapi.json and import it into
Apidog project <id>. Create an environment "local-ollama" with base URL
http://localhost:11434/v1. Add test cases for POST /responses: one that expects 200,
status "completed" and an output item of type "message"; one with stream: true that
expects text/event-stream ending in response.completed; one without "model" that
expects a 4xx error with an error.type field. Run them and summarize any failures.

Agent membaca skema, memvalidasi payload-nya sebelum menulis apa pun, dan menjalankan kasus-kasus tersebut:

curl -sLO https://www.openresponses.org/openapi/openapi.json
apidog import --project <id> --format openapi --file ./openapi.json
apidog environment create local-ollama --project <id> --base-url http://localhost:11434/v1
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog run --test-case <caseId> --project <id> -e <envId> -r cli,json

Entri servers pada spesifikasi menunjuk ke https://api.openai.com/v1, jadi tambahkan satu environment per penyedia dan jalankan kasus yang sama terhadap masing-masing: itulah klaim portabilitas yang teruji. Letakkan baris apidog run ... -r junit di pipeline Anda sehingga peningkatan runtime yang menghilangkan sebuah field menggagalkan build (panduan CI/CD); Apidog CLI di Claude Code membahas penyiapan agent secara terperinci.

FAQ

Apakah Open Responses sama dengan OpenAI Responses API? Tidak. Open Responses adalah spesifikasi yang diturunkan darinya. Responses API milik OpenAI adalah salah satu implementasi dengan fitur tambahan khusus OpenAI; Ollama, LM Studio dan vLLM adalah yang lain.

Siapa yang memiliki Open Responses sekarang? Sejak 2026-10-22 ini adalah proyek Agentic AI Foundation di bawah Linux Foundation, dijalankan sebagai rangkaian LF Projects dengan Technical Steering Committee. Lisensinya Apache 2.0.

Apakah Anthropic mendukung Open Responses? Anthropic tidak termasuk di antara pendukung yang disebutkan. Mereka menyumbangkan Agent Skills ke AAIF pada hari yang sama, tetapi antarmuka asli Claude masih Messages API.

Di mana file spesifikasinya? Di https://www.openresponses.org/openapi/openapi.json, dengan rilis bertanggal di repositori GitHub.

Langkah berikutnya

Pilih satu endpoint yang paling sering dipanggil produk Anda, jalankan acceptance test browser terhadapnya, dan impor spesifikasi ke Apidog agar agent Anda dapat terus menjalankan pemeriksaan tersebut pada setiap deploy. Unduh Apidog untuk memulai.