एक Orchestrator, तीन CLIs: क्या Codex और Gemini को सौंपने से वास्तव में आपके Claude टोकन बच सकते हैं?

2026 में बहुत सारे डेवलपर्स की तरह, मेरे पास भी एक ही मशीन पर तीन AI कोडिंग CLIs इंस्टॉल हो गए हैं, और हर एक ने एक अलग कारण से अपनी जगह बनाई है:

• Claude Code — ऑर्केस्ट्रेटर-ग्रेड एजेंट। मल्टी-स्टेप रीज़निंग, आर्किटेक्चर, डिबगिंग और एक बड़े कोडबेस पर काम करने में सर्वश्रेष्ठ। यह वह भी है जिसके टोकन की मुझे सबसे ज्यादा परवाह है।
• OpenAI Codex CLI — एक सक्षम कोडिंग एजेंट जो बहुत बढ़िया है जब आप इसे एक सटीक स्पेक के साथ अच्छी तरह से स्कोप्ड, आत्मनिर्भर कार्य सौंपते हैं।
• Google Gemini CLI — मल्टीमॉडल वर्कहॉर्स। इमेज जनरेशन, ऑडियो और TTS, ट्रांसक्रिप्शन, और उच्च गुणवत्ता वाला अनुवाद, विशेष रूप से क्षेत्रीय भाषाओं के लिए।

किसी बिंदु पर एक स्पष्ट प्रश्न आता है: तीनों में से सबसे चतुर पूरे दिन चलाने के लिए सबसे महंगा भी है। तो क्या मैं इसे बना सकता हूँ मैनेजर? Claude को एक काम दें, उससे काम को बंटवाएं, टुकड़े Codex और Gemini को सौंपें, और काम पूरा होने पर उन्हें एक मार्कडाउन फ़ाइल के साथ रिपोर्ट करने दें — जबकि Claude टोकन केवल कठिन हिस्सों और अंतिम समीक्षा पर खर्च करता है?

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

संक्षिप्त उत्तर: हाँ, पैटर्न काम करता है, और बचत वास्तविक है — लेकिन केवल तभी जब आप हैंडऑफ़ को ठीक से इंजीनियर करते हैं। लंबा उत्तर नीचे सब कुछ है।

सबसे पहले, समझें कि आप वास्तव में किस चीज़ के लिए भुगतान कर रहे हैं

इससे पहले कि कोई रणनीति समझ में आए, आपको इस बात की स्पष्ट तस्वीर चाहिए कि एक एजेंटिक CLI सत्र में टोकन कहाँ जाते हैं। मोटे तौर पर चार बाल्टियाँ:

1. इनपुट टोकन — वह सब कुछ जो मॉडल पढ़ता है: आपका प्रॉम्ट, फ़ाइल सामग्री, टूल आउटपुट, पूर्व वार्तालाप। एक लंबे कोडिंग सत्र में यह बाकी सब कुछ को बौना कर देता है, क्योंकि एजेंट हर मोड़ पर संदर्भ को फिर से पढ़ता है।
2. आउटपुट टोकन — वह सब कुछ जो मॉडल लिखता है: कोड, गद्य, टूल कॉल। आमतौर पर इनपुट की तुलना में उच्च दर पर बिल किया जाता है।
3. री-रीड्स — साइलेंट किलर। हर बार जब कोई एजेंट "सिर्फ कुछ जांचने के लिए" 1,000-लाइन वाली फ़ाइल खोलता है, तो आप इनपुट के रूप में उन 1,000 लाइनों के लिए फिर से भुगतान करते हैं।
4. पुनर्कार्य — कंपाउंडिंग किलर। एक गलत समझा गया कार्य आपको पहले प्रयास, उसे पकड़ने वाली समीक्षा, और दूसरे प्रयास की कीमत चुकाता है।

प्रत्यायोजन बाल्टी 1 और 2 पर हमला करता है: सब-एजेंट की पीढ़ी होती है उसके बिल (एक अलग सदस्यता, एक सस्ता मॉडल, या एक निःशुल्क टियर) पर, और ऑर्केस्ट्रेटर केवल एक कॉम्पैक्ट सारांश पढ़ता है। लेकिन बुरी तरह से किया गया प्रत्यायोजन बढ़ा देता है बाल्टी 3 और 4 को — और यही इस लेख का पूरा तनाव है।

ऑर्केस्ट्रेटर पैटर्न, ठीक से परिभाषित

