AIDiveपरिचय: वो हफ़्ता जो छोटा हो गया
सितंबर 2026 के बीच में समर प्रमोशन खत्म हुआ और Claude Code की साप्ताहिक लिमिट 17% घट गई। सबसे बड़े प्लान वाले यूज़र अब बताते हैं कि बुधवार तक उनका हफ़्ता खाली हो जाता है। Anthropic की अपनी घोषणा कहती है कि लिमिट स्थायी रूप से 25% बढ़ाई गई है, और उसके ठीक बाद की पोस्ट उसी बदलाव को 17% की कटौती कहती है।
लिमिट को खींचने वाली हर टिप लिस्ट बिना एक भी नंबर के आती है। इस आर्टिकल में हर फ़िक्स के साथ एक नापा हुआ नंबर है, और उन्हें उसी हिसाब से क्रम में रखा गया है। दो नतीजे सबसे अलग दिखते हैं: एक महीने के tokens का लगभग आधा हिस्सा subagents को गया, और एक लंबा ब्रेक अगले मैसेज से लगभग पूरा सेशन दोबारा लिखवा देता है।
क्या बदला, और गिनती कैसे करें
यहाँ के सारे नाप एक डेवलपर के Claude Code लॉग के एक महीने से आते हैं: 3 सितंबर से 3 अक्टूबर तक के 455 सेशन और 63,398 रिक्वेस्ट।
प्रमोशन मई से 13 सितंबर तक चला और उसने साप्ताहिक लिमिट को 50% ऊँचा कर दिया था। हर पाँच घंटे की विंडो की लिमिट कभी नहीं हिली। अगस्त के अंत में Anthropic के डेवलपर अकाउंट ने 25% की स्थायी बढ़ोतरी की घोषणा की, और एक पोस्ट बाद उसी थ्रेड में कहा गया कि यह असल में 17% की कटौती बनती है। दोनों बातें सही हैं:
| अवधि | साप्ताहिक लिमिट (पुरानी लिमिट = 100) |
|---|---|
| प्रमोशन से पहले | 100 |
| प्रमोशन के दौरान (मई से 13 सितंबर) | 150 |
| 14 सितंबर से स्थायी लेवल | 125 |
150 से 125 पर आना ही वो 17% है जो लोग महसूस करते हैं। दो सबसे बड़े प्लान वाले एक यूज़र ने लिखा कि बुधवार को 100% पर पहुँचना पहले कभी नहीं हुआ था। उसी प्लान पर एक और यूज़र मंगलवार सुबह ही 86% पर था। कटौती अकेला कारण नहीं है: सितंबर की शुरुआत में एक ज़्यादा भूखा मॉडल आया था, इसलिए हर खाली हफ़्ता इसी बदलाव से नहीं आता।
आपकी तरफ़ से एक प्रतिशत दिखता है। /usage स्क्रीन हाल के usage को skills, subagents, plugins और हर जुड़े MCP सर्वर में बाँटती है, और cache miss पर निशान लगाती है। एक कुंजी उसे पिछले एक दिन और पिछले सात दिन के बीच बदल देती है। जो आप नहीं देख सकते, वो है लिमिट का साइज़ tokens में: Anthropic प्रतिशत और मल्टीप्लायर छापता है, tokens की गिनती कभी नहीं। इसलिए नीचे जो कुछ नापा गया है वो tokens में है, एक वर्कलोड से, आपके हफ़्ते का हिस्सा नहीं।
लॉग से tokens गिनने में एक जाल है। लॉग एक ही जवाब को कई बार लिखता है, इसलिए हर लाइन जोड़ने पर 18.6 बिलियन tokens आते हैं। एक बार गिनने पर यह 9.3 बिलियन है। सीधी गिनती हर चीज़ को लगभग दोगुना कर देती है।
Subagents: लगभग आधा बिल
Subagent एक और Claude है जिसे आपका सेशन किसी साइड काम के लिए शुरू करता है, और काम खत्म होने पर वह रिपोर्ट लौटा देता है। नापे गए महीने में 2,631 रन में subagents ने सभी tokens का 48.1% लिया।
| नाप | Subagents का हिस्सा |
|---|---|
| सभी tokens | 48.1% |
| Output tokens | 63.9% |
| उस तरह तौला हुआ जैसे पब्लिक प्राइस लिस्ट output और cache writes को तौलती है | 55.3% |
हर subagent एक एंट्री कीमत भी चुकाता है। कुछ भी करने से पहले उसकी पहली रिक्वेस्ट में ही मीडियन 47,117 tokens होते हैं: निर्देश, टूल लिस्ट और skill लिस्ट, सब दोबारा भेजे हुए। किसी और ने अलग मशीन पर इसे नापा और उन agents के लिए जिनका अपना prompt बहुत छोटा है, हर लॉन्च पर 16,000 से 21,000 tokens पाए। उस आर्टिकल के शब्दों में, agent की फ़ाइल अपनी ही लॉन्च लागत के भीतर एक राउंडिंग एरर है।
मॉडल दूसरा आधा हिस्सा है। डिफ़ॉल्ट रूप से subagent मुख्य बातचीत का मॉडल इनहेरिट करता है, इसलिए सेशन को सबसे बड़े मॉडल पर करने से हर सहायक भी उसी पर चलता है। नापे गए लॉग में सबसे छोटे मॉडल ने subagent की 1% से कम रिक्वेस्ट संभालीं। फ़िक्स agent की फ़ाइल में एक लाइन है: model फ़ील्ड को टेस्ट चलाने या फ़ाइलें खोजने जैसे कामों के लिए छोटे मॉडल पर सेट करना।
इससे दो आदतें बनती हैं। जो छोटा काम आप खुद वहीं कर सकते हैं, उसके लिए subagent छोड़ दें, और जिन्हें रखें उन पर छोटा मॉडल पिन करें।
इस नतीजे की सीमा: किसी ने नहीं नापा कि पिन करने से हफ़्ते का कितना हिस्सा बचता है, और जिस छोटे मॉडल को ज़्यादा टर्न चाहिए वह ज़्यादा महँगा भी पड़ सकता है। 48% उस काम से आता है जो बहुत फैलता है। आपका अपना हिस्सा /usage स्क्रीन में है।
पाँच मिनट का cache जो किसी लिस्ट में नहीं
Claude Code आपकी बातचीत को सर्वर पर एक prompt cache में रखता है, और उसे वापस पढ़ना दोबारा भेजने की कीमत का एक छोटा हिस्सा पड़ता है। मुख्य सेशन के लिए वह cache एक घंटा रहता है। Subagent के लिए पाँच मिनट।
डॉक्यूमेंटेशन साफ़ कहता है: subagents को पाँच मिनट मिलते हैं, सब्सक्रिप्शन पर भी, जब तक आप लंबा न चुनें। यही बात मुख्य बातचीत के बाहर की हर चीज़ पर लागू होती है, बैकग्राउंड काम और compaction समेत। नापे गए लॉग भी यही कहते हैं: subagent की हर cache write पाँच मिनट वाली टियर पर गई, और मुख्य सेशन की हर write एक घंटे वाली टियर पर।
Reddit पर एक डेवलपर ने देखा कि इसका क्या असर होता है: उसके एक subagent ने एक ही दिन में अपना पूरा कॉन्टेक्स्ट आठ बार दोबारा लिखा। फ़िक्स सेटिंग्स फ़ाइल में एक लाइन है, "subagentPromptCacheTtl": "1h"।
| उसका नाप | पहले | बाद में |
|---|---|---|
| Cache writes | 12.2 मिलियन tokens | 3.0 मिलियन tokens |
| चार subagents के साथ पाँच घंटे की विंडो | 2% से 100% | 0% से 22% |
यह एक यूज़र है जो दो अलग दिनों की तुलना कर रहा है, कोई नियंत्रित टेस्ट नहीं। यहाँ नापे गए लॉग में इससे लगभग फ़र्क नहीं पड़ता: subagent की 41,790 फ़ॉलो-अप रिक्वेस्ट में से सिर्फ़ 95 (हर हज़ार में करीब दो) पाँच मिनट से ज़्यादा इंतज़ार के बाद आईं, हालाँकि हर एक ने लगभग 75,000 tokens दोबारा लिखे।
तो यह इस पर निर्भर है कि आपके subagents कैसे काम करते हैं। अगर वे किसी लंबे बिल्ड, किसी रिव्यू या आपका इंतज़ार करते हैं, तो इसे चालू करें। अगर वे छोटे झटकों में चलते हैं, तो छोड़ दें, क्योंकि एक घंटा चलने वाले cache को लिखना ज़्यादा महँगा पड़ता है।
वो ब्रेक जो पूरा सेशन दोबारा लिखवाता है
मुख्य सेशन का cache एक घंटा चलता है। इससे लंबे ब्रेक के बाद वह खत्म हो जाता है, और अगला मैसेज कुछ भी वापस नहीं पढ़ पाता। डॉक्यूमेंटेशन इसे साफ़ लिखता है: ब्रेक के बाद आप जो मैसेज भेजते हैं वह cache मिस करता है और आपका पूरा कॉन्टेक्स्ट दोबारा प्रोसेस करता है।
| मैसेज से पहले का विराम | रिक्वेस्ट | Cache दोबारा लिखा गया (मीडियन) |
|---|---|---|
| 5 मिनट से कम | 18,029 | 1,176 tokens |
| 5 से 60 मिनट | 414 | 1,327 tokens |
| 60 मिनट से ज़्यादा | 79 | 130,332 tokens |
उस पल एक आम सेशन में 175,523 tokens थे, इसलिए उसका ज़्यादातर हिस्सा दोबारा लिखा गया। मीटर write को read की तरह भी नहीं गिनता। एक डेवलपर ने Claude Code के आगे एक लॉगिंग प्रॉक्सी लगाई और अपनी पाँच घंटे की विंडो देखी: उसके अनुपात के हिसाब से cache में लिखा गया एक token उससे पढ़े गए token से करीब चालीस गुना भारी पड़ता है।
Claude Code यह जानता है। जब आप लंबे ब्रेक के बाद किसी बड़े सेशन को resume करते हैं, तो वह summary से resume करने का विकल्प देता है। उसे चुन लें।
सस्ती आदत पहले आती है। जब टास्क पूरा हो जाए, तो cache के गर्म रहते सेशन को clear कर दें। Clear करने में कुछ नहीं लगता और अगला टास्क छोटा शुरू होता है। Compact करना भी चलता है, लेकिन किसी विशाल सेशन को compact करना खुद एक विशाल रिक्वेस्ट है।
सिर्फ़ ब्रेक ही cache खोने का तरीका नहीं है। सेशन के बीच में मॉडल बदलने से वह खाली हो जाता है, क्योंकि हर मॉडल का अपना cache होता है। सबसे नए मॉडलों पर effort बदलने से ऐसा नहीं होता। Claude Code cache के गर्म रहते मॉडल बदलने की पुष्टि माँगता है, और वही प्रॉम्प्ट चेतावनी है।
सीमाएँ: 79 कोल्ड रिटर्न एक छोटा सैंपल है, और उनमें से कुछ compaction के बाद के हैं। Summary में कुछ विवरण भी खो जाता है, इसलिए इस फ़िक्स में थोड़ी निरंतरता जाती है।
Effort: वो फ़िक्स जो क्वालिटी की कीमत ले सकता है
Effort यह है कि जवाब देने से पहले मॉडल को कितनी देर सोचने दिया जाए। low से max तक पाँच लेवल हैं, और सोचने का बिल output की तरह लगता है। ज़्यादातर मॉडलों पर डिफ़ॉल्ट high है और सबसे नए दो पर medium।
डॉक्यूमेंटेशन कहता है कि सोचने का बजट हर रिक्वेस्ट पर दसियों हज़ार tokens तक पहुँच सकता है और सबसे ऊपर वाला लेवल ज़रूरत से ज़्यादा सोचने की ओर झुका रहता है। सबसे नए मॉडलों पर सोचना बंद ही नहीं किया जा सकता, इसलिए लेवल ही एकमात्र नियंत्रण है।
एक डेवलपर ने वही 29 असली टास्क पाँचों लेवल पर चलाए:
| Effort लेवल | प्रति टास्क औसत लागत | पास हुए टास्क (29 में से) |
|---|---|---|
| low | $2.50 | 23 |
| medium | $3.15 | 28 |
| high | $5.01 | 26 |
| xhigh | $6.51 | 25 |
| max | $8.84 | 27 |
क्वालिटी लागत के साथ नहीं चली। Medium ने ऊपर के किसी भी लेवल से ज़्यादा टास्क पास किए, और प्रति डॉलर भी सबसे ज़्यादा पास उसी ने दिए। उसके शब्दों में, कर्व medium पर चोटी बनाता दिखता है। Claude Code की टीम भी इसी तरह काम करती है: उसका एक इंजीनियर low या medium पर बनाता है, रिव्यू करता है, और वेरिफ़िकेशन सिर्फ़ high पर चलाता है।
पेच यही है कि यह फ़िक्स क्वालिटी की कीमत क्यों ले सकता है। उसके चुने कठिन problems पर low effort पाँच में से शून्य बार पास हुआ और high पाँच में से पाँच बार। एक low कोशिश में दो मिनट लगे, एक high में तैंतीस।
तो effort को कदम से मिलाएँ: बनाने के लिए medium, जब गलती महँगी हो तब high (पुराने कोड में बग, माइग्रेशन, आख़िरी जाँच), और max लगभग कभी नहीं। सेशन लॉग हर रिक्वेस्ट का effort दर्ज करते हैं, इसलिए आप जाँच सकते हैं कि असल में क्या चलाया।
ये लागतें एक पुराने मॉडल पर डॉलर में हैं, हफ़्ते का हिस्सा नहीं; यह किसी ने नहीं छापा। और जो सस्ती कोशिश फ़ेल होकर दो बार चलती है, वह एक चलने वाली कोशिश से ज़्यादा महँगी पड़ती है।
वो टिप्स जो दावे से हल्की निकलीं
कुछ फ़िक्स हर लिस्ट में हैं और सुई को मुश्किल से हिलाते हैं। उन्हें आज़माना मुफ़्त है। बस हफ़्ता वहाँ नहीं गया।
इस समूह में असली वो है जो शुरुआत में लोड होता है। एक आर्टिकल ने खाली फ़ोल्डर से पहली रिक्वेस्ट 29,061 tokens नापी, और असली प्रोजेक्ट के भीतर लगभग 39,000। यहाँ नापे गए लॉग में पहली रिक्वेस्ट का मीडियन 55,989 tokens है, जो प्रोजेक्ट के हिसाब से 15,764 से 105,020 तक जाता है। /context कमांड दिखाता है कि उसमें क्या है (memory फ़ाइलें, skills, टूल लिस्ट) और हर लोड हुई memory फ़ाइल का नाम बताता है। जो कभी इस्तेमाल नहीं करते उसे छाँट दें। फ़ायदा मामूली है क्योंकि वह ब्लॉक एक बार लिखा जाता है और उसके बाद हर टर्न पर cache से पढ़ा जाता है। यह कोल्ड स्टार्ट और हर subagent लॉन्च पर चुभता है।
| लोकप्रिय टिप | नापा हुआ |
|---|---|
| MCP सर्वर हटाना | तीन सर्वरों के 51 टूल्स के 1,350 tokens; एक टूल वाले एक सर्वर के 18 tokens |
| Prompt suggestions बंद करना | एक यूज़र के लिए 3 से 4%; "10% तक" का दावा विशाल कॉन्टेक्स्ट वाले एक अकाउंट से आया था |
| शेल आउटपुट फ़िल्टर करना | कुल वॉल्यूम का लगभग 0.1%, उन्हीं फ़िल्टरों में से एक के योगदानकर्ता ने नापा |
टूल की परिभाषाएँ अब डिफ़ॉल्ट रूप से deferred हैं, इसीलिए MCP सर्वर इतने हल्के पड़ते हैं। डॉक्यूमेंटेशन prompt suggestions की लागत को छोटा बताता है। तीनों आपके कॉन्टेक्स्ट के साइज़ के साथ बढ़ते हैं, और पुराने मॉडलों पर जहाँ deferral बंद है वहाँ सर्वर ज़्यादा खर्च करते हैं। चाहें तो इन्हें बंद कर दें, लेकिन हफ़्ता वापस मिलने की उम्मीद न रखें।
रैंक की हुई टेबल
जो नापा गया उसके हिसाब से क्रम:
| रैंक | फ़िक्स | नापा हुआ | पेच |
|---|---|---|---|
| 1 | कम और सस्ते subagents | 48.1% tokens; हर लॉन्च पर 47,117 | कम पैरेललिज़्म |
| 2 | कोल्ड सेशन resume न करें | 1,176 के मुकाबले 130,332 tokens दोबारा लिखे गए | Summary में विवरण खो जाता है |
| 3 | Effort: बनाने के लिए medium | प्रति टास्क $5.01 के मुकाबले $3.15; 29 में से 28 पास | कठिन problems पर low फ़ेल होता है |
| 4 | Subagent cache एक घंटे पर | 12.2 मिलियन से 3.0 मिलियन cache-write tokens | तभी फ़ायदा जब subagents इंतज़ार करें |
| 5 | शुरुआत में लोड होने वाली चीज़ें छाँटें | 29,061 की बेसलाइन पर +9,744 tokens | हर सेशन में एक बार चुकाना पड़ता है |
तीन लोकप्रिय टिप्स (MCP सर्वर, prompt suggestions, शेल आउटपुट) वो जगह नहीं हैं जहाँ हफ़्ता गया।
सीमाएँ, साफ़ शब्दों में: यह रैंकिंग tokens में है, एक व्यक्ति के काम के एक महीने से, साथ में दूसरे लोगों के नाप। Anthropic लिमिट का साइज़ tokens में नहीं छापता, इसलिए बाहर का कोई इन्हें आपके हफ़्ते के हिस्से में नहीं बदल सकता। आपका क्रम अलग हो सकता है, और /usage स्क्रीन आपको बता देगी।
दो सबसे बड़े फ़िक्स सेटिंग नहीं, आदतें हैं, और वे मुफ़्त हैं: कम subagents लॉन्च करें, और किसी कोल्ड सेशन को कभी पूरा resume न करें।
