# प्रति-उपयोग पुष्टि का एक ब्रेक-ईवन बिंदु होता है

प्रति-उपयोग पुष्टि अपनी लागत तभी तक वसूल करती है, जब तक उसके पकड़ने वाले कॉल इतने असाधारण हों कि उन पर इंसान को नया निर्णय लेना उचित हो। जब रोज़ का प्रोडक्शन काम लगातार प्रॉम्प्ट भेजने लगता है, तो यही नियंत्रण टीम से एक ही निर्णय की कीमत बार-बार वसूलने लगता है। ब्रेक-ईवन बिंदु आमतौर पर लोगों की अपेक्षा से कम होता है, क्योंकि क्लिक सस्ता हिस्सा है। इंतज़ार, अनुरोध पर भरोसा करने लायक संदर्भ पढ़ना और बाधित विचार-क्रम को फिर से पकड़ना असली लागत बनते हैं।

उपयोगी तुलना के लिए दो अलग खाते चाहिए। एक में ऑपरेटर का समय दर्ज होता है। दूसरे में अधिक व्यापक अनुमति विंडो देने का सुरक्षा परिणाम। इन्हें मिलाने से `बारह प्रॉम्प्ट परेशान करते हैं` या `प्रोडक्शन में हमेशा क्लिक चाहिए` जैसे गलत निष्कर्ष निकलते हैं। इनमें से कोई भी बात नहीं बताती कि प्रॉम्प्ट निर्णय बदलता है या नहीं। नीचे का मॉडल बाधा की कीमत तय करता है, बिना यह मानने के कि विनाशकारी डेटाबेस कमांड का जोखिम केवल पढ़ने वाले स्टेटस कॉल जितना है।

## एक पुष्टि की पूरी लागत निकालें

एक पुष्टि की पूरी लागत में प्रतिक्रिया समय और उस रिकवरी का हिस्सा शामिल है जो वास्तव में प्रॉम्प्ट के कारण होता है। अस्पष्ट रेटिंग, जैसे कम बाधा, के बजाय सेकंड लें। ये मान तय करें:

- `p`: प्रतिदिन दिखाए गए पुष्टि प्रॉम्प्ट
- `t`: प्रॉम्प्ट आने से निर्णय पूरा होने तक माध्यिका सेकंड
- `r`: बाधित काम पर लौटने के लिए आवश्यक माध्यिका सेकंड
- `q`: एकाग्र काम के दौरान आने वाले प्रॉम्प्ट का अंश
- `d`: वे डेवलपर जिनकी व्यक्तिगत प्रॉम्प्ट गिनती `p` में शामिल है

यदि `p` प्रति डेवलपर गिनती है, तो टीम की दैनिक लागत होगी:

```text
per_use_seconds = p * d * (t + q * r)
```

यदि `p` में पहले से पूरी टीम की हर पुष्टि शामिल है, तो `d` हटा दें:

```text
per_use_seconds = p * (t + q * r)
```

यह अंतर सबसे आम स्प्रेडशीट गलती से बचाता है: टीम-भर के प्रॉम्प्ट के कुल को दोबारा टीम के आकार से गुणा कर देना। हर इनपुट के आगे उसकी इकाई लिखें। `8 prompts/person/day` और `48 prompts/team/day` एक ही छह-सदस्यीय टीम का वर्णन कर सकते हैं।

`t` के लिए माध्यिका लें, क्योंकि कुछ छोड़े गए प्रॉम्प्ट औसत को बिगाड़ सकते हैं। फिर भी, उन छोड़े गए अनुरोधों को छिपाएँ नहीं। उन्हें असफल काम के रूप में अलग से ट्रैक करें। रिकवरी के लिए तब तक का समय मापें, जब तक डेवलपर पिछले सार्थक काम पर न लौट आए, न कि तब तक जब तक मंज़ूरी विंडो बंद न हो। कोई डेवलपर नौ सेकंड में मंज़ूरी दे और फिर क्वेरी को फिर से समझने में दो मिनट लगाए, तो उसने नौ नहीं, 129 सेकंड चुकाए।

`q` वाला भाग मॉडल को कार्यों के बीच संभाले गए प्रॉम्प्ट पर रिकवरी की लागत जोड़ने से रोकता है। यदि अभी इसे माप नहीं सकते, तो `q = 0.5` और `q = 1` के साथ एक रेंज निकालें। अनुमान पर बने सटीक आंकड़े से यह रेंज अधिक ईमानदार है।

## प्रॉम्प्ट को उस सीमा पर गिनें जिसे लोग महसूस करते हैं

हर उस निर्णय को गिनें जो किसी व्यक्ति को लेना पड़ता है, हर API अनुरोध या सिस्टम द्वारा भेजी गई हर सूचना को नहीं। पाँच रीट्राई कवर करने वाला एक मंज़ूरी कार्ड एक पुष्टि है। ऑटोमैटिक रीट्राई लूप से बने पाँच कार्ड पाँच पुष्टियाँ हैं, भले ही मूल कार्रवाई तार्किक रूप से एक ही काम हो। मॉडल इंसानी काम की कीमत लगाता है, इसलिए इसकी इकाई इंसानी सीमा से मेल खानी चाहिए।