यहाँ वास्तुकला अपने सरलतम रूप में है:

            ┌─────────────────────────┐
            │   YOU (one instruction)  │
            └───────────┬─────────────┘
                        ▼
            ┌─────────────────────────┐
            │  CLAUDE (orchestrator)   │
            │  plans · splits · specs  │
            │  reviews · integrates    │
            └─────┬──────────────┬────┘
        spec + exact output path │
              ▼                  ▼
   ┌─────────────────┐  ┌─────────────────┐
   │  CODEX (coder)   │  │ GEMINI (media)   │
   │ scoped modules,  │  │ images, audio,   │
   │ tests, boiler-   │  │ translation      │
   │ plate, scripts   │  │                  │
   └────────┬────────┘  └────────┬────────┘
            │  artifacts → disk   │
            │  report.md (≤40 ln) │
            ▼                     ▼
            ┌─────────────────────────┐
            │  CLAUDE reads reports,   │
            │  verifies, fixes/retries │
            │  or integrates & ships   │
            └─────────────────────────┘

ऑर्केस्ट्रेटर के पास चार चीजें होती हैं और केवल चार चीजें: योजना, स्पेक्स, समीक्षा, और एकीकरण। भारी और यांत्रिक सब कुछ दो गैर-परक्राम्य नियमों के साथ नीचे धकेल दिया जाता है:

नियम 1 — आर्टिफैक्ट एक सटीक पथ पर डिस्क पर जाते हैं। सब-एजेंट कभी भी अपने आउटपुट को बातचीत में पेस्ट नहीं करता है। यह फ़ाइलें लिखता है। ऑर्केस्ट्रेटर का संदर्भ साफ़ रहता है।

नियम 2 — उत्तर लगभग कुछ नहीं होता है। आदर्श रूप से एक शब्द और एक छोटी मार्कडाउन रिपोर्ट। रिपोर्ट ही वह एकमात्र चीज़ है जिसे ऑर्केस्ट्रेटर द्वारा पढ़ने की गारंटी होती है।

यदि आपको इस लेख से और कुछ याद नहीं है: प्रत्यायोजन प्रॉम्ट और रिपोर्ट केवल दो स्थान हैं जहां ऑर्केस्ट्रेटर किसी सौंपे गए कार्य पर टोकन खर्च करता है। बाकी सब किसी और का बिल है। आपकी संपूर्ण अनुकूलन सतह वे दो दस्तावेज़ हैं।

वॉकथ्रू #1: Gemini को इमेज जनरेशन सौंपना

यह मेरे द्वारा चलाया जाने वाला उच्चतम-मूल्य का प्रत्यायोजन है, क्योंकि ऑर्केस्ट्रेटर सचमुच इसे नहीं कर सकता — Claude Code के पीछे कोई छवि मॉडल नहीं है। यहाँ उस प्रॉम्ट का वास्तविक आकार है जो Claude लिखता है और Gemini CLI पर फायर करता है:

Generate a single photorealistic editorial corporate portrait.
Concept: <detailed art direction — subject, pose, wardrobe,
lighting, background, composition>.

CRITICAL: the entire subject must be fully inside the frame with
generous margin on all sides — do not crop arms or held objects.
Plain seamless light-grey studio background for easy cutout.
No text, no watermark, no logos, no props.

Save the image to /tmp/work/hero-cyber.png (overwrite if it exists).
Then reply only DONE.

इस प्रॉम्ट में इंजीनियरिंग पर ध्यान दें:

• आउटपुट पथ सटीक है। कोई "इसे कहीं सहेजें" नहीं — ऑर्केस्ट्रेटर ठीक-ठीक जानता है कि कहाँ देखना है, इसलिए शून्य आगे-पीछे होता है।
• "केवल DONE उत्तर दें।" Gemini CLI 400 टोकन के लिए अपनी रचनात्मक प्रक्रिया खुशी-खुशी सुनाएगा। हम यह नहीं चाहते हैं। एक शब्द।
• बाधाओं को यंत्रवत् रूप से बताया गया है ("पूरी तरह से फ्रेम के अंदर," "कोई वॉटरमार्क नहीं") क्योंकि हर बाधा जो आप नहीं लिखते हैं वह एक रिवर्क रूलेट स्पिन है। मैंने उन पंक्तियों में से प्रत्येक को एक विफलता से सीखा — उस पर नीचे और अधिक।

