AIDiveपरिचय — दस mods, तीन टिके
Claude Code mods plugins के अंदर के TypeScript functions हैं जो Claude Code का interface दोबारा बना सकते हैं या उसके काम करने का तरीक़ा बदल सकते हैं। अक्टूबर की शुरुआत में लॉन्च के एक दिन के भीतर तीन अलग-अलग वीडियो tours ने developers से इनमें से दस install करने को कहा। उनमें से दो creators कैमरे पर मानते हैं कि कुछ mods कुछ भी नहीं बचाते, और किसी ने भी एक भी mod नहीं नापा। यह टेस्ट नापता है: दसों hyped mods एक असली हफ़्ते के काम पर चले, और हर एक के overhead, बचत और keep-या-delete verdict पर एक नंबर है। नतीजा पहले ही: दस में से सिर्फ़ तीन एक काम करने वाले developer की मशीन पर जगह के लायक हैं, और उनमें से एक चुपचाप हर जवाब पर tokens ख़र्च करता है।
यह लहर, और हमने क्या चलाया
Anthropic की अपनी परिभाषा एक साँस में आ जाती है: mod एक function है जो किसी event से hook होता है, और वह उससे पहले, उसके बाद, या उसकी जगह चल सकता है। Event यानी एक tool call, भेजा गया prompt, या interface का कोई हिस्सा जो draw हो रहा है। Mods सादा TypeScript हैं, जो एक plugin के अंदर आते हैं जिसे आप किसी भी दूसरे plugin की तरह install करते हैं।
लॉन्च का tweet क़रीब एक दिन में चालीस लाख views पार कर गया, बीस हज़ार likes के साथ, और bookmarks replies और reposts दोनों के जोड़ से ज़्यादा थे। लॉन्च के दो दिन बाद ही एक community catalog सैकड़ों repositories में एक हज़ार से ज़्यादा public mods scan कर चुका था।
इस टेस्ट की bench एक असली हफ़्ते का काम है: चार projects में 85 sessions, लगभग 900 prompts, और 6,000 से कम tool calls। हर mod validator के audit से गुज़रा, जो बताता है कि वह किससे hook होता है और क्या छू सकता है, और हर mod ने उसी मशीन पर, मौजूदा release पर, एक clean baseline के सामने वही task चलाया।
मुख्य बँटवारा: दस में से छह की runtime पर कोई नापने लायक कीमत नहीं, तीन असली समय या असली tokens ख़र्च करते हैं, और एक अपना इकलौता वादा तोड़ता है।
Decoration tier, नापा हुआ
ये शांत छह connection के शोर के भीतर ही आते हैं। Goal meter, repo heatmap, flight recorder, model router, session bookmarks और auto handoff, सब लगभग चार सेकंड के baseline task पर पाव सेकंड की बचत और पाँचवें हिस्से के सेकंड की बढ़त के बीच रहते हैं।
| Mod | Runtime में फ़र्क़ | टिप्पणी |
|---|---|---|
| Goal meter | शोर के भीतर | decoration pane |
| Repo heatmap | शोर के भीतर | फ़ाइलें पढ़े जाने पर जल उठती हैं |
| Flight recorder | शोर के भीतर | turn की live timeline |
| Model router | शोर के भीतर | subagents पर फ़ायदा देता है, verdict देखें |
| Session bookmarks | शोर के भीतर | capability का दायरा बड़ा |
| Auto handoff | ~70 ms idle | context threshold पर एक handoff लिखता है |
ये शानदार दिखते हैं, और कुछ टूटा नहीं: हर configuration के हर run ने task सही पूरा किया। Headless में इनकी कोई कीमत नहीं, क्योंकि draw करने को कुछ है ही नहीं; terminal में ये panes सेकंड में तीस बार तक redraw होते हैं, इसलिए decoration tier की असली कीमत tokens नहीं, ध्यान है।
Validator का audit वह जगह है जहाँ मज़ाक़ ख़त्म होता है। Bookmarks mod model को call कर सकता है, आपकी मशीन पर processes शुरू कर सकता है, फ़ाइलें लिख सकता है, और environment से आपके configuration paths पढ़ता है। इनमें से कुछ छिपा नहीं है और कुछ भी नुक़सानदेह नहीं, लेकिन एक bookmark के लिए यह बहुत ज़्यादा पहुँच है। चार mods यहीं बाहर होते हैं: goal meter, heatmap और flight recorder, decoration के तौर पर, शून्य नापे हुए फ़ायदे के साथ, और bookmarks mod इसलिए कि वह कमाई से ज़्यादा माँगता है।
Flagship हर turn का बिल बनाता है
Suggestion engine वह mod है जिसे हर वीडियो सबसे पहले दिखाता है: आपका जवाब पूरा होता है, composer के ऊपर तीन prompt suggestions आ जाते हैं, आप एक नंबर दबाते हैं और draft ख़ुद भर जाता है। इसकी कार्यप्रणाली इसके अपने author ने documented की है: जब आपका turn पूरा होता है, यह उन suggestions के लिए model से पूछने को session को fork करता है, और fork session का prompt cache साझा करता है, इसलिए उसकी कीमत लगभग एक छोटे जवाब जितनी है। Tours उस line का ज़िक्र कभी नहीं करते।
Bench पर नापने पर यह हर qualifying जवाब पर क़रीब 250 extra output tokens और लगभग तीन सेकंड की extra wall time है, और qualifying जवाब लगभग हर जवाब है: कोई भी जो क़रीब अस्सी characters से लंबा हो। Fork पर surface का कोई gate भी नहीं है। Suggestions सिर्फ़ terminal में draw होते हैं, लेकिन fork हर जगह चलता है, उन headless runs में भी जहाँ कुछ draw हो ही नहीं सकता।
| Mod | नापी हुई कीमत | कब चलता है |
|---|---|---|
| Suggestion engine | ~250 output tokens + ~2.9 s हर qualifying जवाब पर | ~80 characters से लंबा हर जवाब, headless समेत |
| Cache keeper | ~1.5 s हर turn, साथ में warming-mode के model calls | हर turn, घंटों तक warming |
Cache keeper की भी यही शक्ल है: हर turn पर क़रीब डेढ़ सेकंड, और एक warming mode जो आपका prompt cache ठंडा न पड़े इसलिए घंटों तक छोटे model calls ख़र्च करता है। Subscription plan पर cache window पहले से एक घंटे की है, तो आप ऐसी समस्या के लिए pings भरते हैं जिसे plan काफ़ी हद तक पहले ही सुलझा चुका है। दोनों ईमानदार designs हैं जिनकी कीमतें documented हैं, दोनों हर turn पर लगने वाला tax हैं जिसकी कीमत install lists कभी नहीं बतातीं, और दोनों मशीन से हटते हैं।
Mod बनाम hook, वही काम
Claude Code में hooks पहले से थे: आपकी settings में एक shell script जो उन्हीं events पर चलती है। Documentation चुनाव का जवाब एक table row में देती है: mod interface के लिए और events को दोबारा लिखने के लिए है; hook उस script से block, allow या log करने के लिए है जो आपके पास पहले से है।
नापने लायक फ़र्क़ process spawn है। Settings का hook हर tool call पर एक नया process शुरू करता है। इस मशीन पर टाइम करने पर, कुछ न करने वाला shell hook क़रीब 8 ms और Node शुरू करने वाला hook क़रीब 43 ms लेता है, हर एक call पर, script कुछ करे उससे पहले। Bench के हफ़्ते के 5,993 tool calls में यह सिर्फ़ interpreter startup के चार मिनट से ज़्यादा है। Mod इसमें से कुछ नहीं चुकाता: उसका handler engine के अपने process के अंदर चलता है, और engine का log दिखाता है कि यह hop क़रीब एक millisecond में बैठ जाता है।
| Handler | हर call की कीमत | 5,993 calls का एक हफ़्ता |
|---|---|---|
| Shell hook (no-op) | ~8 ms | ~48 s |
| Node hook (no-op) | ~43 ms | ~4.3 min |
| Mod (in-process) | ~1 ms | ~6 s |
असली दुनिया की इकलौती migration रिपोर्ट भी यही कहती है: सत्ताईस shell hooks पाँच mods में सिमट गए, और हर call का spawn उनके साथ ग़ायब हो गया। जो नियम बचता है: interface या event rewriting हो तो mod; अपनी भरोसेमंद script से block, allow या log करना हो तो hook, क्योंकि spawn की कीमत हज़ारों calls पर ही मायने रखती है; और जो ज्ञान आप बार-बार दोहराते हैं, वह skill। जो hook आपने पढ़ा है, वह उस mod से बेहतर है जो आपने नहीं पढ़ा।
वह guard जो कुछ नहीं करता
सबसे सरल संभव safety mod एक ऐसा guard है जो हर shell command पर नज़र रखता है, और यह वाला crash होने के लिए लिखा गया था। Claude Code से एक marker file बनाने को कहा गया; guard ने throw किया; command फिर भी चल गई और file बन गई। यह bug नहीं, documented default है: जब कोई hook throw करे, timeout हो जाए, या ग़लत shape लौटाए, तो Claude Code उसे छोड़कर आगे बढ़ जाता है। एक टूटी decoration से session ठप नहीं होना चाहिए, लेकिन टूटा हुआ guard fail open होता है, चुपचाप, debug log की एक line के साथ जिसे कोई नहीं पढ़ता।
इसका हल एक catch handler है जो deny लौटाता है। वही crash होने वाला guard, catch के साथ, command को मना कर देता है और नाकामी का नाम बताता है। एक line तय करती है कि guard fail open होगा या fail closed, documentation यही pattern देती है, और लगभग कोई इसे install नहीं करता।
एक community team ने मौजूदा release पर इन cases को दोबारा चलाया और model ने क्या कहा उससे नहीं, marker files से फ़ैसला किया। Catch pattern तीन में से तीन runs में fail closed रहा, और एक रास्ता अब भी चुपचाप टूटा है: call के आगे भेजे जा चुकने के बाद लौटाया गया deny tool को नहीं रोकता। File तीन में से तीन बार बन गई, जबकि model को बताया गया कि write नाकाम रहा।
जिस field report ने इस समस्या को नाम दिया, उसने दिनों तक एक ऐसा guard चलाया जो enabled था, loaded था, और कुछ नहीं कर रहा था, क्योंकि एक पुराने flag ने उसे नीचे से बंद कर रखा था: तीन हरे status chips, और उनके नीचे शून्य पर अटका counter। ऐसी ख़ामोशी जो बिल्कुल सेहत जैसी दिखती है।
Collision guard पहला keep कमाता है। यह एक असली समस्या सुलझाता है, यानी एक ही फ़ाइल को एडिट करती दो खुली chats, और इसकी नाकामी का तरीक़ा शोर वाला है: यह dialog में पूछता है और कभी चुपचाप allow नहीं करता। इसकी कीमत edits पर क़रीब आधा सेकंड है और prompt में कुछ नहीं जुड़ता। इसे install करें, और फिर भी इसे catch handler दें।
एक paste करने पर आप क्या देते हैं
Anthropic लॉन्च के दिन ही साफ़ शब्दों में कहता है: mods आपकी मशीन पर वही access लेकर चलते हैं जो ख़ुद Claude Code के पास है। वे sandboxed नहीं हैं; उन्हें वैसे ही install करें जैसे आप अपने कंप्यूटर पर कोई भी code install करते हैं। ठोस रूप में, एक mod आपकी मशीन पर आपकी तरह काम कर सकता है: आपका environment और settings पढ़ सकता है, जहाँ API keys रहती हैं; हर prompt और हर tool call देख सकता है; उन्हें दोबारा लिख सकता है; आपसे पूछे जाने से पहले ही किसी tool call को approve कर सकता है; और अपने ही model calls पर आपके plan का usage ख़र्च कर सकता है।
दो जाल सावधान users को भी फँसाते हैं। Permission rules Claude के tool calls पर चलते हैं, mod के अपने calls पर नहीं: Claude को env file देने से मना करें, तब भी mod उस फ़ाइल को अपने file access से सीधे पढ़ सकता है, या कोई program शुरू कर सकता है जो पढ़ ले। Network policy का भी यही किनारा है: web traffic बंद करें तो mod के अपने fetch calls refuse हो जाते हैं, लेकिन mod का शुरू किया child process पूरे access के साथ network तक पहुँच जाता है। एक built-in guard mod है जो सबसे पहले load होता है, लेकिन सिर्फ़ managed machines पर और Team या Enterprise seats के लिए; निजी subscription पर अकेली seat को इसमें से कुछ नहीं मिलता।
इनमें से कुछ भी सैद्धांतिक नहीं है। एक user ने लॉन्च के कुछ दिन बाद proof of concept छापा: एक mod जिसका button एक program शुरू करता है और home directory में लिखता है, catalog से बिना किसी चेतावनी के install हुआ, और उसकी बात सही है: catalog एक app store जैसा दिखता है, जो ऐसी जाँच का आभास देता है जो है नहीं। एक अलग hook bug ने एक दिन के लिए subagent isolation तोड़ दिया; maintainer ने इसे बड़ी चूक कहा और एक release बाद ठीक कर दिया।
Catalog का अपना scan, एक हज़ार से ज़्यादा public mods पर: चार सौ से ज़्यादा host processes शुरू करते हैं, लगभग चार सौ फ़ाइलें पढ़ते हैं, और तीन सौ से ज़्यादा हर tool call देखते हैं। Catalog की अपनी चेतावनी सही नज़रिया है: यह एक footprint है, verdict नहीं; एक PR tracker को git चलाना ही पड़ता है। अनुशासन की कीमत दो मिनट है: कुछ भी enable करने से पहले validator चलाएँ, और अपने exits जानें: एक session के लिए safe mode, और हर installed hook को हमेशा के लिए रोकने वाली एक setting।
तीन रखें, सात delete करें
दस में से तीन अपनी जगह कमाते हैं: collision guard, model router, और auto handoff।
| Mod | Verdict | इसके पीछे का नंबर |
|---|---|---|
| Collision guard | रखें | edits पर ~0.5 s, शोर के साथ फ़ेल होता है, prompt में कुछ नहीं जुड़ता |
| Model router | रखें | subagent सस्ते model पर बिल हुआ, एक तिहाई कीमत |
| Auto handoff | रखें | 70 ms का कुछ नहीं, context threshold पर एक handoff write |
| Suggestion engine | delete | हर qualifying जवाब पर ~250 output tokens + ~2.9 s |
| Cache keeper | delete | हर turn ~1.5 s, 1 घंटे की cache window के सामने warming pings |
| Recording mode | delete | screen को mask करता है, disk को नहीं |
| Goal meter | delete | decoration, शून्य नापा हुआ फ़ायदा |
| Repo heatmap | delete | decoration, शून्य नापा हुआ फ़ायदा |
| Flight recorder | delete | decoration, शून्य नापा हुआ फ़ायदा |
| Session bookmarks | delete | अपने काम से कहीं ज़्यादा पहुँच |
Model router के पास रसीद है: बड़े model पर चल रहे एक session ने एक subagent spawn किया, और run के अपने usage readout ने दिखाया कि subagent सस्ते model पर बिल हुआ, उसी छोटे काम के लिए एक तिहाई कीमत पर। जिन हफ़्तों में subagents ज़्यादा हों, वहाँ यह असली पैसा है। Auto handoff तब तक कुछ ख़र्च नहीं करता जब तक वह फ़ायदा न दे दे: सत्तर millisecond का idle overhead, और एक context threshold के पार वह cold start के लिए handoff लिख देता है, बस एक बार। इस लहर के एक creator ने ख़ुद माना कि manual handoff button सच में समय नहीं बचाता; एक automatic threshold write के रूप में, वह बचाता है।
टेस्ट के बाद जो अनुशासन बचता है: कुछ भी enable करने से पहले validator का audit पढ़ें, हर guard को उसका catch handler दें ताकि वह fail closed हो, और demos को masking mod के भरोसे नहीं, safe mode में record करें। सीमाएँ असली हैं: एक हफ़्ता, एक मशीन, एक workload, और छोटे model पर हर बिंदु के तीन runs। आपके तीन अलग हो सकते हैं, पर अब आप जानते हैं कि उन्हें कैसे खोजना है।
