AIDiveइंट्रो: वही जाँचें, दोगुना मीटर, पाँच सीमाएँ
Ultracode वह keyword है, या वह टॉगल, जो Claude Code में आपके टाइप किए एक अनुरोध को पूरी agents की टीम में बदल देता है। एक ही spec पर हुए जोड़ीदार टेस्ट में दोनों रन ने वही hidden checks पास किए, और ultracode रन ने सेशन मीटर का दोगुने से ज़्यादा हिस्सा खा लिया। इसकी वजह कोई ज़्यादा समझदार मॉडल नहीं है: harness एक वाक्य जोड़ देता है और तीन गार्ड बंद कर देता है।
यह लेख चार बातें कवर करता है:
- प्लान के मीटर पर पढ़ा गया जोड़ीदार टेस्ट;
- कई और जोड़ियों में token का गुणक;
- वह एक तरह का काम जहाँ एक टीम ने 66 छिपाए गए bugs ढूँढे और अकेले agent ने 14;
- वे पाँच सेटिंग जो रन को आपका हफ़्ता खाने से पहले रोक देती हैं, जिनमें से एक उसे usage limit पर ही रोक देती है।
Ultracode क्या चालू करता है: keyword, टॉगल, agents का workflow
Ultracode के दो स्विच हैं। किसी एक prompt के भीतर ultracode टाइप करने से वह अकेला काम workflow की तरह चलता है, और सेशन का effort स्तर नहीं बदलता। /effort कमांड से टॉगल चालू करने पर Claude हर ठोस काम के लिए एक workflow प्लान करता है, इसलिए एक अनुरोध लगातार कई workflows में बदल सकता है।
Workflow एक स्क्रिप्ट है जिसे Claude अपने लिए लिखता है; वह स्क्रिप्ट चरणों में agents की टीम चलाती है। एक छोटे सैंडबॉक्स पर (कुछ फ़ाइलें जिनमें promises का लापरवाह हैंडलिंग था, और सिर्फ़ पढ़ने वाली समीक्षा माँगी गई थी), Claude ने फ़ाइलें खँगालीं, "unhandled promise audit" नाम का workflow फैलाया, और prompt बॉक्स के नीचे एक टास्क पंक्ति दिखी जिसमें progress bar, agents की संख्या, बीता समय और बढ़ता token योग था। /workflows कमांड हर agent की एक पंक्ति दिखाता है, उसकी अपनी token गिनती के साथ, और pause, stop या restart की कुंजियाँ भी देता है।
उस रन में हर finder ने verifiers शुरू होने से पहले ही लगभग 45,000 tokens पढ़ लिए थे, कोड की मुट्ठी भर पंक्तियों के लिए।
हर सेशन के साथ एक आकार-दिशानिर्देश भी रहता है, यानी वह agents की संख्या जिसके नीचे रहने की सलाह Claude को दी जाती है:
| आकार-दिशानिर्देश | सुझाए गए agents |
|---|---|
| small (Pro पर डिफ़ॉल्ट) | 5 से कम |
| medium | 10 से कम |
हर agent आपकी बातचीत के ऊपर अपने request भेजता है। Workflow कभी एक बिल नहीं होता; वह हर agent का एक बिल होता है, और मीटर हर एक को गिनता है।
जोड़ीदार टेस्ट: वही 136 जाँचें, 8 प्रतिशत बनाम 18, और वो रुकता नहीं
एक developer ने सबसे ऊपरी सब्सक्रिप्शन प्लान पर साफ़ सेटअप के साथ लागत नापी: एक छोटे spreadsheet ऐप का वही spec, वही मॉडल उसी effort पर, एक सादा रन और एक ultracode रन। दोनों को hidden checks से जाँचा गया, यानी ऐसे टेस्ट जो मॉडल कभी नहीं देखता। दोनों ने सभी 136 पास किए।
| रन | कैसे ख़त्म हुआ | इस्तेमाल हुई सेशन लिमिट | पास हुई जाँचें |
|---|---|---|---|
| सादा | अपने आप, 25 मिनट में | 8 % | 136 / 136 |
| Ultracode | 76 मिनट पर घड़ी से कटा, तब भी जाँच रहा था | 18 % | 136 / 136 |
Ultracode रन के भीतर Claude ने एक ऐसी स्क्रिप्ट लिखी जिसका एकमात्र काम टीम चलाना था: गिने गए 12 agents, testers, कुछ judges, और बाद में कुछ "breakers" जिनका काम पेज को तोड़ना था। एक breaker को formula bar में असली bug मिला, जो दूसरे सेल पर क्लिक करने के बाद भी पुराना टेक्स्ट दिखाता रहता था।
प्रति मिनट के हिसाब से ultracode रन ने लिमिट लगभग सादे रन जितनी ही तेज़ी से खाई, औसतन थोड़ी धीमी। वह तेज़ नहीं जला; वह रुका नहीं। Ultracode Claude को ज़्यादा समझदार नहीं बनाता, वह Claude से जाँच करवाता है, और हर जाँच का पैसा आप देते हैं। यह एक छोटे spec पर एक जोड़ी है, और दूसरा रन घड़ी से कटा था, लेकिन तस्वीर साफ़ है: वही जवाब, सेशन विंडो का दोगुने से ज़्यादा हिस्सा, और अतिरिक्त समय पूरा जाँच में गया।
ये महँगा क्यों है: एक वाक्य और तीन गार्ड बंद
मॉडल वही है। जो बदलता है वह टेक्स्ट है जो harness उसे थमाता है; harness यानी Claude Code खुद, उसके tools और मॉडल के आसपास के निर्देश।
Ultracode चालू होने पर Claude Code कोई भी workflow लिखने से पहले एक reference लोड करता है। वह टेक्स्ट मॉडल को बताता है कि हर ठोस काम के लिए डिफ़ॉल्ट रूप से workflow चलाओ, और उसमें वह वाक्य है जो बिल को समझाता है: "The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint." यह harness का अपना टेक्स्ट है, और एक सार्वजनिक GitHub issue में यही पंक्तियाँ उद्धृत हैं।
तीन गार्ड एक साथ बंद हो जाते हैं:
- बड़े workflow की चेतावनी, जो आम तौर पर तब आती है जब रन बहुत ज़्यादा agents शेड्यूल करे, दिखती नहीं।
- एक साथ चल सकने वाले agents की सेशन सीमा उन agents पर लागू नहीं होती जिन्हें Claude खुद spawn करता है।
- Auto mode में पहला लॉन्च कभी मंज़ूरी के लिए पेश नहीं होता।
आकार-दिशानिर्देश सलाह है, सीमा नहीं: सैंडबॉक्स पर इसे small (5 से कम agents) पर रखने के बावजूद ultracode रन ने 9 agents चलाए। निष्पक्षता से कहें तो वह वाक्य एक डिफ़ॉल्ट है जिसे मॉडल तौल सकता है, और बहुत बड़े कामों के लिए गार्ड जानबूझकर हटाए गए हैं। जवाब एक पंक्ति में आता है: ultracode मॉडल नहीं बदलता, वह निर्देशों को बदलकर "हर चीज़ के लिए एक टीम, और लागत कोई बाधा नहीं" कर देता है।
मल्टीप्लायर: तीन जोड़ियाँ, effort की सीढ़ी, 30x वाली जोड़ी
एक दूसरे developer ने Pro प्लान पर कई single agent बनाम workflow जोड़ियाँ चलाईं, समीक्षा-शैली की स्क्रिप्ट्स, और हर एक से पहले और बाद में usage मीटर पढ़ा।
| माप | Single agent | Workflow |
|---|---|---|
| एक समीक्षा स्क्रिप्ट पर tokens | लगभग 115,000 | 972,000 |
| जोड़ियों में token गुणक | 1x | 18x तक, लगभग उन्हीं निष्कर्षों के लिए |
| मीटर की हरकत | 1x | 3x तक |
| दीवार-घड़ी का समय | लगभग एक जैसा | लगभग एक जैसा |
Workflow जल्दी ख़त्म नहीं हुआ; उसने ज़्यादा खर्च किया और आपने उतना ही इंतज़ार किया। समानांतर चलना सिर्फ़ एक जगह फ़ायदेमंद रहा: स्वतंत्र शोध कामों के एक बैच में, जहाँ agents जल्दी ख़त्म हुए, फिर भी दोगुने से ज़्यादा tokens पर।
तीसरे टेस्ट में API कीमतों पर हर effort स्तर पर कुछ छोटे ऐप बनाए गए। सीढ़ी का हर कदम बिल को लगभग दोगुना करता गया, और ultracode max की लागत से कई गुना पर पहुँचा, बिना कभी सबसे आगे निकले। उन tokens का ज़्यादातर हिस्सा cache reads था, यानी सस्ते वाले; output tokens का छोटा सा हिस्सा लगभग आधी लागत बना।
एक और जोड़ी, एक शहर का दृश्य: अकेले agent को लगभग एक घंटा लगा और API कीमत पर कुछ डॉलर। Ultracode रन में लगभग पूरा दिन गया, दर्जनों subagents लगे, और लागत लगभग 30 गुना रही।
ये पूरे अंकों में पढ़े गए मीटर रीडिंग हैं, API कीमतों पर बनाए गए नए ऐप हैं और एक शहर का दृश्य है, इसलिए इनमें से कोई अकेला स्कोरबोर्ड नहीं है। साथ मिलकर पैटर्न हर बार वही है: fan-out जाँच और कवरेज ख़रीदता है, बेहतर जवाब नहीं, जब तक काम स्वतंत्र टुकड़ों में न बँटे।
Fan-out कहाँ फ़ायदा देता है: जज के रूप में test suite, और एक पंक्ति का नियम
कुछ काम सचमुच इसी आकार के होते हैं: माइग्रेशन, ऑडिट, पूरे कोडबेस में स्वीप।
Bun को Zig से Rust में Claude Code के लगभग 50 dynamic workflows से दोबारा लिखा गया, जो 11 दिन लगातार चले। यह आधे मिलियन से ज़्यादा पंक्तियों का Zig था, शुरुआत से लेकर हर प्लेटफ़ॉर्म पर पूरा test suite पास होने तक, उन्हीं दिनों में। इसे चलाने वाली चीज़ agents की संख्या नहीं थी, बल्कि जज था: एक विशाल मौजूदा test suite जो किसी की राय के बिना pass या fail बताता था।
Anthropic का bug शिकार भी यही दिखाता है। एक बड़े कोडबेस में सत्तर bugs छिपाए गए और एक अकेला agent कई बार चलाया गया।
| Agent | 70 में से मिले bugs |
|---|---|
| Single agent (3 रन) | 14, 15, 27 |
| Workflow (3 रन) | हर रन में 66 |
एक चेतावनी: वह टेस्ट Claude Managed Agents पर चला था, जो API प्रोडक्ट है, Claude Code पर नहीं, और कोई लागत नहीं बताई गई।
लॉन्च थ्रेड बाकी रिपोर्ट की गई सफलताएँ जोड़ता है, और वे सब एक जैसी दिखती हैं: नियम-फ़ाइल के विरुद्ध समीक्षा, पूरे कोडबेस का अनुवाद, स्कैन किए पन्नों के ढेर की सफ़ाई। लॉन्च ब्लॉग साफ़ कहता है: ज़्यादातर पारंपरिक coding कामों को पाँच reviewers के पैनल की ज़रूरत नहीं होती।
नियम: fan-out तभी करें जब कोई test suite या नियमों का सेट आउटपुट को परखे, और काम स्वतंत्र टुकड़ों में बँटे। बाकी सब कुछ सादा चलाएँ, high पर। जोड़ीदार टेस्ट करने वाले ने अपने शब्दों में यही कहा: इसे उन कामों के लिए बचाकर रखें जहाँ जाँच ही काम है, जैसे सैकड़ों फ़ाइलों में माइग्रेशन।
रन को सीमित करने वाली पाँच सेटिंग
हर सीमा ऐसी जगह है जिसे आप पहले से जानते हैं।
| # | सेटिंग | कहाँ | असर |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config में Dynamic workflow size के तहत, या settings.json |
सलाह (5 से कम agents), बड़े workflow चेतावनी की सीमा भी घटाती है |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
environment variable, लॉन्च से पहले export करें | डिफ़ॉल्ट रूप से एक साथ 16 agents तक; 4 पर रखें तो बाकी कतार में लगते हैं, रन को मारे बिना खर्च की रफ़्तार धीमी होती है |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
environment variable | हर workflow agent को आपके चुने एक मॉडल पर चलाता है जबकि बाकी subagents अपना मॉडल रखते हैं; सस्ता मॉडल जाँच को सस्ता बनाता है |
| 4 | ultracode keyword, कभी टॉगल नहीं |
prompt में; settings में ultracode कुंजी कभी नहीं |
keyword एक काम को workflow की तरह चलाकर रुक जाता है; टॉगल उसे बंद करने तक स्थायी बना देता है |
| 5 | autoContinueAtUsageLimit |
settings | चालू: लिमिट छूने वाला रन रुकता है, रीसेट का इंतज़ार करता है और आगे बढ़ता है, एक से ज़्यादा बार; बंद: agents दीवार पर fail हो जाते हैं और रन वहीं ख़त्म हो जाता है |
इनके साथ तीन आदतें चलती हैं। लॉन्च ब्लॉग कहता है कि prompt में लिखा बजट, जैसे "use 10k tokens", सीमा तय करता है। किसी भी रन के बाद /usage दिखाता है कि हाल के usage का कितना हिस्सा subagents और workflows में गया, और जब वे हावी हों तो चेतावनी भी देता है। अगर चलते समय कोई रन ग़लत दिखे, तो /workflows पेन और x कुंजी उसे रोक देती हैं, और अब तक का किया काम आम तौर पर बचा रहता है।
इनमें से कुछ भी agent को सस्ता नहीं बनाता। ये सिर्फ़ यह सीमित करती हैं कि एक रन कितने agents पर खर्च कर सकता है, और कितनी देर तक खर्च करता रह सकता है।
बेकाबू रन, सीमाएँ और फ़ैसला
एक सार्वजनिक रिपोर्ट दिखाती है कि हफ़्ता कैसे ग़ायब होता है। सबसे बड़े प्लान पर मॉडल की लिखी एक स्क्रिप्ट ने एक घंटे से कम में 221 agents शुरू किए। पहली session-limit error के बाद भी स्क्रिप्ट dispatch करती रही, और अगले कुछ मिनटों में 189 और agents शुरू हुए। Filer की अपनी तालिका दीवार तक पहुँचने से पहले चरणों में करोड़ों tokens गिनती है।
| चरण | Tokens, cache समेत |
|---|---|
| Ground | 11,063,801 |
| Find | 35,885,272 |
| Merge | 516,226 |
| कुल | 47,465,299 |
दोषी जनरेट की गई स्क्रिप्ट की एक पंक्ति थी, एक fallback जो कहता था: अगर agent कुछ न लौटाए, तो कच्ची सूची इस्तेमाल करो और आगे बढ़ो। Merge fail हुआ और रन चलता रहा। वह वर्ज़न usage limit पर pause आने से पहले का है, और filer कहता है कि वे tokens fail हुए agents के नहीं थे। Concurrency की सीमा उस रन को पतला कर देती, और auto-continue बंद होता तो वह दीवार पर ख़त्म हो जाता।
फ़ैसला: उसी काम पर, उतनी ही जाँचें पास होने पर, ultracode ने सादे रन से दोगुने से ज़्यादा मीटर लिया। इसलिए नहीं कि वह ज़्यादा समझदार है, बल्कि इंजेक्ट किए गए वाक्य और उन गार्ड्स की वजह से जो वह हटा देता है। यह तब फ़ायदा देता है जब कोई test suite या नियमों का सेट आउटपुट को परखे और टुकड़े एक-दूसरे का इंतज़ार न करें। बाकी हर जगह, आप इसे टाइप करते हैं और जाँच का पैसा देते हैं। पाँच सेटिंग तय करती हैं कि एक रन कितना खर्च कर सकता है: आकार-दिशानिर्देश, concurrency की सीमा, workflow का मॉडल, टॉगल के बजाय keyword, और लिमिट पर रुकना।