फिर ऑर्केस्ट्रेटर एक गुणवत्ता द्वार चलाता है, इससे पहले कि वह छवि को कभी देखे — एक सस्ता, यांत्रिक चेक:

# does the file exist and is it non-trivial?
test -s /tmp/work/hero-cyber.png || echo "FAILED: missing/empty"

# entropy gate: catches blank/placeholder images without
# spending any model tokens at all
python3 -c "
from PIL import Image; import sys
img = Image.open('/tmp/work/hero-cyber.png')
# a flat placeholder has near-zero entropy; a real photo is > 4
print(img.entropy())
"

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

इन्हें पृष्ठभूमि में चलाएं। छवि कार्यों में एक से पांच मिनट लगते हैं। एक अवरोधक प्रतीक्षा का अर्थ है कि आपका ऑर्केस्ट्रेटर स्मृति में अपना पूरा संदर्भ पकड़े हुए निष्क्रिय बैठा रहता है। नौकरी को फायर करें, अन्य कार्यों के साथ जारी रखें, जब फ़ाइल उतरे तब वापस आएं। हर गंभीर एजेंट CLI अब पृष्ठभूमि का समर्थन करता है; इसका इस्तेमाल करें।

वॉकथ्रू #2: Codex को कोडिंग कार्य सौंपना

कोडिंग प्रत्यायोजन पेचीदा है, क्योंकि विफलता मोड कोई खराब छवि नहीं है जिसे आप एक नज़र में देख सकते हैं — यह प्रशंसनीय दिखने वाला कोड है जो आपके कोडबेस में फिट नहीं होता है। इसका समाधान एक इतना सख्त स्पेक है कि "संपन्न" मशीन-जांच योग्य है:

TASK: Write a standalone Node script at scripts/import-legacy.mjs

SPEC:
- Reads ./data/legacy-export.csv (papaparse is already a dependency)
- Maps columns per the table below … (exact mapping)
- Writes ./data/import-ready.json, an array of objects
- Node 22, ESM, no new dependencies
- Handle: missing fields → skip row + count; duplicate IDs → last wins

ACCEPTANCE (all must pass):
- node scripts/import-legacy.mjs runs clean on the sample file
- node --test tests/import-legacy.test.mjs passes (write these tests)
- npx eslint scripts/import-legacy.mjs → zero errors

REPORT: write REPORT-import.md (max 40 lines) with status, files
created, how to verify, and up to 5 gotchas. Do not paste file
contents into the report.

तीन गुण इसे प्रत्यायोजित करने योग्य बनाते हैं जहां अधिकांश कोडिंग कार्य नहीं होते हैं:

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

जब रिपोर्ट आती है, तो ऑर्केस्ट्रेटर स्वीकृति कमांड (सस्ता) चलाता है, गॉचा (सस्ता) को स्किम करता है, और केवल तभी वास्तविक कोड खोलता है जब कुछ विफल रहता है या गलत गंध आती है। एक साफ पास पर, ऑर्केस्ट्रेटर कभी भी उन 300 लाइनों को नहीं पढ़ता है जो उसने अन्यथा लिखी होतीं — यही बचत है।

जहाँ बचत वास्तविक है — मोटे गणित के साथ

1. थोक उत्पादन। मान लें कि एक कार्य 2,000 लाइनों का आउटपुट (~25k टोकन) उत्पन्न करता है। सीधे किए जाने पर, ऑर्केस्ट्रेटर ~25k आउटपुट टोकन के साथ-साथ इसके आस-पास के सभी संदर्भ-पठन का भुगतान करता है। प्रत्यायोजित किए जाने पर, ऑर्केस्ट्रेटर भुगतान करता है: एक ~300-टोकन स्पेक, एक ~400-टोकन रिपोर्ट पढ़ना, और सत्यापन आदेशों के कुछ सौ टोकन। इसे ~30k के मुकाबले ~1k टोकन मान लें — एक 95%+ कमी उस कार्य पर, सब-एजेंट के कोटे में बिल की गई पीढ़ी के साथ।

2. वह काम जो ऑर्केस्ट्रेटर वैसे भी नहीं कर सकता। प्रत्येक छवि, प्रत्येक ऑडियो फ़ाइल, मेरे द्वारा हाल ही में शिप किए गए आठ-भाषा अनुवाद बैचों में से प्रत्येक को ऑर्केस्ट्रेटर द्वारा लिखे गए स्पेक से Gemini CLI द्वारा उत्पन्न किया गया था। तुलना करने के लिए कोई Claude-मूल विकल्प नहीं है — यह शुद्ध क्षमता लाभ है, और टोकन लागत केवल स्पेक + रिपोर्ट है।

