నా Agent Orchestrator ప్రతి టాస్క్కు 1-2 మిలియన్ Opus టోకెన్లను ఖర్చు చేసింది.
ఖర్చు ఎలా పెరిగిపోయింది
ఈ orchestrator Claude Code కోసం రూపొందించబడింది మరియు ఇది sub-agents యొక్క క్రమానుగత శ్రేణిని (hierarchy) ఉపయోగించింది. ప్రతి sub-agent పేరెంట్ సెట్టింగ్లను పొందుతుంది, దాని స్వంత ప్రాంప్ట్ను రన్ చేస్తుంది మరియు రివ్యూయర్ అవుట్పుట్ను “clean” అని ప్రకటించే వరకు ఫలితాన్ని తిరిగి లూప్లోకి పంపిస్తుంది. ఈ టూల్ టాస్క్లను పూర్తి చేసింది, కానీ దాని ధర మాత్రం ఆకాశాన్ని తాకింది.
మూడు దాగి ఉన్న “taxes” టోకెన్ల సంఖ్యను పెంచాయి:
- Model tax – sub-agents ఎప్పుడూ మోడల్ను పేర్కొనలేదు, కాబట్టి అవి అత్యంత ఖరీదైన Opus మోడల్ను డిఫాల్ట్గా ఎంచుకున్నాయి. తక్కువ ఖరీదైన మోడల్లో (Haiku లేదా Sonnet) చేయగలిగే చిన్న పని కూడా Opus రేట్లకే బిల్లు చేయబడింది.
- Cache tax – Prompt caching అనేది ఖచ్చితమైన byte-for-byte మ్యాచ్లను మాత్రమే మళ్ళీ ఉపయోగిస్తుంది. ప్రతి sub-agent స్వంత కస్టమ్ ఇన్స్ట్రక్షన్లను జోడించడం వల్ల, ప్రతి కాల్ ఒక కొత్త (cold cache) రైట్ను ప్రేరేపించింది. పేరెంట్ యొక్క క్యాచీని మళ్ళీ ఉపయోగించలేకముచ్చింది, దీనివల్ల షేర్డ్ క్యాష్ సాధారణంగా ఇచ్చే ఆదా వృధా అయింది.
- Loop tax – “loop until clean” అనే నియమం వల్ల, రివ్యూయర్కు ఏదైనా లోపం కనిపించినంత కాలం ప్రక్రియ కొనసాగుతూనే ఉంది. ఎటువంటి గరిష్ట పరిమితి (hard ceiling) లేకపోవడంతో, మోడల్ ఆగిపోయే వరకు లూప్ నడుస్తూనే ఉంది.
ఇవన్నీ కలిసి, కొన్ని లైన్ల కోడ్ను టోకెన్ల వరదగా మార్చేశాయి.
ప్రాంప్ట్లోని బడ్జెట్ రూల్ ఎందుకు విఫలమైంది
అసలు డిజైన్ సిస్టమ్ ప్రాంప్ట్లోనే బడ్జెట్ రూల్ను పొందుపరచడం ద్వారా ఖర్చును తగ్గించడానికి ప్రయత్నించింది. సిద్ధాంతపరంగా, మోడల్కు “X టోకెన్ల కంటే తక్కువ ఉండండి” అని చెప్పడం వల్ల వినియోగం పరిమితం కావాలి. కానీ వాస్తవంలో, ప్రాంప్ట్ ఆధారిత నియమం అనేది కేవలం ఒక ప్రాధాన్యత (preference) మాత్రమే. సెషన్ పెరిగేకొద్దీ, మోడల్ కాంటెక్స్ట్ను కంప్రెస్ చేస్తుంది మరియు ఆ సూచనలను పూర్తిగా వదిలేయవచ్చు లేదా విస్మరించవచ్చు. ఫలితం: ఆ నియమం అసలు లేనట్లే మోడల్ ప్రవర్తించింది.
నియంత్రణను ప్రాంప్ట్ నుండి కోడ్కు మార్చడం
రీడిజైన్ ద్వారా బడ్జెట్ లాజిక్ను ప్రాంప్ట్ నుండి తొలగించి, మోడల్ ఓవర్రైడ్ చేయలేని ఒక డిటర్మినిస్టిక్ (deterministic) హుక్ సిస్టమ్లో ఉంచాము.
- Explicit model selection – ప్రతి sub-agent డిస్పాచ్ ఇప్పుడు ఒక నిర్దిష్ట మోడల్ ఎంపికను (Haiku, Sonnet, లేదా Opus) కోరుతుంది. సైలెంట్ ఇన్హెరిటెన్స్ (Silent inheritance) ఇప్పుడు లేదు, కాబట్టి తక్కువ ఖర్చుతో కూడిన పనులు తక్కువ ఖర్చుతోనే పూర్తవుతాయి.
- Hard guards via a PreToolUse hook – ఏదైనా టూల్ రన్ కావడానికి ముందు, హుక్ ఈ క్రింది వాటిని తనిఖీ చేస్తుంది:
- సెషన్లో ఇప్పటికే ఎన్ని డిస్పాచ్లు జరిగాయో.
- ఎంచుకున్న మోడల్ కనీస స్థాయిని (minimum tier) చేరుకుంటుందో లేదో (అనుకోకుండా Opus వాడకుండా నిరోధించడానికి).
- లూప్ ఇటరేషన్ల గరిష్ట సంఖ్య, దీని తర్వాత ప్రక్రియ నిలిపివేయబడుతుంది (abort).
ఏదైనా గార్డ్ (guard) నియమాన్ని ఉల్లంఘిస్తే, కోడ్ sub-agentను నిలిపివేస్తుంది; లాంగ్వేజ్ మోడల్ దానిని తిరిగి అమలు చేయడానికి ఎటువంటి మార్గం ఉండదు.
డెవలపర్లకు దీని అర్థం ఏమిటి
ఖర్చు పరిమితులు (spend caps), భద్రతా విధానాలు లేదా విధ్వంసకర కమాండ్లపై (destructive commands) పరిమితులను విధించే ఏ వ్యవస్థ అయినా, ఆ నియంత్రణలను సంభాషణ మార్గదర్శకాలుగా (conversational guidance) కాకుండా కోడ్గా పరిగణించాలి. ప్రాంప్ట్ను ఓవర్రైట్ చేయవచ్చు, విస్మరించవచ్చు లేదా మోడల్ యొక్క అంతర్గత కంప్రెషన్లో కోల్పోవచ్చు. మరోవైపు, కోడ్ డిటర్మినిస్టిక్గా అమలు చేయబడుతుంది మరియు దానిని ఆడిట్ చేయవచ్చు.