Open Responses - LLM के बीच संगतता के लिए एक ओपन स्पेसिफिकेशन

• कई LLM प्रदाताओं के बीच interoperability को लक्ष्य बनाने वाला एक open source स्पेसिफिकेशन और ecosystem, जो OpenAI Responses API पर आधारित common interface को परिभाषित करता है
• अनुरोध और response को shared schema में वर्णित किया जाता है, ताकि न्यूनतम conversion काम के साथ कई model providers पर एक ही तरीके से चलाया जा सके
• messages, tool calls, streaming, multimodal input जैसे common components को एक consistent structure में व्यवस्थित किया गया है, जिससे agent workflow लागू करना आसान होता है
• स्थिर core के ऊपर provider-specific extensions की अनुमति देने वाली संरचना, जो extensibility और fragmentation से बचाव दोनों को साथ लेकर चलती है
• OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI, vLLM आदि कई builders की भागीदारी वाले community के आधार पर संचालित

---

अवलोकन

• Open Responses, OpenAI Responses API पर आधारित एक open source स्पेसिफिकेशन और tools ecosystem है
• इसे इस तरह डिज़ाइन किया गया है कि language model calls, streaming result processing, और agent composition जैसे काम provider-independent तरीके से किए जा सकें
• common schema और tooling layer के ज़रिए एक single interface अनुभव प्रदान करता है

Open Responses क्यों

• LLM APIs में messages, tool calls, streaming, multimodal input जैसे समान components होते हैं, लेकिन वे अलग-अलग encoding methods का उपयोग करते हैं
• Open Responses इन्हें एकीकृत करने के लिए एक खुला common specification देता है, जिससे duplicate implementation का बोझ घटता है
• एक बार परिभाषित की गई request और output structure को कई providers पर दोबारा इस्तेमाल किया जा सकता है

डिज़ाइन सिद्धांत

• multi-provider first design के तहत एक single schema को विभिन्न model providers पर map किया जा सकता है
• streaming events, tool call patterns, और model output की न्यूनतम इकाई के रूप में items concept का उपयोग करके agent workflow-friendly structure प्रदान की जाती है
• जो features सामान्यीकृत नहीं किए जा सकते, उनके लिए provider-specific extensions की अनुमति है, लेकिन core stability बनाए रखना प्राथमिकता है

कम्युनिटी और ecosystem

• इसे multi-vendor environment को ध्यान में रखकर चलाए जाने वाले open community project के रूप में संचालित किया जाता है
• OpenRouter, Vercel, Hugging Face, LM Studio, Ollama, OpenAI, vLLM जैसी विभिन्न संस्थाओं की भागीदारी लोगो के रूप में दिखाई गई है
• portability, interoperability, और common foundation को महत्व देने वाली developer-centric community बन रही है

स्पेक की विशेषताएँ

• Items-केंद्रित common schema में message/tool call/reasoning state को एक ही इकाई में व्यक्त किया जाता है, और input तथा output दोनों item के रूप में आते-जाते हैं
• response और item को state machine के रूप में परिभाषित किया गया है, जिससे in_progress→completed/failed/incomplete जैसे lifecycle को स्पष्ट रूप से manage किया जा सके
• streaming को text fragments के बजाय semantic events के रूप में standardize किया गया है, जहाँ response.output_item.added से शुरू होकर delta→done पैटर्न में समापन होता है
• tools को external execution (developer/third-party) और internal execution (provider-hosted) में बाँटा गया है, और tool_choice/allowed_tools के माध्यम से callable scope को enforce करने वाला control plane दिया गया है
• previous_response_id के ज़रिए server पिछले input+output को context के रूप में फिर से बनाकर conversation continuation/retransmission minimization को support करता है, और truncation से “कटौती की अनुमति” बनाम “सीमा पार होने पर fail” चुना जा सकता है
• standard के बाहर के extensions को provider_slug: prefix से अलग किया जाता है, और custom hosted tool के लिए corresponding item type देना अनिवार्य है ताकि log/roundtrip करने योग्य “receipt” बची रहे
• errors structured error object के रूप में लौटाए जाते हैं, और streaming के दौरान error होने पर response.failed event के साथ समाप्ति होती है

[softer]

ओह... मैं भी कुछ implement कर रहा था, लगता है अब इसका ही framework बनाना पड़ेगा।