गिनती वहाँ शुरू करें जहाँ प्रॉम्प्ट पर कार्रवाई की जा सकती हो। ऐसा कार्ड, जो दिख तो गया लेकिन समझने के लिए टर्मिनल खोलना पड़े, पहले ही प्रतिक्रिया समय ले चुका है। अस्वीकृतियाँ, समाप्त प्रॉम्प्ट और डुप्लिकेट अनुरोध शामिल करें, क्योंकि वे ध्यान लेते हैं। उन ऑटोमेटेड कॉल को अलग दर्ज करें जो कभी किसी व्यक्ति से नहीं पूछते। वे जोखिम और क्षमता के लिए मायने रखते हैं, लेकिन उनकी कोई सीधी पुष्टि लागत नहीं है।

प्रतिदिन की गिनती स्थिर रहे, तब भी प्रॉम्प्ट का एक साथ आना मायने रखता है। दस घंटे में फैले बीस प्रॉम्प्ट सहने योग्य हो सकते हैं। रिलीज़ के दौरान आने वाले वही बीस प्रॉम्प्ट, रिलीज़ की समस्या समझ सकने वाले इकलौते लोगों को रोक सकते हैं। किसी भी 15 मिनट की विंडो में पुष्टियों का एक सरल अधिकतम रखें। दैनिक समीकरण श्रम का अनुमान देता है, जबकि यह आँकड़ा ऑपरेशनल देरी दिखाता है।

कई लोगों को भेजे गए अलर्ट को कई पुष्टियाँ न मानें, जब तक कई लोग सच में उन्हें न देखें। यदि प्रोडक्शन प्रॉम्प्ट चार डेवलपर को जाता है और उनमें से दो अक्सर उसे खोलते हैं, फिर एक मंज़ूरी देता है, तो दो मानवीय प्रतिक्रियाएँ दर्ज करें। सूचना पहुँचना लागत की सीमा नहीं है, ध्यान है।

सही इवेंट रिकॉर्ड के लिए बस कुछ फ़ील्ड चाहिए:

```text
ts, request_id, responder, decision, shown_at, decided_at, prior_task_resumed_at, key_class
2026-07-21T14:03:10Z, r-1842, dev-3, allow, 14:03:10, 14:03:22, 14:05:01, deploy-read
```

इस पंक्ति में `t` 12 सेकंड है और देखी गई रिकवरी 99 सेकंड है। यह रिकॉर्ड आपको उसी अनुरोध के दोहराए गए प्रॉम्प्ट, जवाब देने वालों पर असमान भार और सीक्रेट या अनुरोध पेलोड इकट्ठा किए बिना महँगे कुंजी वर्ग खोजने भी देता है।

## सत्र अनुमति मंज़ूरी का अर्थ बदल देती है

सत्र अनुमति पुष्टि हटाती नहीं है। यह निर्णय को हर उपयोग से हटाकर सीमित एजेंट रन की शुरुआत में ले जाती है। इसलिए तुलना की इकाई कॉल से बदलकर सत्र हो जाती है। सत्र मंज़ूरी में प्रोसेस की पहचान होनी चाहिए और प्रोसेस समाप्त होने पर यह भी समाप्त होनी चाहिए। केवल दोस्ताना डिस्प्ले नाम या बिना निश्चित अंत वाली समय विंडो से जुड़ी मंज़ूरी अलग और कमज़ोर नियंत्रण है।

`s` को प्रति डेवलपर प्रतिदिन नए एजेंट सत्र और `a` को सत्र जाँचने व मंज़ूर करने के माध्यिका सेकंड मानें। दैनिक ऑपरेटर लागत होगी:

```text
session_seconds = d * s * a
```

गणित जल्दी ही सत्रों के पक्ष में जाता है, क्योंकि एक निर्णय कई कॉल कवर कर सकता है। सुरक्षा लागत यह है कि मंज़ूर रन के भीतर अधिकार अधिक व्यापक हो जाता है। कोई समझौता किया गया या गलत दिशा में गया प्रोसेस नया प्रॉम्प्ट दिखाए बिना एक और अनुमत कॉल कर सकता है। इसीलिए केवल समय की तुलना से कोई सार्वभौमिक विजेता घोषित नहीं हो सकता।