3. सटीक स्पेक के साथ लंबा यांत्रिक आउटपुट। टेस्ट स्कैफोल्डिंग, डेटा माइग्रेशन, बॉयलरप्लेट मॉड्यूल, फ़ॉर्मेट रूपांतरण, एक रूपरेखा से डॉक ड्राफ्ट। सामान्य धागा: कम निर्णय, उच्च मात्रा। वॉल्यूम ठीक वही है जिसकी कीमत आउटपुट टोकन तय करते हैं; निर्णय वह है जिसकी ठीक-ठीक कमी सस्ते एजेंट में होती है। मात्रा सौंपें, निर्णय रखें।

जहाँ बचत गायब हो जाती है — दो कर और एक ओवरहेड

सत्यापन कर

यह वह लागत है जिसकी कीमत कोई नहीं लगाता है, इसलिए मुझे आपको अपनी खुद की परियोजना से रसीदें देने दें — एक वेबसाइट के लिए AI-जनरेटेड हीरो पोर्ट्रेट का एक बैच:

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

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

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

बजट नियम: मान लें कि 20-30% प्रत्यायोजित रचनात्मक कार्यों को एक फिक्स साइकिल की आवश्यकता होती है, और इसे अपने निर्णय में शामिल करें। यदि कार्य को सत्यापित करना सस्ता है (परीक्षण चलाएं, फ़ाइल की जाँच करें), तो प्रत्यायोजन रिवर्क के साथ भी जीत जाता है। यदि सत्यापन का अर्थ है "सब कुछ ध्यान से पढ़ें," तो बचत एक भ्रम थी।

एकीकरण कर

यदि कार्य कई फ़ाइलों को छूता है, आपके कोडबेस की परंपराओं से मेल खाना चाहिए, या ऑर्केस्ट्रेटर के दिमाग में रहने वाले संदर्भ पर निर्भर करता है — वास्तुकला निर्णय, एक क्रॉस-मॉड्यूल रीफैक्टर, एक रेस-कंडीशन डिबग — तो इसे सौंपना एक झूठी अर्थव्यवस्था है। सब-एजेंट के पास आपका संदर्भ नहीं है; ऑर्केस्ट्रेटर इसे सुरक्षित रूप से एकीकृत करने के लिए सब-एजेंट द्वारा छुई गई हर चीज़ को फिर से पढ़ने में समाप्त होता है। आपने एक ही समझ के लिए दो बार भुगतान किया है: एक बार सब-एजेंट के लिए अपनी आंशिक तस्वीर बनाने के लिए, एक बार ऑर्केस्ट्रेटर के लिए पूरी तस्वीर को फिर से बनाने के लिए।

कहना सरल है: यदि स्पेक लिखने के लिए आपकी वास्तुकला को समझाने की आवश्यकता है, तो कार्य न सौंपें। अकेले स्पेक-राइटिंग की लागत बचत से अधिक है, और गलतफहमी का जोखिम बहुत बड़ा है।

ओवरहेड फ्लोर

एक अच्छा प्रत्यायोजन प्रॉम्ट लिखने में 200-400 टोकन खर्च होते हैं। रिपोर्ट पढ़ने में 300-500 का खर्च आता है। सत्यापन, कुछ सौ और। तो एक फ्लोर है: यदि कार्य की प्रत्यक्ष लागत लगभग 1,000-2,000 टोकन (~50-100 लाइनें आउटपुट) के तहत है, तो इसे सौंपने से हर बार पैसा खो जाता है। बस इसे कर दो।

मार्कडाउन रिपोर्ट अनुबंध — जहाँ बचत रहती है या मर जाती है

यह विचार जो इस पैटर्न को अधिकांश लोगों के लिए क्लिक कराता है, वह रिपोर्ट फ़ाइल है: प्रत्येक उप-एजेंट समाप्त होता है और ऑर्केस्ट्रेटर के लिए एक मार्कडाउन सारांश छोड़ता है। यह सही प्रवृत्ति है — और यह भी ठीक वही है जहाँ पूरी योजना चुपचाप विफल हो जाती है। यदि Codex 500-पंक्ति की रिपोर्ट लिखता है और Claude वह सब पढ़ता है, तो आपने वैसे भी भुगतान किया — बस लिखने के बजाय पढ़ने में।

