मेरे Agent Orchestrator ने प्रति कार्य 1-2 मिलियन Opus टोकन खर्च कर दिए।

लागत कैसे बढ़ती गई

यह orchestrator Claude Code के लिए बनाया गया था और इसमें sub-agents का एक पदानुक्रम (hierarchy) इस्तेमाल किया गया था। प्रत्येक sub-agent पैरेंट की सेटिंग्स को इनहेरिट करता था, अपना स्वयं का प्रॉम्प्ट चलाता था, और परिणाम को तब तक लूप में वापस भेजता रहता था जब तक कि एक रिव्यूअर आउटपुट को "clean" घोषित न कर दे। टूल ने कार्य तो पूरे किए, लेकिन इसकी कीमत बहुत अधिक (astronomical) थी।

तीन छिपे हुए "taxes" ने टोकन की संख्या को कई गुना बढ़ा दिया:

  • Model tax – sub-agents ने कभी भी किसी मॉडल को निर्दिष्ट (specify) नहीं किया, इसलिए वे डिफ़ॉल्ट रूप से सबसे महंगे टियर, Opus पर चले गए। एक छोटा सा ऑपरेशन जो किसी सस्ते मॉडल (Haiku या Sonnet) पर आसानी से हो सकता था, उसका बिल Opus की दरों पर लगाया गया।
  • Cache tax – प्रॉम्प्ट कैशिंग केवल सटीक byte-for-byte मिलान को ही पुन: उपयोग करती है। क्योंकि प्रत्येक sub-agent ने कस्टम निर्देश जोड़े थे, इसलिए हर कॉल ने 'cold cache write' को मजबूर कर दिया। पैरेंट के कैश का पुन: उपयोग नहीं किया जा सका, जिससे एक साझा कैश (shared cache) से होने वाली बचत खत्म हो गई।
  • Loop tax – "loop until clean" नियम ने प्रक्रिया को तब तक जीवित रखा जब तक रिव्यूअर को कोई भी कमी मिलती रही। बिना किसी सख्त सीमा (hard ceiling) के, लूप तब तक चलता रहा जब तक मॉडल रुक नहीं गया।

इन मल्टीप्लायर्स ने मिलकर कोड की कुछ लाइनों को टोकन के सैलाब (avalanche) में बदल दिया।

प्रॉम्प्ट में बजट नियम क्यों विफल रहा

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

प्रवर्तन (enforcement) को प्रॉम्प्ट से कोड में ले जाना

नए डिज़ाइन में बजट लॉजिक को प्रॉम्प्ट से हटाकर एक deterministic hook सिस्टम में डाल दिया गया, जिसे मॉडल ओवरराइड नहीं कर सकता।

  1. Explicit model selection – अब प्रत्येक sub-agent dispatch के लिए एक ठोस मॉडल विकल्प (Haiku, Sonnet, या Opus) आवश्यक है। साइलेंट इनहेरिटेंस (silent inheritance) खत्म हो गया है, इसलिए सस्ते कार्य सस्ते ही रहते हैं।
  2. PreToolUse hook के माध्यम से हार्ड गार्ड्स – किसी भी टूल के चलने से पहले, हुक निम्नलिखित की जाँच करता है:
    • सत्र में अब तक किए गए dispatches की संख्या।
    • क्या चुना गया मॉडल न्यूनतम टियर को पूरा करता है (अनजाने में Opus के उपयोग को रोकने के लिए)।
    • लूप इटरेशन की अधिकतम संख्या, जिसके बाद प्रक्रिया रद्द (abort) हो जाती है।

यदि कोई भी गार्ड ट्रिगर होता है, तो कोड sub-agent को रद्द कर देता है; लैंग्वेज मॉडल के पास वापस आने के लिए बहस करने का कोई तरीका नहीं होता।

डेवलपर्स के लिए इसका क्या अर्थ है

कोई भी सिस्टम जो खर्च की सीमा (spend caps), सुरक्षा नीतियां, या विनाशकारी कमांड (destructive commands) पर सीमाएं लगाता है, उसे उन बाधाओं को कोड के रूप में मानना चाहिए, न कि बातचीत के मार्गदर्शन (conversational guidance) के रूप में। एक प्रॉम्प्ट को ओवरराइट किया जा सकता है, अनदेखा किया जा सकता है, या मॉडल के आंतरिक संपीड़न (internal compression) में खोया जा सकता है। दूसरी ओर, कोड नियतात्मक रूप से (deterministically) निष्पादित होता है और इसका ऑडिट किया जा सकता है।