लेख
बिना सोचे-समझे Fan-out करना बंद करें: Claude Haiku 5.5 के साथ फोर-लेयर ऑर्केस्ट्रेशन आर्किटेक्चर का प्रैक्टिकल गाइड
Claude Haiku 5.5 तेज़ भी है और किफ़ायती भी, लेकिन सारे टास्क आंख मूंदकर पैरेलल में इसे सौंपने से सिर्फ़ मिसजजमेंट, इवैल्यूएटर बायस और Supply Chain रिस्क ही बढ़ेंगे। यह लेख समझाता है Fable का जजमेंट, Opus का ऑर्केस्ट्रेशन, Sonnet और Haiku का इम्प्लीमेंटेशन, CI वैलिडेशन और Opus के एक्सेप्टेंस पर आधारित लेयर्ड आर्किटेक्चर—और यह भी कि किन टास्क्स के लिए Fan-out वाकई फ़ायदेमंद है।
· 1 मिनट में पढ़ें
Claude Haiku 5.5 को 7 अक्टूबर 2026 को रिलीज़ किया गया। 100,000 tokens तक के prompt के लिए इसकी क़ीमत Sonnet 5.5 के मुक़ाबले बीस गुना कम है, और इसकी लेटेंसी Claude की मौजूदा जनरेशन में सबसे तेज़ है।
इतना सस्ता और तेज़ होने की वजह से मन में यह ख़्याल आना स्वाभाविक है: सारे कोडिंग टास्क्स को छोटे हिस्सों में बांटो, उन्हें कई सारे Haiku इंस्टैंसेस में पैरेलल रन कराओ, और काम ख़त्म।
प्रोटोटाइपिंग के दौरान शायद यह तरीक़ा चल भी जाए। लेकिन किसी प्रोडक्शन इंजीनियरिंग एनवायरनमेंट में यह बहुत जल्द तीन बड़ी समस्याओं में फंस जाता है:
- छोटे मॉडल्स एम्बिग्युटी संभालने के लिए नहीं बने हैं। Haiku 5.5 की ऑफ़िशियल पोज़िशनिंग क्लासिफ़िकेशन, एक्सट्रैक्शन, रूटिंग और subagent जैसे हाई-वॉल्यूम, लो-लेटेंसी टास्क्स के लिए है। जब रिक्वायरमेंट्स में बिज़नेस एम्बिग्युटी हो और पूरे सिस्टम के कॉन्टेक्स्ट की ज़रूरत हो, तो यह अक्सर ऐसा आउटपुट दे देता है जो ऊपर से देखने में पूरा लगता है, पर असल में ग़लत दिशा में अंदाज़ा लगा रहा होता है।
- मॉडल से जवाब चुनने को कहेंगे, तो इवैल्यूएटर बायस आएगा। जब दर्जनों आउटपुट्स किसी बड़े मॉडल को रिव्यू करने के लिए दिए जाते हैं, तो वह उस वर्ज़न को चुनने की तरफ़ झुक जाता है जो "दिखने में साफ़-सुथरा आर्किटेक्चर" लगता है, न कि उसे जिसका लॉजिक और एक्ज़ीक्यूशन वाकई सही हो।
- Worker काउंट बढ़ने के साथ परमिशन्स का रिस्क भी बढ़ता है। अगर पैरेलल subagent को मनमाने पैकेज इंस्टॉल करने या कॉन्फ़िगरेशन बदलने की छूट दी जाए, तो जितने N Worker होंगे, मलेशियस पैकेज अंदर आने के उतने ही N नए रास्ते खुल जाएंगे।
इसलिए मैंने Hierarchical Orchestration (लेयर्ड ऑर्केस्ट्रेशन) का रुख़ किया: हर लेयर सिर्फ़ वही काम करती है जिसमें वह माहिर है, और Haiku की पैरेलल क्षमता का इस्तेमाल सिर्फ़ वहीं होता है जहां इसकी सचमुच ज़रूरत हो।
सीधा निष्कर्ष यह है: Fable गहराई से सोचने का ज़िम्मा संभालता है, Opus डिस्पैच और एक्सेप्टेंस देखता है, Sonnet मुख्य इम्प्लीमेंटेशन करता है, और Haiku सिर्फ़ मिकैनिकल टास्क्स तथा ऑटो-वैलिडेट होने वाले सर्च-बेस्ड टास्क्स संभालता है। हर कैंडिडेट सॉल्यूशन पहले CI पास करेगा, उसके बाद ही मॉडल उसे देखेगा।
फोर-लेयर आर्किटेक्चर: जजमेंट, ऑर्केस्ट्रेशन, वैलिडेशन, एक्सेप्टेंस#
रिक्वायरमेंट इनपुट
│
▼
[जजमेंट लेयर] Fable: आर्किटेक्चरल डिसीजन्स, टास्क ब्रेकडाउन, एक्सेप्टेंस क्राइटेरिया
│
▼
[ऑर्केस्ट्रेशन लेयर] Opus Main Session: सिर्फ़ डिस्पैच, कोई दोबारा ब्रेकडाउन नहीं
├─► पाथ A: कॉम्प्लेक्स लेकिन साफ़ बाउंड्री ──► Sonnet इम्प्लीमेंटेशन
├─► पाथ B: मिकैनिकल टास्क ──► सिंगल Haiku
├─► पाथ C: सर्च-बेस्ड, मल्टीपल सॉल्यूशन्स ──► मल्टीपल Haiku, हर एक का अपना Git Worktree
│
▼
[वैलिडेशन लेयर] Build, Type Check, Test, Benchmark (पाथ C से सिर्फ़ टॉप 2–3)
│
▼
[एक्सेप्टेंस लेयर] Opus एक्सेप्टेंस क्राइटेरिया के आधार पर कन्वर्ज करता है
फ़ेल होने पर एस्केलेशन: Haiku 2 बार फ़िक्स करने पर भी फ़ेल ➔ Sonnet ➔ Opus पर वापस
हर मॉडल को किस लेयर में रखना है, यह उसकी ऑफ़िशियल पोज़िशनिंग और क़ीमत के आधार पर तय किया गया है। नीचे 8 अक्टूबर 2026 के Anthropic ऑफ़िशियल डॉक्युमेंटेशन के आंकड़े दिए गए हैं, जहां क़ीमत प्रति मिलियन tokens डॉलर में है:
| मॉडल |
ऑफ़िशियल पोज़िशनिंग |
लेटेंसी |
Input / Output क़ीमत |
| Claude Fable 5.1 |
हाई-डिफ़िकल्टी रीज़निंग और लंबे समय तक चलने वाले agentic टास्क्स |
धीमी |
$10 / $50 |
| Claude Opus 5.5 |
लंबे समय तक चलने वाली agentic कोडिंग और नॉलेज वर्क |
मध्यम |
$4 / $20 |
| Claude Sonnet 5.5 |
स्पीड और कैपेबिलिटी का बेहतरीन संतुलन |
तेज़ |
$2 / $10 |
| Claude Haiku 5.5 |
हाई-वॉल्यूम, लो-लेटेंसी क्लासिफ़िकेशन, एक्सट्रैक्शन, रूटिंग और subagent टास्क्स |
सबसे तेज़ |
$0.10 / $0.50 से शुरू |
Haiku 5.5 की प्राइसिंग दो टियर में बंटी है: prompt जब 100,000 tokens से ज़्यादा का होता है, तो यह $0.50 / $2.50 हो जाती है।
जजमेंट लेयर: Fable आर्किटेक्चरल डिसीजन्स और एक्सेप्टेंस क्राइटेरिया संभालता है#
हर रिक्वायरमेंट को Fable की ज़रूरत नहीं होती। यह सबसे महंगी और सबसे धीमी लेयर है, इसलिए मैं इसे सिर्फ़ तभी इस्तेमाल करता हूं जब रिक्वायरमेंट्स में एम्बिग्युटी हो, क्रॉस-सिस्टम इंटीग्रेशन शामिल हो, या कोर आर्किटेक्चरल डिसीजन्स लेने हों।
Fable को तीन चीज़ें डिलीवर करनी होती हैं:
- सॉल्यूशन डिज़ाइन
- टास्क ब्रेकडाउन
- हर सब-टास्क के लिए ऐसे Acceptance Criteria जिन्हें टेस्ट्स के ज़रिए वैलिडेट किया जा सके
रीज़निंग और टास्क ब्रेकडाउन एक ही लेयर में होना ज़रूरी है। जो लेयर सिस्टम के ब्लाइंड स्पॉट्स को गहराई से समझ सकती है, वही साफ़ बाउंड्रीज़ वाले सब-टास्क्स काट सकती है; अगर आर्किटेक्चर A को सौंपा और ब्रेकडाउन B को, तो इंटरफ़ेस डेफिनिशन अक्सर कमज़ोर पड़ जाती है।
सिक्योरिटी टास्क्स इसका अपवाद हैं। इस जनरेशन के Claude मॉडल्स में सेफ़्टी क्लासिफ़ायर लगे हैं, और जब कोई रिक्वेस्ट ब्लॉक होती है तो वह stop_reason: "refusal" रिटर्न करती है—जिससे सही सिक्योरिटी वर्क भी कभी-कभार ग़लती से ब्लॉक हो सकता है। Fable 5.1 का क्लासिफ़ायर ज़्यादातर सिक्योरिटी कंटेंट को फ़िल्टर कर देता है, और आधिकारिक तौर पर भी इसे सिक्योरिटी डोमेन के लिए डिज़ाइन नहीं किया गया है; वहीं Opus 5.5 सोर्स कोड में वल्नरेबिलिटीज़ खोजने की इजाज़त देता है। इसलिए सिक्योरिटी वल्नरेबिलिटी फ़िक्सेस जैसी ज़रूरतों के शुरुआती एनालिसिस के लिए मैं सीधे Opus का इस्तेमाल करता हूं।
ऑर्केस्ट्रेशन लेयर: Opus सिर्फ़ डिस्पैच करता है, दोबारा ब्रेकडाउन नहीं#
Opus एक Main Session की तरह काम करता है, जो रूटिंग और वर्क एलोकेशन के लिए ज़िम्मेदार है। यह लेयर आर्किटेक्चर को दोबारा ओवररूल नहीं करती, न ही दूसरा ब्रेकडाउन करती है।
- पाथ A, कॉम्प्लेक्स लेकिन साफ़ बाउंड्रीज़: जिन टास्क्स का लॉजिक तो जटिल है पर इंटरफ़ेस बाउंड्रीज़ साफ़-साफ़ तय हैं, उन्हें Sonnet को सौंपा जाता है। इम्प्लीमेंटेशन का मुख्य वर्कहॉर्स यही है।
- पाथ B, सीधे-सादे मिकैनिकल टास्क्स: Boilerplate कोड, वैरिएबल्स का नाम बदलना, बेसिक यूनिट टेस्ट्स जोड़ना, या डॉक्युमेंटेशन अपडेट करना—इन्हें संभालने के लिए एक सिंगल Haiku काफ़ी है।
- पाथ C, सर्च-बेस्ड और ऑप्टिमाइज़ेशन टास्क्स: परफ़ॉर्मेंस ट्यूनिंग, जटिल SQL या Regex के अलग-अलग तरीक़े आज़माना, Flaky Test की डिबगिंग—सिर्फ़ यहीं Fan-out शुरू किया जाता है: कई Haiku इंस्टैंसेस डिप्लॉय किए जाते हैं, और हर कोई अपने अलग Git Worktree में अलग-अलग सॉल्यूशन्स एक्सप्लोर करता है।
चाहे रास्ता कोई भी चुना जाए, हर आउटपुट को वैलिडेशन लेयर से गुज़रना ही पड़ता है।
वैलिडेशन लेयर: पहले मशीन, फिर मॉडल#
एक आम तरीक़ा यह है कि पैरेलल में जनरेट हुए सारे कोड को सीधे Opus या Sonnet के सामने रख दिया जाए और prompt के ज़रिए उसका रिव्यू कराया जाए।
दिक्कत यह है कि कोड पढ़ते समय मॉडल अक्सर साफ़-सुथरे फ़ॉर्मैटिंग और प्रॉपर टाइप डेफिनिशन्स वाले जवाबों से प्रभावित हो जाता है, भले ही उस कोड ने एज-केस टेस्ट्स पास न किए हों। इसलिए हर कैंडिडेट सॉल्यूशन को पहले मशीनी जांच से गुज़रना होगा:
- Build और Type Check: कोड कंपाइल होना चाहिए और टाइप्स सही होने चाहिए
- Unit / Integration Tests: यूनिट टेस्ट्स और इंटीग्रेशन टेस्ट्स पास होने चाहिए
- Benchmark / Profiling: परफ़ॉर्मेंस और मेमोरी का सही मेज़रमेंट होना चाहिए
जो ऑटोमेटेड टेस्ट्स फ़ेल कर दे, वह तुरंत बाहर। पाथ C के कैंडिडेट्स में से Opus सिर्फ़ उन्हीं टॉप 2–3 को देखता है जो सारे चेक पास कर चुके हों और जिनके मेट्रिक्स सबसे अच्छे हों—इससे context window और token दोनों की बचत होती है।
एक्सेप्टेंस लेयर: Opus कन्वर्ज करता है, फ़ेल होने पर एस्केलेट करता है#
अंत में Opus, जजमेंट लेयर द्वारा तय किए गए एक्सेप्टेंस क्राइटेरिया के आधार पर फ़ाइनल आउटपुट पर कन्वर्ज करता है। जब कोई Worker अटक जाता है, तो एक तय Escalation Path के तहत मामला ऊपर भेजा जाता है:
- अगर Haiku फ़ेल होता है, और 2 बार ऑटो-फ़िक्स के बाद भी पास नहीं होता, तो री-ट्राई बंद कर दिया जाता है।
- इसके बाद Sonnet रिपेयर का काम अपने हाथ में लेता है।
- अगर Sonnet भी एक्सेप्टेंस पास नहीं कर पाता, तो इसका सीधा मतलब है कि टास्क ब्रेकडाउन या शुरुआती मान्यताओं में कोई विरोधाभास है। टास्क Opus को लौटा दिया जाता है, और Opus तय करता है कि इसे दोबारा ब्रेकडाउन के लिए Fable के पास भेजना है या नहीं।
प्रोडक्शन में लागू करने के तीन नियम#
बिना सोचे-समझे Fan-out न करें#
आसान टास्क्स के लिए मल्टीपल Workers की ज़रूरत नहीं होती, और अत्यधिक एम्बिग्युटी वाले टास्क्स को छोटा मॉडल संभाल नहीं पाता। सिर्फ़ वही सर्च-बेस्ड टास्क्स जहां "सॉल्यूशन स्पेस बहुत बड़ा हो" और जिन्हें "ऑटोमेटेड टेस्ट्स से तुरंत वैलिडेट किया जा सके", कई Haiku इंस्टैंसेस को पैरेलल चलाने लायक़ होते हैं।
एनवायरनमेंट आइसोलेट करें, Lockfile लॉक रखें#
Git Worktree कोड के बदलावों को आइसोलेट करता है ताकि पैरेलल Workers एक-दूसरे की फ़ाइलों को ओवरराइट न करें; यह नेटवर्क पर कोई पाबंदी नहीं लगाता और न ही कोड के एक्सेस स्कोप को सीमित करता है। Supply Chain Attack से बचने के लिए sandbox की ज़रूरत होती है, और Workers को बिना रिव्यू किए पैकेज इंस्टॉल करने या Lockfile मॉडिफ़ाई करने की सख़्त मनाही होनी चाहिए। इंस्टॉलेशन की खुली छूट देने का मतलब है Agent को कोडबेस में अनजान पैकेज और स्क्रिप्ट्स लाने का खुला न्योता देना।
मेट्रिक्स से एक्सेप्ट करें, मॉडल के रिव्यूज से नहीं#
टेस्ट रिज़ल्ट्स, कवरेज, मेमोरी यूसेज और लेटेंसी—यही वो डेटा हैं जिन्हें रीप्रोड्यूस और कंपेयर किया जा सकता है। मॉडल का टेक्स्ट फ़ीडबैक संदर्भ के लिए ठीक है, लेकिन कोड क्वालिटी के एक्सेप्टेंस का पैमाना वह नहीं हो सकता।
सस्ते मॉडल का सही जगह इस्तेमाल करें#
Haiku 5.5 ने पैरेललिज़्म को किफ़ायती बना दिया है, लेकिन पैरेलल रन कराने भर से रिज़ल्ट्स सही नहीं हो जाते। पहले जजमेंट, डिस्पैच, वैलिडेशन और एक्सेप्टेंस को अलग करें; तभी सस्ता और तेज़ होना एक असली एडवांटेज बन पाएगा।
यह लेयर्ड अप्रोच असल में वही Graph है जिसकी बात मैंने AI Agents असल में एक पूरी Agile टीम हैं में की थी: पहले काम कौन करेगा, ख़त्म होने पर किसे सौंपेगा, और गड़बड़ होने पर किसे एस्केलेट करेगा।