यहाँ एक खराब रिपोर्ट है (यह वही है जो एजेंट उत्पन्न करते हैं यदि आप उन्हें बाध्य नहीं करते हैं):

एक 340-पंक्ति का निबंध: कार्य को पुनः बताता है, हर निर्णय को कालानुक्रमिक रूप से बताता है, "संदर्भ के लिए" इसके द्वारा बनाई गई दो फ़ाइलों की पूरी सामग्री को पेस्ट करता है, इसमें पूरा परीक्षण आउटपुट शामिल होता है, और भविष्य के सुधारों के लिए तीन पैराग्राफ चेतावनियों और सुझावों के साथ बंद होता है।

इसे पढ़ना कोड लिखने से ज्यादा महंगा है। इसके बजाय मैं जिस अनुबंध को लागू करता हूं वह यहां दिया गया है:

# Task: import-legacy script
Status: DONE
Files created:
  - scripts/import-legacy.mjs
  - tests/import-legacy.test.mjs
How to verify:
  - node --test tests/import-legacy.test.mjs
  - node scripts/import-legacy.mjs && head data/import-ready.json
Gotchas:
  - 14 rows in the sample CSV had no email; skipped, count logged
  - CSV dates are DD/MM/YYYY, not ISO — parser handles both

और चार नियम जो हर रिपोर्ट को इस आकार में रखते हैं:

1. हार्ड कैप: 40 लाइनें। इसे प्रत्यायोजन प्रॉम्ट में बताएं। स्थिति, पथ, कमांड सत्यापित करें, गॉचा — और कुछ नहीं।
2. पथ, सामग्री कभी नहीं। आर्टिफैक्ट डिस्क पर रहते हैं; रिपोर्ट उनकी ओर इशारा करती है। ऑर्केस्ट्रेटर फ़ाइल केवल तभी खोलता है जब सत्यापन की मांग होती है — दो बार पढ़ना एक विकल्पबन जाता है, डिफ़ॉल्ट नहीं।
3. शुद्ध पीढ़ी के लिए "केवल DONE उत्तर दें"। जब आर्टिफैक्ट अपने लिए बोलता है (एक छवि, एक ऑडियो फ़ाइल), तो एक रिपोर्ट भी बहुत ज्यादा होती है। फ़ाइल उतरती है, एक शब्द वापस आता है, गेट चलते हैं।
4. हर स्पेक में मशीन-जांच योग्य स्वीकृति मानदंड। "इसे अच्छा बनाएं" रिवर्क पैदा करता है। "सभी परीक्षण पास, शून्य लिंट त्रुटियाँ, आउटपुट 200 KB के तहत 1200×630 JPEG है" एक पास/असफल उत्पन्न करता है जिसे ऑर्केस्ट्रेटर एक कमांड में सत्यापित करता है। आपके स्वीकृति मानदंड की गुणवत्ता ही आपके प्रत्यायोजन की गुणवत्ता है।

श्रम का विभाजन: किसे क्या मिलता है, और क्यों

कार्य	इसे दें	क्यों
छवियां, ऑडियो/TTS, ट्रांसक्रिप्शन	Gemini CLI — हमेशा	आर्केस्ट्रेटर इन्हें बिल्कुल नहीं कर सकता; शुद्ध लाभ
अनुवाद (विशेषकर क्षेत्रीय भाषाएं)	Gemini CLI	मजबूत गुणवत्ता, उच्च मात्रा, सैंपलिंग द्वारा आसानी से सत्यापित करने योग्य
एक सटीक स्पेक के साथ स्व-निहित स्क्रिप्ट/मॉड्यूल	Codex CLI	उच्च मात्रा, कम निर्णय, मशीन-चेक करने योग्य
टेस्ट स्कैफोल्डिंग, माइग्रेशन, बॉयलरप्लेट	Codex CLI	यांत्रिक आउटपुट; स्वीकृति = स्वयं परीक्षण
आर्किटेक्चर & डिज़ाइन निर्णय	Claude — कभी भी डेलिगेट न करें	शुद्ध निर्णय; स्पेक की लागत कार्य से अधिक होगी
मल्टी-फ़ाइल रिफ़ैक्टर्स, एकीकरण कार्य	Claude	इंटीग्रेशन टैक्स डेलिगेशन को एक झूठी अर्थव्यवस्था बनाता है
डिबगिंग	Claude	संचित संदर्भ की आवश्यकता होती है; सब-एजेंट शून्य से शुरू होता है
डेलिगेट की गई हर चीज़ की अंतिम समीक्षा	Claude	यह सचमुच वह काम है जिसके लिए आप प्रीमियम मॉडल को भुगतान कर रहे हैं

