Open Responses Nedir?

Open Responses, sağlayıcılar arasında dil modellerini çağırmak için tek bir istek ve yanıt şeklini tanımlayan, OpenAPI 3.1 belgesi olarak yayımlanmış açık bir spesifikasyondur. OpenAI Responses API'sini temel alır: POST /v1/responses adresine model, input ve isteğe bağlı tools gönderirsiniz ve sağlayıcıya özgü bir format yerine tiplendirilmiş öğeler ile anlamsal akış olayları alırsınız. OpenAI, Open Responses'ı 2026-01-15 tarihinde başlattı, Apache 2.0 lisansı altında yayımladı ve 2026-10-22 tarihinde OpenAI bunu MCP'ye de ev sahipliği yapan Linux Foundation bünyesindeki Agentic AI Foundation'a (AAIF) bağışladı.

Asıl haber bu son adım: spesifikasyonun artık teknik bir tüzüğü, bir yönlendirme komitesi ve tarafsız bir yuvası var. Bu yazı neleri tanımladığını, kimlerin uyguladığını, AAIF hamlesinin neleri değiştirdiğini ve bağlı olduğunuz bir uç noktanın uyumlu olup olmadığını nasıl kontrol edeceğinizi ele alıyor. Temel API'de yeniyseniz, OpenAI Responses API nasıl kullanılır yazısıyla başlayın.

Open Responses neleri tanımlıyor

Spesifikasyon sorunu açıkça ortaya koyuyor: sağlayıcılar aynı yapı taşlarında (mesajlar, araç çağrıları, akış, çok modlu girdi) birleşmiş durumda, ancak her biri bunları farklı biçimde kodluyor. Open Responses tek bir kodlamayı seçip yazıya döküyor.

Mevcut OpenAPI belgesi 2026-04-24 sürümündedir ve küçük bir yüzeyi kapsar:

İstek gövdesi, OpenAI'nin API'sini kullandıysanız bekleyeceğiniz alanları kabul eder: model, input, instructions, tools, tool_choice, stream, store, previous_response_id, reasoning, text, truncation, temperature, top_p, max_output_tokens, prompt_cache_key ve birkaç tane daha. Yanıt nesnesi (ResponseResource) id, status, output, usage, error ve gönderdiğiniz ayarların bir yankısını taşır. Belge toplamda 108 şema tanımlar; çoğu öğe ve akış olayı tipleridir.

Tasarımı üç fikir taşıyor.

Öğeler bağlamın birimidir

Modelin okuduğu veya ürettiği her şey bir öğedir: bir message, bir function_call, bir function_call_output, bir reasoning öğesi. Öğeler çift yönlüdür; dolayısıyla bir turun çıktısı doğrudan bir sonrakinin girdisi olarak beslenebilir. Her öğe tipi type alanıyla ayırt edilir ve kendi şemasına sahiptir.

Öğeler aynı zamanda durum makineleridir: her biri in_progress durumundan completed veya incomplete durumuna geçer (token bütçesi tükendiğinde) ve bir incomplete öğe yayımlanan son öğe olmalı, tüm yanıt da incomplete olarak işaretlenmelidir. Bir durum, sunucunun öğeyi saklayıp saklamadığı hakkında hiçbir şey söylemez; kalıcılık ayrı bir konudur.

Akış ham deltalar değil, anlamsal olaylardır

stream: true ayarladığınızda, sunucu Content-Type: text/event-stream ile tanımlı bir olay dizisi yanıtlamalıdır. Bir çıktı öğesi response.output_item.added ile açılır; içindeki metin response.content_part.added, ardından tekrarlanan response.output_text.delta olayları, sonra response.output_text.done ve response.content_part.done olarak gelir; öğe response.output_item.done ile kapanır. Akış bir terminal olayla bitmelidir: response.completed, response.failed veya response.incomplete. Sonda bir [DONE] isteğe bağlıdır ve istemciler onsuz biten bir akışı da işleyebilmelidir.