सत्र का अंत स्पष्ट होना चाहिए। प्रोसेस समाप्ति को समझना आसान है: अनुमति उसी प्रोसेस के साथ गायब हो जाती है जिसे वह मिली थी। आठ घंटे की तय विंडो काम से अधिक समय तक रह सकती है, हैंडऑफ़ के बाद भी चल सकती है और ऐसी बाद की कार्रवाई कवर कर सकती है जिस पर मंज़ूरी के समय किसी ने विचार नहीं किया था। यदि अनुमति प्रणाली सक्रिय सत्र को रद्द नहीं कर सकती या यह नहीं दिखा सकती कि उसे कौन-सा प्रोसेस पकड़े है, तो उसे मुफ्त मानने के बजाय नियंत्रण की कमी की लागत मानें।

सत्र प्रॉम्प्ट में जवाब देने वाले के लिए निर्णय लेने योग्य पहचान भी होनी चाहिए। पाथ नाम और एजेंट लेबल कॉपी किए जा सकते हैं। कोड-साइनिंग अथॉरिटी, एक्ज़ीक्यूटेबल की पहचान और लॉन्च संदर्भ बेहतर प्रमाण देते हैं कि शुरुआत किसने की। व्यक्ति किसी ऐसे वाक्य को स्वीकार नहीं कर रहा कि एजेंट को एक्सेस चाहिए, वह एक समयावधि के लिए किसी प्रिंसिपल को मंज़ूरी दे रहा है।

## ब्रेक-ईवन समीकरण असली सीमा दिखाता है

जब प्रति-उपयोग पुष्टि के दैनिक पूरे सेकंड सत्र मंज़ूरी की लागत से अधिक हो जाएँ, तब वह अधिक ऑपरेटर समय लेती है। प्रति डेवलपर प्रॉम्प्ट गिनती के लिए दोनों समीकरण बराबर रखें:

```text
p * d * (t + q * r) = d * s * a
p_break_even = (s * a) / (t + q * r)
```

जब हर डेवलपर की प्रॉम्प्ट और सत्र दर समान हो, तो टीम का आकार कट जाता है। इसका अर्थ यह नहीं कि `d` मायने नहीं रखता। प्रति व्यक्ति सीमा टीम बढ़ने पर भी वैसी रहती है, जबकि दोनों तरफ कुल लागत बढ़ती है। काम असमान हो, कई लोग एक ही प्रॉम्प्ट देखें या टीम का केवल एक हिस्सा एजेंट सत्र शुरू करे, तब टीम का आकार फिर महत्वपूर्ण हो जाता है।

छह डेवलपर का उदाहरण लें। हर व्यक्ति प्रतिदिन दो ऐसे एजेंट रन शुरू करता है जो प्रोडक्शन में काम कर सकते हैं और सत्र निर्णय में 15 सेकंड लगते हैं। प्रति-उपयोग निर्णयों में माध्यिका 12 सेकंड लगते हैं। इनमें 70 प्रतिशत एकाग्र काम के दौरान आते हैं और माध्यिका रिकवरी 90 सेकंड है।

```text
p_break_even = (2 * 15) / (12 + 0.70 * 90)
p_break_even = 30 / 75
p_break_even = 0.4 confirmations per developer per day
```

प्रति डेवलपर प्रतिदिन आठ प्रति-उपयोग प्रॉम्प्ट पर टीम 48 प्रॉम्प्ट संभालती है। उनकी पूरी लागत है:

```text
48 * (12 + 0.70 * 90) = 3,600 seconds = 60 minutes/day
```

12 सत्र मंज़ूरियों की लागत `6 * 2 * 15 = 180 seconds`, यानी तीन मिनट है। हर प्रोडक्शन दिन का अंतर 57 मिनट है। सिर्फ क्लिक का समय प्रति-उपयोग मंज़ूरी के लिए 9.6 मिनट बताएगा और अधिकतर लागत छूट जाएगी।

0.4 की सीमा हर सत्र को व्यापक एक्सेस देने का निर्देश नहीं है। इसका मतलब है कि एक जैसे नियमित कॉल को मंज़ूरी देने का अधिक महँगा तरीका बार-बार प्रॉम्प्ट बन गया है। जिन कॉल के परिणाम हर बार बदल सकते हैं, उनके लिए प्रति-उपयोग निर्णय रखें। अनुमानित और सीमित काम को सत्र दायरे में तभी ले जाएँ, जब सत्र की पहचान, अवधि, अनुमत चैनल और रद्द करने का व्यवहार उस दायरे को स्वीकार्य बनाते हों।

कार्रवाई से पहले संवेदनशीलता जाँच चलाएँ। समान इनपुट के साथ रिकवरी लागत शून्य हो तो सीमा `30 / 12 = 2.5` प्रॉम्प्ट प्रति डेवलपर प्रतिदिन हो जाती है। तीन मिनट की रिकवरी पर वह 0.22 से नीचे आती है। यदि केवल अविश्वसनीय रिकवरी अनुमान पर सिफारिश बदलती है, तो निर्णय स्थिर है। यदि आपकी भरोसेमंद रेंज में निष्कर्ष पलटता है, तो बहस करने के बजाय रिकवरी मापें।

