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 मध्ये जोडतो. ॲप्लिकेशनने तो निकाल वाचून कॉल चालवण्यास नकार दिला पाहिजे. निर्णयाकडे दुर्लक्ष करणारा Messages क्लायंट चिन्हांकित टूल वापर चालवेल, असा स्पष्ट इशारा OpenRouter देते. क्लायंटवर नियंत्रण नसलेला विकसक Messages मध्ये output_mode: "text" मागू शकतो, जेणेकरून OpenRouter कॉल रोखेल. API ला सादर करता येत नाही असा आउटपुट मोड मागितल्यास 400 मिळतो.

OpenRouter च्या Ori metaharness मधून वापरलेला 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 वापरणाऱ्या क्लायंटने टूल वापरावर कृती करण्याआधी त्याची वाट पाहिली पाहिजे.

वर्गीकरण यंत्रणेचा वेळ संपल्यास, त्रुटी आल्यास किंवा अतिमोठी विनंती हाताळता न आल्यास डीफॉल्ट पर्याय on_error: "block" असल्याचे OpenRouter सांगते; on_error: "log" कॉल सोडतो. Claude Code सुसंगतता मोडमध्ये unavailable स्थितीचा कॉल निर्णय दिसत असतानाच सोडला जातो. पुरवठादाराची नेटिव्ह सर्व्हर टूल डीफॉल्टने वगळली जातात; मात्र evaluate_native_tools त्यांना मूल्यांकनासाठी नेटिव्ह मार्गाबाहेर काढण्यास भाग पाडू शकते. हे पर्याय आणि टूलचा प्रत्यक्ष मार्ग संघाच्या एकत्रीकरण तपासणीत असायला हवेत; केवळ Armor ची नोंद म्हणजे प्रत्येक टूल तपासले गेले असे नाही.

बीटाचा खर्च, वेग आणि व्याप्तीच्या मर्यादा

Claude Code शी सुसंगत नियमसंच लोड केलेला असताना मूल्यांकनामुळे वाढलेला विलंब मध्यकावर 279 मिलिसेकंद आणि 90व्या पर्सेंटाइलवर 334 मिलिसेकंद होता, असे OpenRouter सांगते. ही नमूद परिस्थितीत पुरवठादाराने दिलेली मोजमापे आहेत; विशिष्ट एजंट किंवा प्रत्येक नियमसंचाचा बेंचमार्क नाही. सोडण्यापूर्वी किंवा अडवण्यापूर्वी प्रत्येक कॉलचे एकदाच मूल्यांकन केले जाते. बीटा काळात मूल्यांकनाचे बिल आकारले जात नाही; सर्वांसाठी उपलब्ध करण्यापूर्वी किंमत जाहीर करू, असे 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 सुविधेचा थेट पुढचा भाग नाही.