Bu en çok istemci kodu için önemlidir: iki sağlayıcı aynı olayları aynı sırayla yayarsa, tek bir SSE ayrıştırıcısı ikisi için de çalışır. SSE test rehberimiz bu akışları olay olay nasıl inceleyeceğinizi gösterir.

Ad alanlı uzantıları olan kararlı bir çekirdek

Sağlayıcılar kendi öğe tiplerini, araçlarını ve akış olaylarını ekleyebilir, ancak bunların başına bir sağlayıcı kısa adı eklemeleri gerekir. Spesifikasyonun kendi örneği openai:web_search_call'dır. Ön ekli bir tipi tanımayan bir istemci, hiçbir şeyi bozmadan onu atlayabilir. Spesifikasyonun taşınabilir kalırken web araması veya dosya araması gibi barındırılan araçların sağlayıcı özelliği olarak kalmasının yolu budur.

Sözleşmenin geri kalanı

Spesifikasyon üzerine inşa etmeye başlamadan önce birkaç kural daha bilmeye değer:

• İki tür araç. Harici olarak barındırılan araçlar (fonksiyonlar, MCP sunucuları) sağlayıcının dışında çalışır; fonksiyonlar için model bir function_call yayar, siz onu çalıştırırsınız ve eşleşen call_id ile bir function_call_output geri gönderirsiniz. Dahili olarak barındırılan araçlar (örneğin OpenAI'nin dosya araması) kontrolü geri vermeden sağlayıcının içinde çalışır.
• tool_choice ve allowed_tools. tool_choice auto (varsayılan), required, none veya tek bir fonksiyonu adlandıran bir nesne alır. allowed_tools, modelin hangi araçları çağırabileceğini kısıtlarken hepsini göstermeye devam eder; böylece tools dizisini düzenleyerek önbelleğe alınmış bir prompt'u geçersiz kılmazsınız. Sunucular bunu katı bir sınır olarak uygulamalıdır.
• previous_response_id. Sunucu yeni isteği bu sırayla previous_response.input + previous_response.output + input olarak ele almalıdır; böylece konuşma dökümünü yeniden göndermezsiniz.
• Reasoning öğeleri ham content, opak bir encrypted_content blob'u, kullanıcıya uygun bir summary veya bunların herhangi bir karışımını taşıyabilir.
• Hatalar bir type (server_error, invalid_request, not_found, model_error, too_many_requests) ve ayrıca code, param ve message taşır; akış ortasında bir hatayı response.failed izler.

2026-04-24 revizyonu (değişiklik günlüğü) WebSocket taşımasını ekledi: her tur bir response.create mesajıyla başlar, bir bağlantı aynı anda bir yanıt işler, bağlantılar 60 dakikayla sınırlıdır (hata kodu websocket_connection_limit_reached) ve store: false devamları bağlantıya yerel bellekte yaşar, bu durum ortadan kalktığında previous_response_not_found ile başarısız olur. Aynı revizyon /responses/compact'ı, asistan mesajlarında isteğe bağlı bir phase alanını (commentary veya final_answer) ekledi ve logprobs'u isteğe bağlı hale getirdi.

Open Responses vs Chat Completions

Chat Completions hâlâ en yaygın kopyalanan LLM arayüzüdür. Fark şekildedir: Chat Completions bir mesaj tutan choices döndürürken, araç çağrıları da onun içine yerleştirilmiştir; Responses modeli ise tiplendirilmiş öğelerden oluşan düz bir liste döndürür. Bir reasoning adımı, üç araç çağrısı ve bir final mesajı, kendi durumlarına sahip ayrı, sıralı nesneler haline gelir; bu da ajan döngülerine daha uygundur.

Üç baskın formatı gerçek isteklerle yan yana Chat Completions vs Anthropic Messages vs Responses API yazısında karşılaştırdık. OpenAI'nin kendi yüzeyleri arasında seçim yapıyorsanız, Agents API vs Responses API vs Agents SDK dökümü Responses'ın nerede durduğunu ele alıyor.

Kimler uyguluyor

Destekçi listesinde OpenAI'nin yanı sıra AWS Bedrock, Databricks, Hugging Face, LM Studio, Nvidia, Ollama, OpenRouter, Red Hat, Vercel ve vLLM yer alıyor. Anthropic ve Google adlandırılmış destekçiler arasında değil; her ikisi de hâlâ kendi yerel formatlarını sunuyor.

"Destekliyor" geniş bir yelpazeyi kapsıyor, bu yüzden kullandığınız çalışma zamanının ayrıntılarını kontrol edin:

• Ollama, POST /v1/responses'ı v0.13.3'te ekledi. Uyumluluk belgeleri "yalnızca durumsuz (non-stateful) biçim desteklenir" diyor: akış, fonksiyon araçları ve reasoning özetleri çalışır, ancak previous_response_id, conversation ve truncation çalışmaz. Geçmişi kendiniz yeniden gönderirsiniz.
• LM Studio 0.3.39 sürümünde http://localhost:1234/v1/responses uç noktasını uyumlu hale getirdi; buna previous_response_id, görü modelleri için uzak görsel URL'leri ve logprobs dahil. Kurulum için LM Studio rehberimize bakın.

Ölçek hakkında bir fikir vermesi için, API Evangelist 13 Eylül'de bir temel ölçüm aldı: okunabilir bir OpenAPI belgesi yayımlayan ve OpenAI uyumluluğu iddia eden 120 sağlayıcıdan 26'sı POST /responses bildirirken, 105'i POST /chat/completions bildiriyor. Temel ölçümün amacı, tarafsız yönetişimin bu sayıyı hareket ettirip ettirmediğini ölçmektir.

Agentic AI Foundation hamlesi neleri değiştiriyor

AAIF, 2026-10-22 tarihinde San Jose'deki AGNTCon + MCPCon North America'da Open Responses'ı duyurdu; birlikte diğer üç yeni projeyle: Agent Skills (Anthropic'ten), OpenEnv (Hugging Face'ten) ve OpenSandbox (Alibaba'dan). Bu, AAIF'yi ilk yılında MCP, Agent2Agent protokolü, AGENTS.md, goose, agentgateway ve Agent Router'ın yanında 10 barındırılan projeye ulaştırıyor. Bunların birbirine nasıl uyduğunu çözümlüyorsanız, MCP vs A2A açıklamamız iyi bir başlangıçtır.

