OpenRouter అందించే Armor బీటా మోడల్ ప్రతిపాదించిన టూల్ కాల్‌కూ, దాన్ని అమలు చేయగల అప్లికేషన్‌కూ మధ్య నియమాల వర్గీకరణ వ్యవస్థను ఉంచుతుంది. ఏజెంట్ డెవలపర్‌కు ముఖ్యమైన అంశం, నిర్ణయం వాస్తవంగా ఏ దశలో అమలును ఆపుతుందనేదే. Chat Completions, Responsesలో Armor గుర్తించిన కాల్‌ను నిలిపివేయగలదు. Messages APIలోని Claude Code అనుకూలత మోడ్‌లో గుర్తించిన tool_use ప్రతిస్పందనలోనే ఉంటుంది. దాన్ని అమలు చేయడానికి క్లయింట్ నిరాకరించాలి.

ప్రస్తుత డాక్యుమెంటేషన్, అక్టోబర్ 2026 నుంచి అందుబాటులో ఉన్న బీటాను వివరిస్తుంది. అక్టోబర్ 17న BIG CHANGE, డాక్యుమెంటేషన్‌లోని అభ్యర్థన–ప్రతిస్పందన ఒప్పందాలను సమీక్షించింది. మేము 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 మెటాహార్నెస్ ద్వారా 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 ఫీచర్‌కు నేరుగా కొనసాగింపు కాదు.