एक बारीकी जो बताने लायक है: यह "Claude अच्छा है, अन्य बुरे हैं" नहीं है। यह मात्रा बनाम निर्णय. Codex उत्कृष्ट स्व-निहित कोड लिखता है; Gemini की छवि और अनुवाद गुणवत्ता वास्तविक उत्पादन कार्य को संभालती है। यह विभाजन इस बारे में है कि प्रत्येक सीट की लागत क्या है और प्रत्येक कार्य की आवश्यकता क्या है।

परिचालन प्लेबुक

कुछ आदतें जो बचत को बढ़ाती हैं:

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

आक्रामक रूप से बैच बनाएं। छह वार्तालापों के रूप में छह छवियां, प्रॉम्प्ट+रिपोर्ट ओवरहेड के छह राउंड हैं। एक प्रॉम्प्ट जो नामकरण परंपरा के साथ छह फ़ाइलें बनाता है (hero-01.png … hero-06.png), एक रिपोर्ट, एक समीक्षा पास। अनुवाद के लिए भी यही: एक डेलिगेशन में सभी आठ भाषाएं।

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

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

आर्केस्ट्रेटर के सत्र को साफ़ रखें। लंबे समय तक चलने वाले आर्केस्ट्रेटर सत्र संदर्भ जमा करते हैं, और संदर्भ इनपुट-टोकन किराया है जो आप हर मोड़ पर चुकाते हैं। डेलिगेशन ठीक इसलिए मदद करता है क्योंकि आर्टिफैक्ट वार्तालाप के बजाय डिस्क पर रहते हैं — ऐसा करके इसे पूर्ववत न करें catचैट में फ़ाइलों को "एक नज़र डालने के लिए" डालकर।

जो बाधाएं आपने सीखीं, उन्हें टेम्प्लेट में लिखें। हर रीवर्क आपको एक प्रॉम्प्ट लाइन सिखाता है ("कोई वॉटरमार्क नहीं," "पूरी तरह से फ्रेम के अंदर," "कोई नई निर्भरता नहीं")। टेम्प्लेट वह तरीका है जिससे आप एक ही सबक के लिए दो बार भुगतान करना बंद कर देते हैं।

वास्तव में इसका एक सप्ताह कैसा दिखता है

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

पैटर्न ने महंगे मॉडल को सस्ता नहीं बनाया। इसने मुझे इसे टाइपिस्ट के रूप में उपयोग करना बंद करवा दिया।

फैसला, और एक चेकलिस्ट

क्या रणनीति सही है? अधिकतर, हाँ। जनरेशन-भारी काम के लिए बचत वास्तविक और बड़ी है — यह डेलिगेशन है आउटपुट का, और आउटपुट वही है जिसके लिए आप भुगतान करते हैं। निर्णय-भारी काम के लिए बचत एक भ्रम है — यह डेलिगेशन है समझ का, और समझ हमेशा आर्केस्ट्रेटर के बिल पर वापस आती है, आमतौर पर ब्याज के साथ।

महंगे CLI को एक बेहतरीन, सस्ती टीम के साथ नखरेबाज़ टेक लीड के रूप में समझें: यह स्पेक्स लिखता है, छोटी रिपोर्ट की समीक्षा करता है, और केवल तभी हुड खोलता है যখন कुछ गलत लगता है।

किसी कार्य को डेलिगेट करने से पहले, चेकलिस्ट चलाएँ:

• क्या आउटपुट है बड़ा (>100 लाइनें / >2k टोकन) या ऐसा कुछ जो आर्केस्ट्रेटर बिल्कुल भी उत्पादित नहीं कर सकता?
• क्या मैं स्पेक लिख सकता हूँ अपने आर्किटेक्चर को समझाए बिना?
• क्या "किया गया" मशीन-चेक करने योग्य (परीक्षण, लिंट, फ़ाइल गुण) बजाय इसके कि "इसे ध्यान से पढ़ें"?
• क्या आउटपुट पथ सटीक है, और उत्तर सीमित है DONE + एक ≤40-लाइन रिपोर्ट तक?
• क्या मैंने बजट बनाया है एक फिक्स साइकिल का — और यह तय किया कि यदि यह दो बार विफल होता है तो क्या होगा?

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