## सस्ता प्रॉम्प्ट भी पूरी कार्रवाई रोक सकता है

श्रम लागत और बीता हुआ विलंब अलग सवालों के जवाब देते हैं। ऊपर का समीकरण इंसानी समय जोड़ता है, लेकिन जब तक कोई कार्रवाई नहीं कर सकता, एजेंट भी इंतज़ार करता है। 15 सेकंड का निर्णय केवल 15 सेकंड का श्रम ले सकता है, फिर भी यदि प्रॉम्प्ट 225 सेकंड तक अनदेखा पड़ा रहे तो डिप्लॉयमेंट में चार मिनट जुड़ सकते हैं। दोनों मान ट्रैक करें। पहला बताता है कि नियंत्रण की टीम को क्या लागत है, दूसरा बताता है कि प्रोडक्शन वर्कफ़्लो को क्या लागत है।

ऐसे एजेंट पर विचार करें जो पाँच कॉल की रिलीज़ जाँच करता है: डिप्लॉयमेंट स्थिति पढ़ना, हाल की त्रुटियाँ लाना, सक्रिय रिविज़न देखना, SSH पर हेल्थ कमांड चलाना और परिणाम रिकॉर्ड करना। हर कॉल ऐसी कुंजी इस्तेमाल करता है जिसमें प्रति-उपयोग मंज़ूरी तय है। पहला कार्ड कोड रिव्यू के दौरान ऑन-ड्यूटी डेवलपर तक पहुँचता है। डेवलपर उसे जाँचकर डिफ़ पर लौटता है। एजेंट के पहली प्रतिक्रिया प्रोसेस करने के 40 सेकंड बाद अगला कॉल आता है। वर्कफ़्लो समाप्त होने तक यह दोहराता है।

पाँच क्लिक में कुल केवल एक मिनट लग सकता है। वे एक बाधा नहीं हैं, क्योंकि उनके बीच का अंतर डेवलपर को फिर से रिव्यू में जाने और दोबारा बाहर खींचे जाने देता है। यदि हर बाधा के बाद 75 सेकंड की रिकवरी हो, तो पूरी मानवीय लागत 435 सेकंड पहुँचती है: `5 * (12 + 75)`। एजेंट का बीता हुआ विलंब अधिक हो सकता है, क्योंकि उसका काम हर मंज़ूरी के पीछे क्रम से अटकता है। डैशबोर्ड केवल क्लिक लेटेंसी दिखाए, तो दोनों आंकड़े नहीं दिखेंगे।

अब मान लें कि चौथा कॉल किसी अनपेक्षित होस्ट पर हेल्थ कमांड चलाने को कहता है। डेवलपर उसे अस्वीकार कर देता है। यह अस्वीकृति साबित करती है कि एक प्रॉम्प्ट में उपयोगी, कॉल-विशिष्ट जानकारी थी। इससे यह साबित नहीं होता कि बाकी चार नियमित रीड के लिए अलग निर्णय ज़रूरी थे। बेहतर डिज़ाइन पहचाने गए एजेंट प्रोसेस को तीन ज्ञात रीड कॉल के लिए अधिकृत कर सकता है, SSH के लिए प्रति-उपयोग मंज़ूरी रख सकता है और इच्छित दायरे से बाहर के होस्ट अस्वीकार कर सकता है। मॉडल इस विभाजन को समर्थन देता है, क्योंकि यह पूरे वर्कफ़्लो का औसत निकालने के बजाय लागत और अस्वीकृतियों को कुंजी वर्ग के अनुसार समूहित करता है।

यह विफलता क्रमिक पुष्टियों की लागत भी दिखाती है। जब कॉल पिछले परिणामों पर निर्भर हों, तो मंज़ूरी का विलंब महत्वपूर्ण पथ पर होता है। स्वतंत्र कॉल के लिए एजेंट कई अनुरोध साथ भेज सकता है, जिससे जवाब देने वाले को जाँचने के लिए एक साथ कई प्रॉम्प्ट मिलते हैं। दैनिक पूरे-समय का समीकरण मानव निर्णयों की एक ही संख्या को लगभग समान मानता है, लेकिन ऑपरेशनल रूप अलग होता है। रिलीज़ की गति और इन्सिडेंट रिस्पॉन्स मायने रखते हों तो वर्कफ़्लो का बीता समय या एजेंट प्रतीक्षा समय रिकॉर्ड करें।

एजेंट के प्रतीक्षा समय को सीधे डेवलपर के श्रम रुपये में न बदलें। इंतज़ार करता प्रोसेस काम करता व्यक्ति नहीं है। इसे बीते विलंब के रूप में बताएँ, फिर तय करें कि यह विलंब किसे नुकसान पहुँचाता है: डिप्लॉयमेंट की अवधि, इन्सिडेंट की जाँच, ऑटोमेटेड समयसीमा या किसी गैर-महत्वपूर्ण चीज़ को। खाते अलग रखने से प्रभावशाली दिखने वाला लेकिन गलत कुल बचता है।

