परिचय: वह सस्ता worker जिसे कोई नहीं बुलाता
Claude Code के subagents तब तक Haiku 5.5 को छोड़ देते हैं, जब तक दो फ़ाइलें कुछ और न कहें। पूरी खोज बस यही है, और इस लेख का बाकी हिस्सा इसी का माप है: एक असली repository पर सात रोज़मर्रा के काम, जिनमें worker की भूमिका बारी-बारी से Haiku 5.5, Sonnet 5.5 और Opus 5.5 ने निभाई, और हर block के बाद plan meter पढ़ा गया।
Haiku 5.5 7 अक्टूबर 2026 को आया। Anthropic ने इसे subagent मॉडल के रूप में पेश किया, और इसकी प्रति token कीमत पुराने Haiku का दसवाँ हिस्सा है। एक account के एक महीने के logs दूसरा पहलू दिखाते हैं: 2,631 subagent runs, जिनमें सिर्फ़ 42 Haiku पर चले, क्योंकि हर subagent main मॉडल ही विरासत में लेता है। हर subagent को Haiku पर कर देने से एक सीधा सवाल उठता है: plan meter असल में कितना वापस देता है? दो फ़ाइलें Explore agent को Haiku पर ले जाती हैं, और जो setting ज़्यादातर लोग सबसे पहले आज़माते हैं, वह अकेले कुछ नहीं करती। usage breakdown panel, जिस पर सब भरोसा करते हैं, binary में बंद चार संख्याओं से निकलता है।
हर मॉडल पर एक काम की कीमत
Haiku 5.5 की कीमत $0.10 प्रति दस लाख input tokens और $0.50 प्रति दस लाख output tokens है, जबकि Haiku 4.5 की कीमत $1 और $5 है। यह कीमत 100,000 tokens तक के prompts पर लागू होती है; उस रेखा के ऊपर पूरा request पाँच गुना महँगा गिना जाता है। Anthropic का "90%" आँकड़ा कोई छूट नहीं है: यह पिछले Haiku के उन requests का हिस्सा है जो उस रेखा के नीचे रहे।
| मॉडल | प्रति 1M tokens input | प्रति 1M tokens output |
|---|---|---|
| Haiku 5.5 (prompt 100k तक) | $0.10 | $0.50 |
| Haiku 5.5 (prompt 100k से ऊपर) | $0.50 | $2.50 |
| Haiku 4.5 | $1.00 | $5.00 |
| Sonnet 5.5 | $2.00 | $10.00 |
| Opus 5.5 | $4.00 | $20.00 |
मैदान से दो और पेच सामने आए। नया tokenizer उसी text को Haiku 4.5 के मुक़ाबले लगभग 30% ज़्यादा tokens गिनता है। और max effort पर एक स्वतंत्र run ने प्रति काम लगभग 162,000 output tokens मापे, जो एक प्रतिद्वंद्वी मॉडल का करीब तीन गुना है। Anthropic की अपनी पंक्ति सावधान है: जटिल agentic coding के लिए Sonnet और Opus बेहतर विकल्प बने रहते हैं। Terminal-Bench 4.0 पर Haiku 5.5 का स्कोर 39.2% है, जबकि Sonnet 5.5 का 70.6%।
यह test उन कामों को कवर करता है जो एक subagent को सच में मिलते हैं। एक असली repository, tinydb, जिसके suite में 226 tests हैं। सात तरह के काम: code को explore करना, फ़ेल होता test ठीक करना, lint errors साफ़ करना, commit message लिखना, एक छोटा feature जोड़ना, एक diff की समीक्षा करना, architecture का सार लिखना। चार workers: medium effort पर Haiku 5.5, low effort पर Haiku 5.5, Sonnet 5.5, Opus 5.5। कुल 182 runs, और हर एक को किसी छिपे test या तय नियम ने जाँचा, कभी आँख से नहीं।
| कॉन्फ़िगरेशन | Runs | स्वीकार | छोटा feature, list price | छोटा feature, wall time |
|---|---|---|---|---|
| Haiku 5.5, low effort | 70 | 70 | $0.0052 | 17.1 s |
| Haiku 5.5, medium effort | 70 | 70 | $0.0078 | 26.3 s |
| Sonnet 5.5 | 21 | 21 | $0.1050 | 30.3 s |
| Opus 5.5 | 21 | 21 | $0.1675 | 30.3 s |
codebase को explore करने में Haiku low पर $0.0035 और Opus पर $0.1454 लगे, यानी लगभग चालीस गुना ज़्यादा। Haiku कभी धीमा नहीं रहा: सातों काम स्वीकार हुए, कीमत के एक छोटे हिस्से पर, उतनी ही तेज़ी से या उससे तेज़।
डिफ़ॉल्ट रूप से कुछ भी Haiku पर क्यों नहीं चलता
कुछ भी अपने आप Haiku पर नहीं जाता, और यह जानबूझकर है। release 2.1.198 से built-in Explore agent main session का मॉडल विरासत में लेता है, जिसकी ऊपरी सीमा Opus है; उस release से पहले यह Haiku पर चलता था। हर custom subagent भी यही करता है। documentation चुनाव का क्रम देती है: launch के समय बताया गया मॉडल, फिर agent फ़ाइल में लिखा मॉडल, फिर CLAUDE_CODE_SUBAGENT_MODEL variable, और इन सबके बाद ही main मॉडल।
इस सूची में एक जाल है, और docs उसे साफ़ कहते हैं: अकेले subagent model variable सेट करने से built-in Explore और Plan agents का मॉडल नहीं बदलता। दो headless runs दोनों बातों की पुष्टि करते हैं। main session Fable मॉडल पर थी और सवाल एक ही था (Explore agent से पता लगवाओ कि query cache कहाँ साफ़ होता है); tool result उस मॉडल का नाम बताता है जो सच में चला: Opus 5.5। वही run, जिसमें सिर्फ़ subagent model variable को Haiku 5.5 पर सेट किया गया और कुछ और नहीं: फिर Opus 5.5।
इसीलिए एक महीने के logs ऐसे दिखते हैं। 2,631 subagent runs में से 42 Haiku पर गए। subagents ने account के हर token का 48.1% लिया, और weighted cost में Haiku का हिस्सा 0.27% था। यह डिफ़ॉल्ट एक तर्कसंगत चुनाव है: आपके main मॉडल पर चलने वाला explorer code उतना ही अच्छा पढ़ता है जितना main मॉडल। जो कोई नहीं छापता, वह है इसकी कीमत।
दो फ़ाइलें
दो फ़ाइलें इसे ठीक करती हैं, और आप एक लें या दोनों। छोटी फ़ाइल आपके project में एक अकेली agent फ़ाइल है: .claude/agents/Explore.md बनाइए, नाम Explore रखिए, एक description दीजिए, मॉडल को पूरे id claude-haiku-5-5 के साथ सेट कीजिए, effort को low रखिए, और tools को Read, Glob, Grep और Bash तक सीमित कीजिए। Claude Code उसके बाद आपकी फ़ाइल को ही Explore agent मानता है, और docs यह साफ़ शब्दों में कहते हैं: Explore नाम का एक project subagent परिभाषित कीजिए और उसे Haiku मॉडल दीजिए। वही headless run तब resolvedModel: claude-haiku-5-5 बताता है।
दूसरी फ़ाइल आपकी settings है। .claude/settings.json में दो variables वाला एक env block: CLAUDE_CODE_SUBAGENT_MODEL को claude-haiku-5-5 पर, और CLAUDE_CODE_SUBAGENT_MODEL_FORCE को 1 पर सेट कीजिए। Force वही हिस्सा है जो लोग चूक जाते हैं। release 2.1.257 से यह flag subagent मॉडल को हर subagent पर लागू करता है, और launch पर या agent फ़ाइल में दिए गए overrides को नज़रअंदाज़ करता है। environment में इन्हीं दो variables के साथ, बिना agent फ़ाइल के, वही run फिर Haiku 5.5 पढ़ता है।
| आप क्या चाहते हैं | क्या इस्तेमाल करें | साइड इफ़ेक्ट |
|---|---|---|
| हर subagent सस्ता | force flag वाला settings env block | आपके जानबूझकर Opus पर रखे agents भी Haiku पर आ जाते हैं |
| सिर्फ़ explorer सस्ता | Explore agent फ़ाइल | बाकी agents अपने-अपने मॉडल पर रहते हैं |
पूरा model id पिन कीजिए। haiku alias का मतलब Haiku 5.5 सिर्फ़ Anthropic API पर है; Bedrock, Vertex और Foundry पर इसका मतलब अब भी Haiku 4.5 है। Claude Code repository पर एक खुला issue बताता है कि 1,371 में से 1,149 subagents parent के Opus मॉडल पर चले, जबकि फ़ाइल कुछ और कहती थी; यह एक दर्जन builds (2.1.277 से 2.1.290) में रुक-रुककर हुआ, और Anthropic की ओर से कोई जवाब नहीं आया। मौजूदा build 2.1.293 पर 182 में से हर run ने configured मॉडल ही इस्तेमाल किया। फिर भी जाँचिए: /tasks कमांड दिखाता है कि हर subagent किस मॉडल पर चला, और headless run का tool result भी उसे बताता है। इन मॉडलों पर thinking बंद नहीं की जा सकती, इसलिए effort ही बचा हुआ लीवर है; Explore फ़ाइल में low effort एक सोचा-समझा चुनाव है, और वह क्या देता है, यह आगे मापा गया है।
असली meter ने क्या देखा
streaming output वाला हर headless run एक rate_limit_event भेजता है। उसके अंदर दो अंश होते हैं, five-hour window और seven-day window, हर एक दो दशमलव के साथ। ये सीधे उन response headers से आते हैं जो Anthropic हर जवाब के साथ भेजता है, एक point की resolution पर और उससे बारीक नहीं। चारों workers चार blocks के रूप में एक के बाद एक चले, और account को और कुछ नहीं छू रहा था।
| Block | Runs | Five-hour window पहले | Five-hour window बाद | साप्ताहिक window |
|---|---|---|---|---|
| Haiku 5.5, low effort | 70 | 21% | 21% | 67% |
| Haiku 5.5, medium effort | 70 | 21% | 21% | 67% |
| Sonnet 5.5 | 21 | 21% | 22% | 67% |
| Opus 5.5 | 21 | 22% | 23% | 67% |
list price में पूरे matrix की लागत $4.09 रही। meter पर यह एक five-hour window के दो point और हफ़्ते के शून्य point रही। Haiku वाले आधे हिस्से की लागत $0.54 रही और उसने कुछ नहीं हिलाया: इस account की window का एक point Haiku पर इन 140 से ज़्यादा कामों से भी ज़्यादा का है।
Anthropic मॉडल के वज़न पर एक ही वाक्य छापता है: Opus प्रति turn Sonnet से कई गुना महँगा है, और Sonnet Haiku से ज़्यादा। कई गुना। कहीं कोई संख्या नहीं। windows हर मॉडल के लिए एक ही pool हैं, इसलिए session के बीच में मॉडल बदलने से कुछ वापस नहीं मिलता। हर block में एक point तक की rounding हो सकती है, यानी Sonnet का एक point और Opus का एक point अलग नहीं पहचाने जा सकते। meter पक्के तौर पर इतना साबित करता है कि इनमें से किसी भी मॉडल पर एक सीमित काम इस resolution पर दिखता ही नहीं। हर मॉडल का वज़न कहीं और से पढ़ना होगा।
/usage breakdown एक अंदाज़ा है
/usage panel खोलिए और आपको एक breakdown मिलता है: skills, subagents, plugins और MCP servers को दिए गए प्रतिशत। यह server data जैसा दिखता है। यह है नहीं। documentation कहती है कि ये आँकड़े अनुमानित हैं और इस मशीन के local session history से निकाले जाते हैं, इसलिए फ़ॉर्मूला binary में रहता है। executable पर strings चलाइए और दो functions निकल आते हैं।
| कारक | वज़न |
|---|---|
| Model tier: Fable | 10 |
| Model tier: Opus | 5 |
| Model tier: Haiku | 1 |
| Model tier: बाकी सब | 3 |
| Cached tokens | 1 |
| Fresh input tokens | 10 |
| Cache writes | 12.5 |
| Output tokens | 50 |
record का वज़न tokens के योग गुणा model tier है। ये client के attribution weights हैं, इस बात का प्रमाण नहीं कि server आपका quota कैसे गिनता है, और यह अंतर दिखता है। ऊपर के blocks पर यह फ़ॉर्मूला चलाइए: 70 Haiku medium runs का स्कोर 29.5 units है, 21 Opus runs का 27.3। panel Haiku block को Opus block से ऊपर रखेगा; असली meter ने शून्य point बनाम एक point बताया।
नीचे एक दूसरी खामी भी है। एक खुला issue बताता है कि subagent transcripts पहले streaming chunk का usage दर्ज करते हैं: एक run ने 461 output tokens दर्ज किए, जबकि वही run headless में 15,575 दर्ज करता है। इस मशीन का एक transcript हर assistant entry पर 16 output tokens दिखाता है। फ़ॉर्मूला इस कम गिने गए आँकड़े को 50 से गुणा करता है, इसलिए जो subagents बहुत लिखते हैं वे panel से गायब हो जाते हैं। इसे वैसे ही इस्तेमाल कीजिए जैसा यह है: दिन और हफ़्ते की keys के साथ यह बताता है कि कौन-सी skill या agent आपके local history को खा रहा है। आपके असली quota में किसी मॉडल के वज़न के लिए यह एक अंदाज़ा है।
दिन का quota असल में कहाँ जाता है
meter जिस पैमाने को देख पाता है वह एक दिन है। Andrea Grandi ने Haiku 5.5 के आने वाले दिन ही Pro plan पर अपने आँकड़े छापे। उनकी main session medium effort पर Opus 5.5 चलाती है; Sonnet 5.5 पर एक implementer agent code लिखता है; बाकी काम दो Haiku 5.5 agents करते हैं: plan mode में बिना edit tools और ज़्यादा से ज़्यादा बारह turns वाला एक scoper, और low effort पर एक shipper जो commit करता है, push करता है और PR खोलता है।
| माप | मान |
|---|---|
| Pull requests, sessions के ऊपर | 13, 10 sessions में |
| प्रति PR five-hour window | लगभग 6% |
| एक-PR session पर साप्ताहिक counter | लगभग 1% |
| subagents के साथ प्रति PR अनुमानित लागत | $2.31 |
| अकेले Opus पर प्रति PR अनुमानित लागत | $3.59 |
| प्रति session requests, पहले और बाद | 75 से 54 |
| प्रति request tokens, पहले और बाद | 119,000 से 107,000 |
उनका अपना वाक्य ही मुद्दा है: अगर वे subagents के tokens को Opus की दरों पर आँकें, तो दस sessions सिर्फ़ 5% महँगे होते हैं। बचत इस बात से आई कि main context छोटा रहा। एक महीने के logs दूसरी तरफ़ से यही कहते हैं: subagents ने 48.1% tokens लिए, और सभी tokens का 96% cache reads थे। हर subagent एक launch prompt के साथ शुरू होता है; इस account पर उसका median 47,000 tokens है, और worker Opus हो, Sonnet हो या Haiku, यह वही stack रहता है। मॉडल बदलने से यह छोटा नहीं होता।
Effort ज़रूर भूख बदलता है। छोटे feature पर Haiku medium effort ने 14 turns में 233,000 tokens पढ़े; Haiku low effort ने उसी स्वीकार हुए नतीजे के लिए 8 turns में 140,000 पढ़े; Opus को 88,000 लगे। एक स्वतंत्र run ने यही वक्र ऊपर के स्तर पर मापा: high effort पर प्रति काम 55,000 output tokens, max पर 162,000। प्रति token सस्ता, प्रति काम ज़्यादा भूखा, और dial आपके हाथ में है। दो सावधानियाँ: Grandi के डॉलर Pro plan पर एक अनुमान हैं, और यहाँ का matrix एक छोटी repository पर है। इनमें से कोई भी Max plan पर एक पूरा हफ़्ता नहीं है।
routing table, सीमाएँ और pack
routing table: code explore करना, फ़ेल होता test ठीक करना, lint साफ़ करना, commit message लिखना, छोटा feature जोड़ना, diff की समीक्षा करना, architecture का सार लिखना। सातों काम low effort पर Haiku 5.5 को जाते हैं, low और medium दोनों पर हर एक में 70 में से 70 runs स्वीकार हुए। प्रति काम list price में यह एक सेंट के पाँचवें हिस्से से आधे सेंट के बीच है, जबकि Opus पर छह से सत्रह सेंट। Sonnet या Opus पर वह रहता है जो Anthropic के अपने शब्दों में जटिल agentic coding है, जहाँ Terminal-Bench Haiku को 70.6 के सामने 39.2 पर रखता है; launch की जो एक समीक्षा जाँची गई, वह भी इसी पंक्ति पर खत्म हुई: कठिन coding के लिए Sonnet पर रहिए।
दोनों फ़ाइलें table के बगल में रखी हैं: पूरे Haiku model id और low effort वाली Explore agent फ़ाइल, और subagent मॉडल व force flag वाला settings env block। जाँच /tasks कमांड है, जो हर subagent का मॉडल दिखाता है। उस पंक्ति पर भरोसा कीजिए, फ़ाइल पर कभी नहीं।
शुरुआत के सवाल पर लौटते हैं। हर subagent को Haiku पर कर दीजिए, तो meter क्या वापस देता है? एक सीमित काम के लिए, किसी भी मॉडल पर एक point से कम। 182 runs के पूरे matrix ने five-hour window को दो point और हफ़्ते को शून्य हिलाया। असली हफ़्ता main context से और उस launch prompt से लौटता है जो हर subagent अपने साथ ढोता है। मॉडल बदलना सस्ता हिस्सा है, और इसे लेना मुफ़्त है।
| सीमा | विवरण |
|---|---|
| Repository | एक छोटी repo, tinydb, 226 tests |
| काम का आकार | सात सीमित काम, हर एक एक मिनट से कम, agentic coding का पूरा दिन नहीं |
| Meter | एक point की resolution, हर block में प्लस या माइनस एक point |
| गुणक | Anthropic ने प्रति मॉडल कोई प्रकाशित नहीं किया |
| Version | 8 अक्टूबर 2026 को Claude Code 2.1.293; पुराने builds agent फ़ाइल के मॉडल को नज़रअंदाज़ करते थे (खुला issue) |
मुफ़्त pack में routing table, दोनों फ़ाइलें, और वह harness है जिसने इसे मापा: सात prompts, checks और runner।
AIDive