OpenRouter का Armor बीटा मॉडल के प्रस्तावित टूल कॉल और उसे चलाने वाले ऐप्लिकेशन के बीच नियमों का एक क्लासिफ़ायर रखता है। एजेंट डेवलपर के लिए निर्णायक बात यह है कि फ़ैसला वास्तव में किस बिंदु पर निष्पादन रोकता है। Chat Completions और Responses में Armor चिह्नित कॉल को आगे जाने से रोक सकता है। Messages API के Claude Code संगतता मोड में चिह्नित tool_use जवाब में बना रहता है और क्लाइंट को उसे चलाने से इनकार करना होता है।
मौजूदा दस्तावेज़ अक्टूबर 2026 से उपलब्ध बीटा का वर्णन करते हैं। BIG CHANGE ने 17 अक्टूबर को दस्तावेज़ों में दिए गए अनुरोध और जवाब के अनुबंधों की समीक्षा की। हमने API अनुरोध नहीं भेजा, एजेंट नहीं चलाया और उसकी सुरक्षा का प्रदर्शन नहीं मापा।
बड़ा बदलाव
- क्या बदला: OpenRouter एजेंट अपने प्रस्तावित टूल कॉल ऐसे क्लासिफ़ायर से भेज सकता है जो कॉल के ऐप्लिकेशन तक पहुँचने से पहले डेवलपर के लिखे नियम लागू करता है। डिफ़ॉल्ट प्रवर्तन मार्ग में चिह्नित कॉल का निष्पादन छोड़ दिया जाता है और कारण लौटाया जाता है, ताकि मॉडल आगे बढ़ सके।
- यह क्यों मायने रखता है: डेवलपर कार्रवाइयों के स्तर पर सीमाएँ सामान्य भाषा में लिख सकते हैं, जिनमें संकीर्ण दायरे में अनुमति मिले काम के अपवाद भी शामिल हों। Messages संगतता अनुबंध फिर भी निष्पादन का निर्णायक कदम क्लाइंट पर छोड़ता है: चिह्नित फ़ैसले को अनदेखा करने वाला क्लाइंट उस कॉल को फिर भी चला सकता है।
- किस पर नज़र रखें: टीमों को चुने गए API आउटपुट मोड के मुताबिक क्लाइंट बनाना, अपने ट्रैफ़िक पर नियम परखना और क्लासिफ़ायर की त्रुटियों पर व्यवहार तय करना होगा। बीटा के फ़ॉर्मैट बदल सकते हैं। OpenRouter के मुताबिक क्लासिफ़ायर स्वीकार्य कॉल को रोक भी सकता है और अस्वीकार्य कॉल को चूक भी सकता है।
प्रस्ताव से फ़ैसले तक कॉल का रास्ता समझें
OpenRouter कहता है कि हर प्रस्तावित टूल कॉल को ऐप्लिकेशन तक भेजने से पहले रोककर रखा जाता है। उसका निर्णय मॉडल कॉल, नियम और अब तक की बातचीत लेता है, हर नियम के मेल का अनुमान लगाता है और नतीजों को जोड़कर flagged या not_flagged देता है। जिस कॉल को चिह्नित नहीं किया गया हो, उसे जस का तस आगे जाने दिया जाता है। प्रवर्तन मोड में चिह्नित कॉल का निष्पादन छोड़ने का निर्देश होता है; मॉडल कारण पाता है और कम दायरे वाला कॉल आज़मा सकता है या मना करने की वजह समझा सकता है। यह प्रस्तावित कार्रवाई पर क्लासिफ़ायर का निर्णय है, बाद का टूल या पूरा एजेंट सुरक्षित होने का प्रमाण नहीं।
नियमों के स्तर अलग सवालों के जवाब देते हैं। hard_deny का मेल अनुमति वाले नियम या उपयोगकर्ता के अनुरोध की परवाह किए बिना रोकता है। soft_deny का मेल allow के मेल से हट सकता है, या बातचीत में उपयोगकर्ता के उसी लक्ष्य पर ठीक उसी कार्रवाई का अनुरोध करने से। allow नियम अकेले कभी कॉल नहीं रोकता। OpenRouter उपयोगकर्ता की तय की हुई और वापस न ली गई सीमा के लिए एक अंतर्निहित सॉफ़्ट-डिनाय भी बताता है। डेवलपर भरोसेमंद रिपॉज़िटरी या डिप्लॉय लक्ष्य जैसे तथ्य environment में देते हैं; पुराने तथ्य नियम की सटीकता घटा सकते हैं। नाम वाले नियम ऑब्जेक्ट फ़ैसलों में ID और नाम दिखाते हैं। वैकल्पिक थ्रेशोल्ड के डिफ़ॉल्ट मान रोकने वाले नियमों के लिए 0.6 और अनुमति वाले नियमों के लिए 0.7 हैं।
दस्तावेज़ में दिया गया Responses का उदाहरण एक bash टूल को git push के लिए हार्ड-डिनाय नियम देता है। output_mode: "custom_item" के साथ चिह्नित पुश की जगह कॉल और कारण वाला openrouter:armor_blocked आइटम आता है, जिसके बाद मॉडल का जवाब होता है। उदाहरण दिखाता है कि दस्तावेज़ों के मुताबिक सेवा क्या लौटाती है; यह BIG CHANGE का किया हुआ परीक्षण नहीं है।
टूल चलाने से पहले आउटपुट अनुबंध चुनें
Chat Completions और Responses में डिफ़ॉल्ट text मोड अवरुद्ध कॉल हटा देता है और असिस्टेंट के पाठ में <openrouter_armor_blocked> चिह्न रखता है। Responses API custom_item भी सपोर्ट करता है, जो वहाँ टाइप वाला अवरुद्ध आइटम लौटाता है जहाँ function_call आया होता। दस्तावेज़ कहते हैं कि अगले Responses इनपुट में उस आइटम को बिना बदलाव वापस भेजें और उसके लिए अलग function_call_output न बनाएँ। safeguard_results कॉल ID के आधार पर फ़ैसले दर्ज करता है।
अनुरोध में safeguards होने पर Messages API का डिफ़ॉल्ट व्यवहार काफ़ी अलग होता है: claude_code_compatibility चिह्नित tool_use को content[] में रहने देता है और उसका flagged नतीजा safeguard_results में जोड़ता है। ऐप्लिकेशन को वह नतीजा पढ़कर कॉल चलाने से मना करना होता है। OpenRouter साफ़ चेतावनी देता है कि फ़ैसले की अनदेखी करने वाला Messages क्लाइंट टूल के चिह्नित इस्तेमाल को अंजाम देगा। जिस डेवलपर का क्लाइंट पर नियंत्रण नहीं है, वह Messages में output_mode: "text" माँग सकता है, ताकि OpenRouter कॉल रोक ले। API जिस आउटपुट मोड को व्यक्त नहीं कर सकता, उसे माँगने पर 400 मिलता है।
OpenRouter के Ori मेटाहार्नेस के ज़रिये Claude Code ऑटो मोड अतिरिक्त Armor प्लगइन एंट्री के बिना Messages अनुबंध का इस्तेमाल करता है। दस्तावेज़ बताते हैं कि Claude Code चिह्नित कॉल ठुकराता है, बातचीत के रिकॉर्ड में त्रुटि वाला नतीजा लिखता है और मॉडल को आगे बढ़ने देता है। वे यह भी कहते हैं कि अपने क्लासिफ़ायर को सपोर्ट करने वाला Anthropic एंडपॉइंट सीधे आगे भेजा जाने वाला फ़ैसला दे सकता है; दूसरे एंडपॉइंट पर Armor जाँच करता है। यह दस्तावेज़ों में बताया गया एकीकरण व्यवहार है, यह दावा नहीं कि हर तीसरे पक्ष का क्लाइंट इसे ठीक लागू करता है।
सीमित नियमसमूह तैयार करें और जाँचें
कस्टम एजेंट के लिए Armor गाइड में armor एंट्री को plugins में रखने को कहा गया है, जिसमें संस्करण वाला classifier_context (v: 1), auto_mode नियम और वैकल्पिक परिवेश संबंधी तथ्य होते हैं। पहले वह कार्रवाई और सुरक्षित संसाधन तय करें जिसे नियम को पहचानना चाहिए। फिर ऐसे निषेध के लिए हार्ड डिनाय चुनें जो उपयोगकर्ता की सहमति के बाद भी कायम रहना चाहिए; जहाँ सटीक सहमति या नामित अनुमति उसे उचित रूप से हटा सकती हो, वहाँ सॉफ़्ट डिनाय चुनें। दस्तावेज़ एक ही कमांड की लिखावट के बजाय कार्रवाई बताने और परिवेश के तथ्यों को ताज़ा रखने की सलाह देते हैं।
डिफ़ॉल्ट enforce मोड फ़ैसलों पर अमल करता है। audit वही फ़ैसले बताता है, लेकिन चिह्नित कॉल सहित हर कॉल आगे जाने देता है। यह प्रवर्तन से पहले असली ट्रैफ़िक देखने और नियम सुधारने का तरीका है, सुरक्षा देने वाला मोड नहीं। ऑडिट को claude_code_compatibility के साथ नहीं जोड़ सकते। दोनों मोड में safeguard_results पढ़ें: not_flagged का अर्थ अनुमति है, flagged मेल खाने वाला नियम बताता है, unavailable का अर्थ मूल्यांकन विफल होना है, और skipped प्रदाता का ऐसा नेटिव टूल बताता है जिसका मूल्यांकन नहीं हुआ। स्ट्रीमिंग में फ़ैसले का ऑब्जेक्ट जवाब के अंत में आता है, इसलिए Messages इस्तेमाल करने वाले क्लाइंट को टूल इस्तेमाल पर कार्रवाई करने से पहले उसका इंतज़ार करना चाहिए।
क्लासिफ़ायर का समय समाप्त होने, त्रुटि आने या बहुत बड़ा अनुरोध न सँभाल पाने पर OpenRouter on_error: "block" को डिफ़ॉल्ट बताता है; on_error: "log" कॉल आगे जाने देता है। Claude Code संगतता मोड में unavailable कॉल फ़ैसला दिखाई देते हुए आगे जाने दिया जाता है। प्रदाता के नेटिव सर्वर टूल डिफ़ॉल्ट रूप से छोड़ दिए जाते हैं, जब तक evaluate_native_tools उन्हें मूल्यांकन के लिए नेटिव मार्ग से बाहर न निकाले। ये सेटिंग और टूल का असल रास्ता टीम की एकीकरण जाँच में होने चाहिए; केवल Armor एंट्री होने से यह साबित नहीं होता कि हर टूल का मूल्यांकन हुआ।
बीटा की लागत, गति और दायरे की सीमाएँ
OpenRouter के अनुसार Claude Code के साथ संगत उसका नियमसमूह लोड होने पर मूल्यांकन ने मीडियन पर 279 मिलीसेकंड और 90वें पर्सेंटाइल पर 334 मिलीसेकंड जोड़े। ये बताई गई परिस्थिति में विक्रेता की रिपोर्ट की हुई मापें हैं, किसी खास एजेंट या हर नियमसमूह का बेंचमार्क नहीं। हर कॉल आगे भेजे जाने या रोके जाने से पहले एक बार परखा जाता है। बीटा में मूल्यांकन का शुल्क नहीं है; OpenRouter कहता है कि आम उपलब्धता से पहले कीमत घोषित करेगा। दस्तावेज़ भविष्य की दर तय नहीं करते।
निर्णय मॉडल सामान्य भाषा के नियमों को सामान्य भाषा के आर्ग्युमेंट के आधार पर परखता है, इसलिए गलत सकारात्मक नतीजे दे सकता है और कुछ उल्लंघन चूक सकता है। दस्तावेज़ असली ट्रैफ़िक पर ऑडिट फ़ैसले इस्तेमाल करने और हर नियम का थ्रेशोल्ड सुधारने की सलाह देते हैं। HIPAA, Zero Data Retention या डेटा क्षेत्र की पाबंदी वाले अनुरोधों के लिए Armor मूल्यांकन अभी समर्थित नहीं है। इन संदर्भों में प्लगइन चालू होने वाले अनुरोध को 403 मिलता है; Claude Code अनुरोध इसके बजाय कॉल को unavailable के रूप में आगे जाने देता है और Claude Code स्थानीय ऑटो-मोड मूल्यांकन पर लौटता है। बीटा की चेतावनी में कॉन्फ़िगरेशन फ़ील्ड, safeguard_results और openrouter:armor_blocked आइटम के प्रकार में बदलाव भी शामिल हैं।
Armor मॉडल से ऐप्लिकेशन को सौंपने के चरण में प्रस्तावित कॉल जाँचता है। इसलिए यह Microsoft के MXC कमांड नियंत्रण और NVIDIA के OpenShell तथा Sentry रनटाइम नियंत्रणों से अलग तंत्र है, जो वर्कलोड या उसकी पहुँच के आसपास पाबंदियाँ लागू करते हैं। Armor में तत्काल लागू करने का निर्णय यह है कि चुना गया जवाब फ़ॉर्मैट चिह्नित कॉल खुद रोकता है या क्लाइंट को उसे रोकना पड़ता है।
स्रोत और आगे पढ़ें
- OpenRouter Armor दस्तावेज़, 17 अक्टूबर 2026 को देखे गए। बीटा की स्थिति, क्लासिफ़ायर का क्रम, नियमों की प्राथमिकता, API जवाब अनुबंध, त्रुटियों का व्यवहार, निजता संदर्भों के अपवाद, बताई गई लेटेंसी और बीटा बिलिंग का प्राथमिक स्रोत। ये OpenRouter के दस्तावेज़ी दावे हैं; BIG CHANGE ने प्लगइन नहीं चलाया।
- Microsoft MXC पर BIG CHANGE एजेंट के बनाए कमांड के लिए नीति-आधारित नियंत्रण समझाता है। यह अलग प्रवर्तन परत बताता है, Armor का पहले का चरण नहीं।
- NVIDIA OpenShell और Sentry पर BIG CHANGE सॉफ़्टवेयर पहुँच नियंत्रण और वैकल्पिक हार्डवेयर निगरानी डिज़ाइन बताता है। यह संबंधित संदर्भ है, OpenRouter की इस सुविधा का सीधा अगला हिस्सा नहीं।