यही अनुशासन अस्वीकृत कॉल पर भी लागू होता है। अस्वीकृति अनचाही कार्रवाई का परिणाम बचाती है, जो बाधा लागत से कहीं अधिक हो सकता है, लेकिन साक्ष्य के बिना उसका विश्वसनीय मौद्रिक मूल्य नहीं लगाया जा सकता। गेट ने क्या पकड़ा, यह ठोस शब्दों में बताएँ। `अपरिचित होस्ट पर SSH अस्वीकार किया गया` निर्णय का साक्ष्य है। `मंज़ूरी ने बड़ी घटना रोक दी` तब तक अनुमान है, जब तक जाँच से वह नतीजा स्थापित न हो।

विफलता के इस उदाहरण को डिज़ाइन टेस्ट की तरह इस्तेमाल करें। यदि चार प्रॉम्प्ट हटाने से पाँचवाँ पकड़ने के लिए चाहिए था संदर्भ भी हट जाता है, तो प्रस्तावित सत्र दायरा बहुत व्यापक है। यदि हर कॉल अलग कुंजी वर्ग इस्तेमाल करता है और संवेदनशील कॉल का गेट बना रहता है, तो नियमित प्रॉम्प्ट लागत जोड़ते हैं, उस निर्णय में मदद नहीं करते। ब्रेक-ईवन समीकरण बताता है कि डिज़ाइन कब जाँचना है, कॉल क्रम बताता है कि कहाँ विभाजित करना है।

## माध्यिका प्रतिक्रिया समय कतारों और छोड़े गए काम को नहीं दिखाता

माध्यिका प्रतिक्रिया समय सामान्य संभाले गए प्रॉम्प्ट को दर्शाता है, लेकिन प्रोडक्शन काम अक्सर लंबे समय वाले किनारों पर विफल होता है। एक अधिकृत डेवलपर की प्रतीक्षा करता प्रॉम्प्ट एजेंट, डिप्लॉयमेंट या इन्सिडेंट जाँच को माध्यिका से कहीं अधिक समय तक रोक सकता है। श्रम समीकरण में इस्तेमाल मान के साथ 90वाँ परसेंटाइल प्रतिक्रिया समय, समाप्त प्रॉम्प्ट और पहले वैध जवाब देने वाले तक का समय रिकॉर्ड करें।

हर लागत गणना में 90वाँ परसेंटाइल सीधे न डालें। इससे हर प्रॉम्प्ट पर ऐसे लागत लगेगी जैसे वह धीमा हो। सामान्य श्रम के अनुमान के लिए माध्यिका लें और लंबे समय वाले मामलों को ऑपरेशनल बाधा के रूप में रिपोर्ट करें। उदाहरण: `42 loaded minutes/day; median decision 11s; p90 decision 96s; 3 expirations/week`। यह संक्षिप्त पंक्ति एक मिले-जुले स्कोर से अधिक सच बताती है।

बाधा के बाद रिकवरी का भी लंबा किनारा होता है। लॉग पढ़ते समय आने वाले प्रॉम्प्ट की लागत आधा मिनट हो सकती है। उसी व्यक्ति के कार्यशील स्मरण में निष्पादित न किया गया डेटाबेस सुधार हो, तब आने वाला प्रॉम्प्ट पूरा फिर से जाँचने पर मजबूर कर सकता है। पिछले काम को नियमित, एकाग्र और इन्सिडेंट जैसी दो या तीन श्रेणियों में बाँटें। आप नीति की सीमा खोज रहे हैं, न्यूरोसाइंस का शोधपत्र नहीं।

छोड़ा गया काम लागत खाते में होना चाहिए। यदि एजेंट इंतज़ार में टाइम आउट हो, रीट्राई करे और दूसरा कार्ड दिखाए, तो पहले प्रॉम्प्ट की लागत शून्य नहीं थी, केवल इसलिए कि किसी ने मंज़ूरी नहीं दी। उसे मिला ध्यान, एजेंट पर लगा विलंब और वह डुप्लिकेट गिनें, यदि कोई व्यक्ति बाद में उसे भी देखता है।

सिर्फ बड़ी प्रॉम्प्ट संख्या मंज़ूरी की थकान सिद्ध नहीं करती। एक ही कुंजी वर्ग की दोहराई मंज़ूरियाँ, घटता निरीक्षण समय, डुप्लिकेट अनुरोध और नियमित कार्रवाइयों के लिए लगभग शून्य अस्वीकृति दर देखें। ये संकेत बताते हैं कि इंटरफ़ेस लोगों से पहले से तय निर्णय की फिर पुष्टि करा रहा है। ऊँची अस्वीकृति दर कहती है कि प्रॉम्प्ट महँगे होने पर भी स्वीकार्य और अस्वीकार्य कॉल को अलग कर रहे हैं।