Değişenler:

• Yönetişim. Proje artık 2026-10-21'de kabul edilen bir teknik tüzükle "Open Responses a Series of LF Projects, LLC" oldu. Başlangıçta projenin sürdürücülerinden oluşan bir Teknik Yönlendirme Komitesi teknik kararların sahibidir ve katılım tüzüğe uyan herkese açıktır.
• Diğer satıcılar için inandırıcılık. Bir şirkete ait spesifikasyon bir üründür. Bir vakıf altındaki spesifikasyonu bir rakibin, bir rakibi takip ediyor görünmeden benimsemesi daha kolaydır.

Değişmeyenler:

• OpenAI'nin kendi API'si. api.openai.com üzerindeki Responses API kendi özelliklerini ve sürüm takvimini korur. Open Responses taşınabilir çekirdeği tanımlar; OpenAI'ye özel araçlar openai: ön ekinin arkasında kalır.
• Tel formatı. Hamleyle birlikte yeni bir spesifikasyon sürümü gelmedi. En son sürüm hâlâ 2026-04-24 ve tarihli sürümler değiştirilemez.
• Uygunluk. Destekçi listesinde olmak, bir uç noktanın testleri geçtiği anlamına gelmez. Henüz kimse geçti/kaldı endeksi yayımlamıyor, bu yüzden bağlı olduğunuz uç noktaları kendiniz kontrol edersiniz.

