माझ्या Agent Orchestrator ने प्रत्येक कामासाठी १-२ दशलक्ष Opus tokens खर्च केले.

खर्च कसा प्रचंड वाढला

हा orchestrator Claude Code साठी बनवला होता आणि त्यात sub-agents ची एक श्रेणी (hierarchy) वापरली होती. प्रत्येक sub-agent ला मूळ (parent) सेटिंग्स वारसाहक्काने मिळत होत्या, तो स्वतःचा prompt चालवत असे आणि जोपर्यंत रिव्ह्यूअरने आउटपुट "clean" घोषित केले नाही, तोपर्यंत निकाल पुन्हा लूपमध्ये पाठवत असे. या टूलने कामे पूर्ण केली, पण त्याची किंमत मात्र अवाढव्य होती.

तीन लपलेले "taxes" टोकनची संख्या अनेक पटींनी वाढवत होते:

  • Model tax – sub-agents ने कधीही मॉडेल नमूद केले नव्हते, त्यामुळे ते डिफॉल्टनुसार सर्वात महागड्या Opus टियरवर चालत होते. एखादे छोटे काम जे स्वस्त मॉडेलवर (Haiku किंवा Sonnet) सहज होऊ शकले असते, त्याचे बिल मात्र Opus च्या दराने आकारले जात होते.
  • Cache tax – Prompt caching फक्त तंतोतंत (byte-for-byte) जुळणाऱ्या गोष्टींचा पुनर्वापर करते. प्रत्येक sub-agent ने स्वतःच्या सूचना (custom instructions) जोडल्यामुळे, प्रत्येक कॉलमध्ये नवीन 'cold cache write' करणे भाग पडत होते. मूळ (parent) कॅशेचा पुनर्वापर करता येत नव्हता, ज्यामुळे शेअर कॅशेमुळे मिळणारी बचत वाया जात होती.
  • Loop tax – "जोपर्यंत स्वच्छ (clean) नाही तोपर्यंत लूप" या नियमामुळे जोपर्यंत रिव्ह्यूअरला काही त्रुटी सापडत असे, तोपर्यंत ही प्रक्रिया सुरू राहत असे. कोणतीही मर्यादा (hard ceiling) नसल्यामुळे, मॉडेल थांबेपर्यंत हा लूप चालूच राहत असे.

एकत्रितपणे, या मल्टिप्लायर्सनी कोडच्या काही ओळींचे रूपांतर टोकनच्या महापुरात (avalanche) केले.

प्रॉम्प्टमधील बजेट नियम का अपयशी ठरला

मूळ डिझाइनमध्ये सिस्टम प्रॉम्प्टमध्ये थेट बजेट नियम समाविष्ट करून खर्च कमी करण्याचा प्रयत्न केला होता. सिद्धांतानुसार, मॉडेलला "X टोकनच्या मर्यादेत राहा" असे सांगितल्यास वापर मर्यादित व्हायला हवा होता. पण प्रत्यक्षात, प्रॉम्प्टवर आधारित नियम हा केवळ एक 'पसंतीचा' (preference) भाग असतो. जसा सेशन वाढतो, तसे मॉडेल कॉन्टेक्स्ट कॉम्प्रेस करते आणि त्या सूचना पूर्णपणे सोडू शकते किंवा दुर्लक्षित करू शकते. परिणामी: मॉडेलने असे वागले जणू तो नियम कधी अस्तित्वातच नव्हता.

अंमलबजावणी प्रॉम्प्टकडून कोडकडे वळवणे

नवीन डिझाइनमध्ये बजेट लॉजिक प्रॉम्प्टमधून काढून टाकण्यात आले आणि ते एका deterministic hook system मध्ये ठेवण्यात आले, ज्याला मॉडेल ओव्हरराइड (override) करू शकत नाही.

  1. Explicit model selection – आता प्रत्येक sub-agent dispatch साठी मॉडेलची स्पष्ट निवड (Haiku, Sonnet, किंवा Opus) करणे आवश्यक आहे. 'Silent inheritance' आता संपले आहे, त्यामुळे स्वस्त कामे स्वस्तच राहतील.
  2. PreToolUse hook द्वारे कडक निर्बंध (Hard guards) – कोणतेही टूल चालण्यापूर्वी, हुक खालील गोष्टी तपासतो:
    • सेशनमध्ये आतापर्यंत किती वेळा dispatch झाले आहेत.
    • निवडलेले मॉडेल किमान टियरचे (minimum tier) आहे की नाही (चुकीच्या पद्धतीने Opus वापरणे टाळण्यासाठी).
    • लूप इटरेशनची कमाल संख्या, ज्यानंतर प्रक्रिया थांबवली जाते.

जर कोणताही निर्बंध (guard) लागू झाला, तर कोड sub-agent ची प्रक्रिया थांबवतो; लँग्वेज मॉडेलकडे पुन्हा त्यात शिरण्यासाठी कोणताही मार्ग नसतो.

डेव्हलपर्ससाठी याचा अर्थ काय

खर्च मर्यादा (spend caps), सुरक्षा धोरणे (security policies) किंवा विनाशकारी कमांड्सवर (destructive commands) निर्बंध लादणारी कोणतीही प्रणाली या मर्यादांना 'कोड' म्हणून मानली पाहिजे, केवळ संवादात्मक मार्गदर्शनाप्रमाणे (conversational guidance) नाही. प्रॉम्प्ट ओव्हरराईट केला जाऊ शकतो, दुर्लक्षित केला जाऊ शकतो किंवा मॉडेलच्या अंतर्गत कॉम्प्रेशनमध्ये हरवू शकतो. याउलट, कोड 'deterministically' कार्यान्वित होतो आणि त्याचे ऑडिटही करता येते.