## अधिक डेवलपर समन्वय बदलते हैं, गुणा नहीं

प्रोडक्शन में जवाब देने वालों की संख्या मायने रखती है, क्योंकि प्रॉम्प्ट का वितरण शायद ही बराबर होता है। टीम-भर के प्रॉम्प्ट को हेडकाउंट से गुणा करना लागत बढ़ाकर बताता है, जबकि सभी का औसत लेने से यह छिप सकता है कि लगभग सारी बाधाएँ दो लोगों पर आ रही हैं। पहले प्रति व्यक्ति पूरे मिनट निकालें, फिर उन्हें जोड़ें। टीम के कुल के साथ माध्यिका और सबसे व्यस्त जवाब देने वाले का आँकड़ा भी बताएँ।

मान लें 60 प्रॉम्प्ट दस-सदस्यीय प्रोडक्शन समूह तक पहुँचते हैं, लेकिन रूटिंग में 45 प्राथमिक जोड़ी तक जाते हैं। प्रति व्यक्ति छह प्रॉम्प्ट का टीम औसत किसी के दिन का वर्णन नहीं करता। प्राथमिक जवाब देने वालों को नियमित कॉल के लिए सत्र अनुमति चाहिए हो सकती है, भले ही समूह के बाकी लोगों को बहुत कम बाधा हो। प्राथमिक भूमिका बदल-बदल कर देने से परेशानी बँट सकती है, पर कुल लागत नहीं घटती और हैंडऑफ़ का काम बढ़ सकता है।

कई लोगों को भेजना एक और लागत बनाता है। एक प्रॉम्प्ट कई लोगों तक जाए, तो एक मंज़ूरी इंतज़ार खत्म करती है, लेकिन दूसरे डेवलपर उसे पहले ही पढ़ चुके हो सकते हैं। `w` जोड़ें, यानी हर प्रॉम्प्ट देखने वाले लोगों की औसत संख्या। तब टीम-कुल का रूप होगा:

```text
per_use_seconds = p * w * (t + q * r)
```

यह रूप केवल तब लें जब हर निरीक्षण की लागत लगभग समान हो। मंज़ूरी देने वाला 20 सेकंड लगाए और बाकी लोग दो सेकंड नज़र डालें, तो इन समूहों की गणना अलग-अलग करें। ऑपरेटिंग पैटर्न को ज़रूरत हो तो मॉडल को थोड़ा विस्तृत होना चाहिए, केवल इसलिए नहीं कि स्प्रेडशीट में और सेल की जगह है।

सत्र लागत भी कुछ लोगों पर केंद्रित हो सकती है। यदि केवल दो नामित ऑपरेटर प्रोडक्शन में काम कर सकने वाले रन शुरू करते हैं, तो सत्र वाली तरफ उन दो का इस्तेमाल करें, उन दस लोगों का नहीं जिन्हें प्रति-उपयोग प्रॉम्प्ट मिल सकता है। हर पद के साथ संबंधित लोगों का समूह लिखें। हेडकाउंट अकेले जोखिम का गुणक नहीं है, अधिकार का वितरण और वास्तविक ध्यान मायने रखता है।

यहीं कतार का स्वामित्व भी महत्वपूर्ण है। स्पष्ट ऑन-ड्यूटी जवाब देने वाले की साझा मंज़ूरी कतार डुप्लिकेट निरीक्षण घटाती है। हर अनुरोध पूरी टीम को भेजने से तेज़ क्लिक मिलने की संभावना बढ़ सकती है, लेकिन चुपचाप अधिक सामूहिक एकाग्रता खर्च होती है। तेज़ मंज़ूरी और सस्ती मंज़ूरी अलग माप हैं।

## जोखिम तय करता है कि किन कॉल पर प्रति-उपयोग गेट रहेंगे

वॉल्यूम दिखा सकता है कि कोई नियंत्रण महँगा है, लेकिन परिणाम तय करता है कि उसकी कीमत चुकाते रहना है या नहीं। कुंजियों या कार्रवाई वर्गों को इस आधार पर अलग करें कि उसी सत्र में एक और कॉल क्या कर सकता है। केवल पढ़ने वाली इन्वेंटरी, डिप्लॉयमेंट शुरू करना, प्रोडक्शन में बदलाव और क्रेडेंशियल प्रशासन को एक ही सेटिंग नहीं मिलनी चाहिए, केवल इसलिए कि उन्हें एक ही एजेंट चलाता है।

लोग अक्सर ऑथेंटिकेशन, ऑथराइज़ेशन और पुष्टि को मिला देते हैं। ऑथेंटिकेशन प्रोसेस या व्यक्ति पहचानता है। ऑथराइज़ेशन एक दायरा देता है। पुष्टि इंसान से प्रस्तावित उपयोग पर फिर विचार करने को कहती है। बार-बार पुष्टि कमज़ोर प्रोसेस पहचान को ठीक नहीं कर सकती, और मज़बूत पहचान व्यापक अनुमति को सुरक्षित नहीं बनाती। इन तीनों को गड़बड़ करें, तो आप हर कॉल पर क्लिक करते रहेंगे और गलत प्रोसेस को अनुमति देते रहेंगे।