Bir uç noktayı kabul testleriyle kontrol edin

Proje kendi kabul testlerini sunuyor. Uyumluluk sayfası tarayıcıda herhangi bir temel URL, model ve anahtara karşı 10 test çalıştırır: temel metin yanıtı, akış, sistem prompt'u, araç çağırma, görsel girdi, çok turlu geçmiş, asistan phase etiketleri, sıkıştırma uç noktası ve model eksik bir compact isteği için bir negatif test. Yedi WebSocket testi daha (sıralı turlar, store: false devamı, yeniden bağlanma kurtarma, başarısız bir devamdan sonra önbellek tahliyesi) yalnızca CLI'dan çalışır:

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

Her HTTP isteği ve her WebSocket turu 30 saniyelik bir süre sınırı alır ve zaman aşımı yalnızca o testi başarısız kılar. Ollama gibi durumsuz bir çalışma zamanının devam testlerinde tasarım gereği başarısız olmasını bekleyin.

Kodlama ajanınızın bunu Apidog CLI ile test etmesini sağlayın

Kabul testleri bir sunucunun bugün spesifikasyona uyup uymadığını söyler. Ancak uygulamanızın çağırdığı uç noktayı her dağıtımda, Ollama'yı yükselttiğinizde veya bir sağlayıcıyı değiştirdiğinizde izlemezler. Bunun için spesifikasyonu bir Apidog projesine aktarın ve kodlama ajanınızın Apidog CLI ile ona karşı regresyon testleri yazıp çalıştırmasını sağlayın.

CLI'yı ve ajan becerisini bir kez kurun:

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

Ardından Claude Code, Codex veya Cursor'a tek bir prompt verin:

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.

Ajan şemaları okur, herhangi bir şey yazmadan önce payload'larını doğrular ve test durumlarını çalıştırır:

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

Spesifikasyonun servers girdisi https://api.openai.com/v1 adresini işaret eder, dolayısıyla her sağlayıcı için bir ortam ekleyin ve aynı test durumlarını her birine karşı çalıştırın: taşınabilirlik iddiasının test edilmiş hali budur. apidog run ... -r junit satırını pipeline'ınıza koyun ki bir alanı düşüren bir çalışma zamanı yükseltmesi derlemeyi başarısız kılsın (CI/CD rehberi); Claude Code'da Apidog CLI ajan kurulumunu ayrıntılı olarak ele alıyor.

SSS

Open Responses, OpenAI Responses API ile aynı şey mi? Hayır. Open Responses ondan türetilmiş bir spesifikasyondur. OpenAI'nin Responses API'si, ekstra yalnızca-OpenAI özelliklerine sahip bir uygulamadır; Ollama, LM Studio ve vLLM ise diğerleridir.

Open Responses'ın sahibi artık kim? 2026-10-22'den beri Linux Foundation altında bir Agentic AI Foundation projesidir; bir Teknik Yönlendirme Komitesi ile LF Projects serisi olarak yürütülür. Apache 2.0 lisansı altındadır.

Anthropic Open Responses'ı destekliyor mu? Anthropic adlandırılmış destekçiler arasında değil. Aynı gün AAIF'ye Agent Skills katkısında bulundu, ancak Claude'un yerel arayüzü hâlâ Messages API'sidir.

Spesifikasyon dosyası nerede? https://www.openresponses.org/openapi/openapi.json adresinde, tarihli sürümler ise GitHub deposunda.

Sonraki adım

Ürününüzün en çok çağırdığı tek uç noktayı seçin, ona karşı tarayıcı kabul testlerini çalıştırın ve spesifikasyonu Apidog'a aktarın ki ajanınız bu kontrolleri her dağıtımda çalıştırmaya devam etsin. Başlamak için Apidog'u indirin.