जहाँ अनुरोध में ऐसे तथ्य हों जो निर्णय को महत्वपूर्ण रूप से बदलते हैं, वहाँ प्रति-उपयोग पुष्टि रखें: लक्ष्य होस्ट, कार्रवाई वर्ग, वातावरण या प्रभावित संसाधन। प्रोडक्शन पर विनाशकारी कमांड अधिक वॉल्यूम पर भी नई जाँच के योग्य हो सकती है। यदि जवाब देने वाले दिन में पचास बार आने के कारण इसे पढ़े बिना मंज़ूर कर रहे हैं, तो डिज़ाइन पहले ही विफल है। तेज़ क्लिक को नियंत्रण मानने के बजाय स्रोत वॉल्यूम घटाएँ या अनुमत कार्रवाई सीमित करें।

सत्र अनुमति बार-बार होने वाले कॉल के लिए उपयुक्त है, जब इंसान प्रोसेस और दायरे के बारे में एक बार सार्थक निर्णय ले सकता हो। अच्छे उम्मीदवारों में सीमित अवधि, अनुमानित चैनल, दिखने योग्य पहचान, तुरंत रद्द करना और इतना विस्तृत ऑडिट रिकॉर्ड होता है कि अलग-अलग कॉल फिर से समझी जा सकें। सत्र असंबंधित प्रोसेसों के बीच बाँटी जाने वाली पूरे दिन की बेयरर अनुमति नहीं बनना चाहिए।

मिश्रित निर्णय अक्सर सही होता है। नियमित API रीड और ज्ञात डिप्लॉयमेंट जाँच को प्रोसेस-आधारित सत्र में रखें। उन कम कुंजियों पर प्रति-उपयोग मंज़ूरी बनाए रखें जो प्रोडक्शन में बदलाव या क्रेडेंशियल प्रशासन कर सकती हैं। इससे बाधाओं की संख्या कम होती है और एक कार्रवाई के जोखिम बदलने पर सोच-समझकर रुकने की जगह बनी रहती है।

यह कहकर प्रति-उपयोग पुष्टि का समर्थन न करें कि अधिक प्रॉम्प्ट हमेशा अधिक सुरक्षा देते हैं। जिस नियंत्रण को लोग आदतन मंज़ूर कर दें, उसमें औपचारिकता बहुत और भेद करने की क्षमता कम होती है। उपयोगी सवाल यह है कि प्रॉम्प्ट का पूरा खर्च चुकाने लायक, क्या वह अक्सर कोई अलग निर्णय करवाता है।

## दायरा बदलने से पहले एक प्रोडक्शन सप्ताह मापें

एक सप्ताह का नमूना आमतौर पर अनुमान को विश्वसनीय रेंज से बदलने के लिए पर्याप्त है, बशर्ते उसमें सामान्य प्रोडक्शन काम और कम से कम एक व्यस्त अवधि शामिल हो। मापने के लिए इन्सिडेंट पैदा न करें। प्रॉम्प्ट इवेंट एक्सपोर्ट करें, जवाब देने वालों से छोटे नमूने के लिए रिकवरी दर्ज करने को कहें और वर्कशीट इतनी सरल रखें कि कोई उसे पूरा कर सके।

हर जवाब देने वाले के लिए प्रतिदिन एक पंक्ति लें:

```text
date | responder | prompts_seen | prompts_allowed | prompts_denied | median_response_s | focus_share | median_recovery_s | sessions_started | median_session_approval_s
2026-07-21 | dev-3 | 11 | 10 | 1 | 12 | 0.70 | 90 | 2 | 15
```

इन सेल की गणना करें:

```text
loaded_per_use_min = prompts_seen * (median_response_s + focus_share * median_recovery_s) / 60
session_min = sessions_started * median_session_approval_s / 60
break_even_prompts = sessions_started * median_session_approval_s / (median_response_s + focus_share * median_recovery_s)
```

फिर प्रॉम्प्ट को कुंजी वर्ग के हिसाब से देखें। टीम का कुल बता सकता है कि बदलाव करना उचित है, लेकिन वर्ग के आधार पर विभाजन बताता है कि क्या बदलना है। यदि 80 प्रतिशत प्रॉम्प्ट केवल पढ़ने वाली स्टेटस जाँच से आते हैं और कुछ अस्वीकृत अनुरोध प्रोडक्शन बदलाव से जुड़े हैं, तो हर कुंजी को एक ही मोड पर ले जाना साक्ष्य का सबसे उपयोगी हिस्सा खो देगा।

हर अस्वीकृति के लिए साधारण श्रेणी में एक कारण दर्ज करें, जैसे गलत लक्ष्य, अनपेक्षित कार्रवाई, डुप्लिकेट या अपर्याप्त संदर्भ। मुक्त रूप में लिखे गए इन्सिडेंट विवरण को जोड़ना मुश्किल होता है। कारणों का वितरण बताता है कि गेट खतरनाक अनुरोध पकड़ता है या भ्रमित करने वाले प्रॉम्प्ट की भरपाई करता है।

रिकवरी सैंपलिंग के लिए निगरानी की ज़रूरत नहीं है। जवाब देने वाले से कुछ प्रॉम्प्ट के लिए `0`, `30`, `90` या `180+` सेकंड चिह्नित करने को कहें, या उनके नियंत्रण में मौजूद स्थानीय काम के ट्रेस से काम पर लौटना अनुमानित करें। परिणाम के साथ तरीका प्रकाशित करें। दो दशमलव तक ले जाए गए मनगढ़ंत स्थिरांक से मोटा, देखा गया वितरण बेहतर है।

अनुमति बदलने से पहले पूर्वानुमान लिखें: कौन-से प्रॉम्प्ट वर्ग गायब होंगे, उनकी जगह कितनी सत्र मंज़ूरियाँ आएँगी और कौन-से प्रति-उपयोग गेट रहेंगे। अगले सप्ताह उन्हीं फ़ील्ड के साथ मापें। यदि एजेंट बिना रुके आगे बढ़ सकें और कॉल वॉल्यूम बढ़ जाए, तो कच्चे API अनुरोधों के बजाय मानवीय निर्णयों की तुलना करें।

## पुष्टि वहाँ खर्च करें जहाँ वह निर्णय बदल सकती है

मॉडल से एक रूटिंग निर्णय निकलना चाहिए, एक वैश्विक सीमा नहीं। हर कुंजी वर्ग के लिए पूरी प्रति-उपयोग मिनट लागत की तुलना सत्र मंज़ूरी मिनटों से करें, फिर मंज़ूर सत्र में एक अतिरिक्त कॉल का परिणाम लिखें। जिन नियमित वर्गों में लागत का अंतर बड़ा और सत्र का परिणाम स्वीकार्य हो, वे सत्र में जा सकते हैं। अधिक प्रभाव वाले वर्ग अपना समय खर्च साफ़ दिखने पर भी प्रति-उपयोग ही रहें।

देखे गए व्यवहार के आधार पर समीक्षा ट्रिगर तय करें। प्रॉम्प्ट वॉल्यूम दोगुना हो, जवाब देने वाला समूह बदले, सत्र की अवधि बदले या अस्वीकृति के कारण बदलें, तो फिर गणना करें। किसी दूसरी टीम से कॉपी की गई सीमा लगभग बेकार है, क्योंकि रिकवरी समय और कई लोगों को भेजे जाने का असर क्लिक समय से अधिक अलग होता है।

दायरा बदलने के बाद भी नियंत्रण प्रणाली को साक्ष्य बनाए रखना चाहिए। सत्र की शुरुआत, मंज़ूर पहचान, रद्द करना और हर अलग कॉल लॉग करें। वरना सत्र अनुमति समय तो बचाती है, लेकिन एजेंट ने क्या किया इसकी जाँच के लिए जरूरी ट्रेल हटा देती है। सत्यापित करें कि ऑडिट इतिहास कार्रवाई करने वाले एजेंट पर निर्भर हुए बिना मिटाने या बदलने को उजागर कर सकता है।

Sallyport इसे एक स्थिर सीढ़ी की तरह लागू करता है: लॉक्ड वॉल्ट हर कार्रवाई रोकता है, नए एजेंट प्रोसेस को डिफ़ॉल्ट रूप से एक सत्र निर्णय मिलता है और चुनी हुई कुंजियाँ फिर भी हर उपयोग पर मंज़ूरी माँग सकती हैं। इसके Sessions और Activity जर्नल रन-स्तर और कॉल-स्तर के रिकॉर्ड रखते हैं, इसलिए पुष्टि का दायरा बदलने से अलग-अलग कार्रवाइयाँ गायब नहीं होतीं।

बैठक में यह पूछकर सीमा तय न करें कि क्या परेशान करने वाला लगता है। सात दिनों के प्रॉम्प्ट को समीकरण में डालें, इकाइयाँ दिखती रहने दें और नियमित कॉल को उन कॉल से अलग रखें जिनके तथ्य निर्णय बदलते हैं। निर्णय के साथ कच्ची वर्कशीट रखें, ताकि टीम बाद में धारणाओं पर सवाल कर सके। जब किसी व्यक्ति ने बिना किसी अस्वीकृति के एक ही सीमित अधिकार को दर्जनों बार मंज़ूर किया है, तो एक और वैसा कार्ड उसके विवेक को सुरक्षित नहीं रख रहा। वह उसे खर्च कर रहा है।