Claude Code में लंबा काम शुरू करने से पहले: कब compact करें और सबएजेंट व उपयोग को कैसे नियंत्रित रखें

Claude Code को लगातार कोड पढ़ने, बदलाव करने और टेस्ट चलाने का काम देने से पहले कॉन्टेक्स्ट साफ़ करने की जल्दी न करें। लेकिन सिर्फ़ “पूरे 1M का इस्तेमाल” करने के लिए हर पुरानी चर्चा बचाकर रखना भी ज़रूरी नहीं है।

पहले कुछ ज़्यादा उपयोगी सवालों के जवाब खोजें: अगले कदम में मूल जानकारी का कौन-सा हिस्सा अभी भी चाहिए? जो काम आप सौंपने वाले हैं, क्या वह स्वतंत्र रूप से पूरा हो सकता है? काम खत्म होने पर कैसे तय करेंगे कि बदलाव से वास्तव में फायदा हुआ, न कि केवल उपयोग का आँकड़ा छोटा दिखाई देने लगा?

19 सितंबर को ZryMiller ने अपना बदला हुआ तरीका साझा किया। पहले वह बार-बार compact करते थे, फिर उन्होंने उस 1M विंडो को वापस अपनाया जिसे उन्होंने डिफ़ॉल्ट बताया। उनके अनुसार अनुभव काफी बेहतर हुआ, और वह अपना पहला ऐप रिलीज़ करने की तैयारी कर रहे थे। लेकिन पोस्ट में तुलना योग्य कार्य, पहले और बाद के उपयोग के आँकड़े, या ऐप के आखिरकार रिलीज़ होने का परिणाम नहीं था। यह उपयोगी निजी अनुभव है, पर इससे यह निष्कर्ष नहीं निकलता कि “कॉन्टेक्स्ट को compact न करने पर हर लंबा काम बेहतर होता है।”

“बार-बार compact करें” और “कभी compact न करें” में से एक चुनने के बजाय, काम के किसी ठोस चरण के अंत पर यह फैसला लें।

पहले पुष्टि करें कि आप किस सेटअप का इस्तेमाल कर रहे हैं

टर्मिनल में claude --version चलाकर क्लाइंट का संस्करण लिख लें। सेशन के भीतर /status से अकाउंट और मौजूदा मॉडल देखें, /model से उपलब्ध मॉडल और संबंधित सेटिंग्स जाँचें, फिर /context से देखें कि कॉन्टेक्स्ट कितना भरा है। उपयोग की जानकारी चाहिए तो /usage चलाएँ। ये कमांड अलग-अलग जानकारी दिखाते हैं; इन्हें एक ही माप का अलग रूप न समझें। आधिकारिक कमांड संदर्भ · उपयोग की जानकारी

इस चर्चा में मॉडल का आधिकारिक नाम Claude Fable 5.1 है। Claude API में इसका मॉडल ID claude-fable-5-1 है, और आधिकारिक स्पेसिफ़िकेशन में इसकी कॉन्टेक्स्ट विंडो 1M टोकन बताई गई है। मॉडल, Claude Code का संस्करण और effort सेटिंग अलग-अलग बातें हैं। रिकॉर्ड में केवल “Fable इस्तेमाल किया” या “Ultra इस्तेमाल किया” न लिखें। मॉडल का आधिकारिक स्पेसिफ़िकेशन

किसी मॉडल का 1M सपोर्ट करना यह नहीं बताता कि हर अकाउंट, मॉडल और कनेक्शन के तरीके पर इस्तेमाल की शर्तें अपने-आप एक जैसी होंगी। उदाहरण के लिए, आधिकारिक दस्तावेज़ के अनुसार Opus का 1M एक्सेस Max, Team और Enterprise में शामिल है, जबकि Pro पर usage credits चाहिए। सब्सक्रिप्शन प्लान पर Sonnet 4.6 की 1M विंडो के लिए भी usage credits चाहिए। इन नियमों को सीधे दूसरे मॉडल पर लागू न करें। क्लाइंट कॉन्फ़िगरेशन, मॉडल मैपिंग और गेटवे सपोर्ट भी जाँचना होगा; चयनकर्ता में [1m] जोड़ देने से सर्वर पर मौजूद मॉडल की क्षमता अपने-आप नहीं बढ़ती। 1M की शर्तें और मॉडल कॉन्फ़िगरेशन

तीन आसानी से गड्डमड्ड हो जाने वाले आँकड़ों का फर्क भी समझें। कॉन्टेक्स्ट उपयोग बताता है कि मौजूदा अनुरोध में कितनी सामग्री समानी है। कुल टोकन उपयोग यह दर्ज करता है कि अनुरोधों ने कितना इनपुट, आउटपुट और कैश की गई सामग्री प्रोसेस की। सब्सक्रिप्शन कोटा संबंधित उपयोग-अवधि में अकाउंट पर लागू सीमा है। पाँच घंटे या एक सप्ताह कोटा गिनने की अवधि है, इस बात की गारंटी नहीं कि काम लगातार पाँच घंटे या एक सप्ताह चल सकेगा। कैश में मिली सामग्री भी कॉन्टेक्स्ट में जगह लेती है, भले ही API बिलिंग में उसके लिए अलग कैश दर लागू हो। इसलिए “कॉन्टेक्स्ट का 30% इस्तेमाल हुआ” को “पाँच घंटे के कोटे का 30% खर्च हुआ” में नहीं बदला जा सकता। 1M ऐसा टोकन कोटा भी नहीं है जिसे बार-बार मुफ़्त प्रोसेस किया जा सके। कॉन्टेक्स्ट और कैशिंग · API की मूल्य संरचना

compact करने से पहले देखें कि अगले कदम को किन बातों की ज़रूरत है

मान लें कि आप ऐसी त्रुटि की जाँच कर रहे हैं जो फ़्रंटएंड, API और डेटाबेस तक फैली हुई है। अभी पढ़े गए कुछ कोड अंश, एक विफल अनुरोध और एक सीमांत स्थिति से अभी कोई दोबारा जाँचा जा सकने वाला निष्कर्ष नहीं निकला है। सिर्फ़ इसलिए compact करना कि “चैट लंबी हो गई है”, उन विवरणों को हटा सकता है जिनकी अगले कदम में तुलना करनी है।

इसके उलट, अगर मूल कारण स्पष्ट है, संबंधित फ़ाइलें और सबूत का स्थान दर्ज हैं, और आगे केवल तय योजना के अनुसार छोटा-सा बदलाव करना है, तो पहले हुई बहुत-सी खोज को मौजूदा विंडो में रखना शायद ज़रूरी न हो।

compact करने का सही समय किसी सार्वभौमिक प्रतिशत से तय नहीं होता। सही स्थिति वह है जब एक चरण पूरा हो चुका हो और भरोसेमंद रिकॉर्ड के आधार पर आगे बढ़ा जा सके। यह काम करने के तरीके की सलाह है, मॉडल की कोई निश्चित सीमा नहीं।

पहले Claude से अपने बताए हुए कार्य-रिकॉर्ड में ज़रूरी स्थिति लिखवाएँ: पुष्ट तथ्य और सबूत के स्थान, वास्तव में बदली गई फ़ाइलें, चलाई गई जाँचें और उनके असली परिणाम, अनसुलझे प्रश्न तथा अगला कदम। पूरी चैट दोहराने की ज़रूरत नहीं है। जिन अनुमानों की पुष्टि नहीं हुई है, उन्हें निष्कर्ष के रूप में भी न लिखें।

फिर मूल /compact कमांड का इस्तेमाल करें और स्पष्ट करें कि क्या बचाना है: compact कैसे काम करता है

/compact मौजूदा लक्ष्य, पुष्ट निष्कर्ष और सबूत के स्थान, बदली गई फ़ाइलें, चलाई गई जाँचें और उनके असली परिणाम, अनसुलझे प्रश्न तथा अगला कदम सुरक्षित रखें। दोहराई गई खोज और पहले ही खारिज की जा चुकी चर्चाएँ हटा दें।

यह सारांश के लिए निर्देश है, “कोई जानकारी नहीं खोएगी” की गारंटी नहीं। बदलाव जारी रखने से पहले Claude से compact किए गए कॉन्टेक्स्ट के आधार पर अगला कदम समझाने को कहें। फिर मुख्य शर्तों को वास्तविक फ़ाइलों और कार्य-रिकॉर्ड से मिलाएँ। कोई सीमांत स्थिति छूट गई हो तो उसे पहले वापस जोड़ें, न कि गलत दिशा में कार्यान्वयन हो जाने के बाद दोबारा काम करें।

अगर अगला काम पिछले काम से असंबंधित है, तो मौजूदा परिणाम और आगे जारी रखने के लिए ज़रूरी जानकारी सहेजकर /clear से नया सेशन शुरू करना आम तौर पर अधिक सीधा तरीका है। पुरानी बातचीत पर लौटना हो तो /resume इस्तेमाल करें। सेशन साफ़ करने से पहले हो चुका उपयोग वापस नहीं मिलता और सब्सक्रिप्शन का कोटा रीसेट नहीं होता। सेशन कमांड · उपयोग के डिस्प्ले में क्या रीसेट होता है

Claude Code में पहले से स्वचालित compaction मौजूद है, इसलिए इस तरीके को अपनाने के लिए प्लगइन लगाना ज़रूरी नहीं। v2.1.221 और बाद के संस्करणों में /autocompact भी है: बिना आर्ग्युमेंट यह मौजूदा स्वचालित compaction विंडो दिखाता है; /autocompact auto मॉडल के लिए तय की गई विंडो सेटिंग वापस लागू करता है। दूसरा कमांड सेटिंग सहेजता है, केवल मॉडल के सामने पसंद व्यक्त नहीं करता। मॉडल की अधिकतम कॉन्टेक्स्ट विंडो और स्वचालित compaction विंडो एक ही चीज़ नहीं हैं। स्वचालित compaction कमांड

HKTECH_AI ने अनुमान लगाया था कि एक बार compact करने से पाँच घंटे के कोटे का लगभग 15% खर्च हो सकता है। पोस्ट में बिल या गणना का तरीका नहीं दिया गया था, इसलिए इस प्रतिशत को काम करने का नियम न बनाएँ। असली तुलना यह होनी चाहिए: क्या compact करने से बाद के अनुरोधों में बार-बार भेजी जाने वाली सामग्री कम हुई, और क्या इसके कारण फिर से पढ़ने, समझाने या गलतियाँ सुधारने की ज़रूरत पड़ी?

सबएजेंट काम बाँट सकते हैं, लेकिन “एक बार में एक” कैसे लागू होता है, यह समझें

SHCH ने भूमिकाओं का एक बँटवारा साझा किया था: Fable योजना और निर्णय संभालता है, Sonnet पर चलने वाला Scout खोज करता है, और Opus पर चलने वाला Builder स्पष्ट रूप से परिभाषित काम करता है। उन्होंने खास तौर पर एक बार में केवल एक सबएजेंट बुलाने की सलाह दी।

उनके सार्वजनिक Builder स्क्रीनशॉट में पहले से तय योजना का पालन करने, योजना में समस्या हो तो रुककर बताने, आगे और सबएजेंट न चलाने तथा जाँच के परिणाम बताने पर ज़ोर था। इन निर्देशों का फायदा जिम्मेदारियाँ स्पष्ट करने में है। लेकिन चित्र में लिखा “आगे और सबएजेंट न चलाएँ” अभी भी प्रॉम्प्ट में दी गई पाबंदी है, सॉफ़्टवेयर द्वारा लागू सीमा नहीं। लेखक ने कई मुख्य सेशन चलाने का भी उल्लेख किया और जाँचे जा सकने वाले पहले-बाद के उपयोग आँकड़े नहीं दिए। इसलिए इस सेटअप का अर्थ “पूरे अकाउंट में केवल एक एजेंट” नहीं निकाला जा सकता, और न ही किसी निश्चित प्रतिशत की बचत का वादा किया जा सकता है।

सामान्य सबएजेंट अलग कॉन्टेक्स्ट से शुरू होता है। उसे सौंपा गया काम और संबंधित कॉन्फ़िगरेशन मिलते हैं, मुख्य सेशन की पूरी चैट-हिस्ट्री अपने-आप नहीं मिलती। मौजूदा बातचीत fork सबएजेंट को विरासत में मिलती है। विस्तृत खोजबीन सबएजेंट को सौंपने से मुख्य सेशन में रखी जाने वाली प्रक्रिया-संबंधी जानकारी कम हो सकती है, लेकिन सबएजेंट के अपने अनुरोध भी टोकन प्रोसेस करते हैं, और उसका लौटाया हुआ परिणाम मुख्य सेशन में शामिल होता है। सबएजेंट के कॉन्टेक्स्ट की सीमाएँ

इसलिए “एक साथ कितने चलाएँ?” से पहले पूछें, “क्या यह काम सौंपना उचित है?” किसी साधारण खोज के लिए योजनाकार, शोधकर्ता और कार्यान्वयनकर्ता की पूरी श्रृंखला की ज़रूरत नहीं। एक ही फ़ाइल बार-बार बदलने वाले दो काम भी जरूरी नहीं कि साथ किए जाएँ। वास्तव में स्वतंत्र जाँचें, जिनके अपेक्षित परिणाम स्पष्ट हों, समानांतर तुलना के लिए अधिक उपयुक्त हैं।

काम के निर्देश अधिक ठोस बनाए जा सकते हैं, जैसे:

लक्ष्य: इस बार के सहमत बदलाव पूरे करें और उनसे सीधे संबंधित जाँचें पास करें।
बदलाव की अनुमत सीमा: इस अनुरोध से जुड़ा कार्यान्वयन और उसके संबंधित टेस्ट।
काम करने का तरीका: साधारण खोज सीधे पूरी करें। काम सौंपना वास्तव में ज़रूरी हो तो केवल उस उपकार्य के लिए आवश्यक संदर्भ और अपेक्षित परिणाम दें; एक बार में एक सबएजेंट लगाएँ। प्रतीक्षा के दौरान एक ही स्थिति बार-बार न पूछें।
पूरा होने की शर्त: स्वीकृति की आवश्यकताओं के अनुसार परिणाम दें और संबंधित जाँचें पास होते ही रुक जाएँ। रुकावट हो तो बताएँ कि क्या पूरा हुआ और काम क्यों अटका है; वही काम फिर से शुरू न करें।

ये अभी भी व्यवहार संबंधी निर्देश हैं। मूल सबएजेंट बनाए जाने पर वास्तविक रोक लगानी हो तो क्लाइंट के नियंत्रण इस्तेमाल करें। Claude Code v2.1.217 और बाद के संस्करण एक साथ चलने वाले सबएजेंट और काम सौंपने की गहराई पर सीमा लगाने देते हैं। macOS और Linux के Bash/Zsh के लिए नीचे दिया गया लॉन्च उदाहरण अनावश्यक समानांतर काम की जाँच शुरू करने का एक सावधान तरीका है: एनवायरनमेंट वैरिएबल संदर्भ

CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS=1 \
CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH=1 \
claude

पहला वैरिएबल एक सेशन में Agent टूल से नए सबएजेंट बनाते समय एक साथ चलने की सीमा जाँचता है। दूसरा सबएजेंट को एक स्तर तक सीमित करता है, ताकि वह आगे और सबएजेंटों को काम न सौंप सके। ये प्रॉम्प्ट नहीं हैं, और पहले से चल रहे दूसरे सेशन पर पीछे से लागू नहीं होते। एनवायरनमेंट वैरिएबल संदर्भ

लेकिन यह ऐसी वैश्विक लॉक व्यवस्था नहीं है जो “हर जगह, हमेशा, अधिकतम एक एजेंट” की गारंटी दे। आधिकारिक दस्तावेज़ अपवाद साफ़ बताते हैं: ultracode सेशन इस समवर्ती सीमा को लागू नहीं करते; हाथ से चलाया गया /subtask और पहले से पूरे हो चुके सबएजेंट को फिर चालू करना उसी नए-निर्माण जाँच से नहीं रोका जाता; वर्कफ़्लो और agent teams की अपनी सीमाएँ हैं। कई मुख्य सेशन और बाहर से शुरू किए गए प्रोसेस भी इस एक सेटिंग से सामूहिक रूप से नियंत्रित नहीं होते। समवर्ती सीमाएँ और अपवाद

अपने शेड्यूलर में वास्तविक वैश्विक सीमा चाहिए तो शुरू करने, फिर जारी करने और दोबारा प्रयास करने को एक साझा कतार या समवर्ती लॉक से नियंत्रित करें। केवल प्रॉम्प्ट में “एक बार में एक” लिखना पर्याप्त नहीं। यह आपके अपने शेड्यूलर का कार्यान्वयन है, Claude Code की कोई और अनबताई सेटिंग नहीं।

परिणाम की प्रतीक्षा का मतलब मॉडल से लगातार प्रगति पूछवाना नहीं है

LeeLeepenkman की शिकायत सिर्फ़ “सबएजेंट इस्तेमाल करने” की नहीं थी। उन्होंने बताया कि Fable 5.1 पहले muse को बड़ा प्रॉम्प्ट देता था, फिर लगभग हर पाँच सेकंड में स्थिति पूछता था, जिससे कॉन्टेक्स्ट तेजी से बढ़ता था। मूल पोस्ट में muse का कार्यान्वयन, अनुरोधों का रिकॉर्ड या समस्या सुलझने के बाद का परिणाम नहीं था। इसलिए पाँच सेकंड को Claude Code का निश्चित polling अंतराल नहीं कहा जा सकता।

मौजूदा मूल बैकग्राउंड सबएजेंट काम पूरा होने की सूचना देते हैं, और परिणाम बाद के संवाद-चरणों में मुख्य सेशन को लौटाया जाता है। चल रहे काम देखने के लिए /tasks इस्तेमाल किया जा सकता है। यह मॉडल से बार-बार “क्या काम पूरा हो गया?” का नया अनुरोध करवाने से अलग है। बैकग्राउंड सबएजेंट और परिणाम की सूचनाएँ

जाँच के समय सेशन के टूल रिकॉर्ड खोलकर उसी काम को ट्रैक करें: क्या बार-बार की जाँच नई जानकारी दे रही है? क्या पूरा काम फिर शुरू कर दिया गया? क्या स्थिति जाँचने से वास्तव में नया मॉडल कॉल हुआ? Ctrl+O बातचीत का अधिक विस्तृत दृश्य खोलता है, लेकिन इंटरफ़ेस कितनी बार रीफ़्रेश हुआ, उसे मॉडल अनुरोधों की संख्या नहीं माना जा सकता। अनुरोध-स्तर का उपयोग चाहिए तो जिस प्रदाता से वास्तव में जुड़े हैं, उसके रिकॉर्ड भी मिलाएँ। इंटरैक्शन और सेशन दृश्य

मूल सूचनाएँ इस्तेमाल हो रही हों तो मॉडल से चलने वाला एक अतिरिक्त, बहुत बार जाँच करने वाला लूप आम तौर पर ज़रूरी नहीं होता। बाहरी टूल केवल polling सपोर्ट करता हो तो प्रोग्राम उचित अंतराल पर स्थिति बदलने की प्रतीक्षा कर सकता है, टाइमआउट रख सकता है, और केवल नया परिणाम या असामान्य स्थिति आने पर जानकारी मॉडल तक पहुँचा सकता है। उद्देश्य बिना नई जानकारी वाले मॉडल कॉल कम करना है, जरूरी प्रगति निगरानी रोकना नहीं।

कोटा रीसेट होने के बाद पहले देखें कि कौन-सा काम बाकी है

intwerpret ने अधिक गंभीर अनुभव बताया। उपयोग सीमा पर पहुँचने के बाद उन्होंने प्रतीक्षा करके अपने-आप जारी रहने का विकल्प चुना। उनके दावे के अनुसार इसके बाद 39 एजेंट दिखाई दिए, जिन्होंने कोटा फिर समाप्त कर दिया, और अंत में वह Codex पर लौट गए। सामग्री में क्लाइंट का संस्करण, कार्य का विवरण, पूरी कॉन्फ़िगरेशन या फिर शुरू करने की व्यवस्था का स्रोत नहीं है। यह भी पता नहीं कि काम आखिरकार पूरा हुआ या नहीं।

यह प्रतिक्रिया फिर शुरू करने की प्रक्रिया जाँचने की वजह देती है, लेकिन यह साबित नहीं करती कि “Claude Code का ऑटो-रिज़्यूम हमेशा 39 एजेंट शुरू करता है।” लेखक का “Ultra” कहना भी यह साबित करने के लिए पर्याप्त नहीं कि उस समय ऊपर बताया गया ultracode मोड चल रहा था।

दूसरी ओर, अब हर स्वतः जारी होने वाले व्यवहार को तीसरे पक्ष की स्क्रिप्ट का काम भी नहीं माना जा सकता। आधिकारिक इंटरैक्शन दस्तावेज़ मूल “उपयोग सीमा रीसेट होने पर जारी रखें” क्षमता दर्ज करते हैं। v2.1.234 से, पात्र इंटरैक्टिव सब्सक्रिप्शन सेशन कोटा रीसेट होने की प्रतीक्षा करके काम जारी रख सकते हैं। यह API Key, -p या हर बैकग्राउंड मोड के व्यवहार के समान नहीं है। फिर जारी होने का अर्थ उपयोगकर्ता का आखिरी मूल कार्य फिर भेज देना भी नहीं है। मूल प्रतीक्षा और स्वचालित जारी रहना

अगर आप काम को बिना निगरानी फिर शुरू नहीं होने देना चाहते, तो /config में Continue automatically at usage limit (उपयोग सीमा रीसेट होने पर अपने-आप जारी रखें) बंद करें। यह सेटिंग सपोर्ट करने वाले संस्करण में सीधे यह भी चलाया जा सकता है:

/config autoContinueAtUsageLimit=false

सेशन पहले से प्रतीक्षा में हो तो उस खास प्रतीक्षा को भी रद्द करें: खाली इनपुट बॉक्स में Esc दबाएँ या /rate-limit-options में Don’t continue automatically (अपने-आप जारी न रखें) चुनें। डिफ़ॉल्ट सेटिंग बदलना और पहले से चुनी गई प्रतीक्षा रद्द करना अलग काम हैं। स्वचालित जारी रहने को रद्द करना और सेट करना

इसके बाद /tasks और फ़ाइलों की वास्तविक स्थिति देखें। कौन-से काम अभी चल रहे हैं, कौन-से पूरे हैं, और किन्हें केवल एक और सत्यापन चाहिए? मौजूद परिणाम दोबारा इस्तेमाल करें और अधूरे काम का अगला लक्ष्य स्पष्ट करें। पूरी माँग फिर से न भेजें, जिससे काम एक बार और छोटे हिस्सों में बाँटा जाए।

खास तौर पर कमिट, डिप्लॉयमेंट, संदेश भेजने या बाहरी असर वाले किसी कदम से पहले पुष्टि करें कि पिछला प्रयास सफल हुआ था या नहीं। कोटा रीसेट केवल यह तय करता है कि “अब अनुरोध जारी हो सकते हैं या नहीं”; यह गारंटी नहीं देता कि “आगे कोई काम दोबारा नहीं होगा।”

उपयोग बेहतर हुआ या नहीं, तय करने से पहले पूरा परिणाम देखें

chasemdev ने बताया था कि वह Fable से हर समय खुद कोड नहीं लिखवा रहे थे, बल्कि उससे Opus सबएजेंटों का समन्वय करवा रहे थे। फिर भी उन्हें जल्द साप्ताहिक सीमा तक पहुँचने की आशंका थी। यहाँ “जल्द” लेखक का उस समय का अनुमान था, सत्यापित अंतिम उपयोग नहीं। लेकिन इससे वह हिस्सा याद आता है जो रिकॉर्ड में छूट सकता है: केवल मुख्य मॉडल नहीं, सबएजेंटों के मॉडल और उनका काम भी गिनें।

मौजूदा /usage का Session भाग सेशन का टोकन उपयोग और स्थानीय रूप से निकाला गया लागत अनुमान दिखाता है। सब्सक्रिप्शन उपयोगकर्ताओं को उसी इंटरफ़ेस में प्लान का उपयोग भी दिखता है। Session में डॉलर की संख्या सब्सक्रिप्शन का बिल नहीं है, और यह API प्रदाता की अंतिम कटौती के बराबर भी जरूरी नहीं है। उपयोग के हिसाब से भुगतान करने वाले उपयोगकर्ता अपने वास्तविक प्रदाता का बिल मानें। इस समय /usage का अर्थ

सब्सक्रिप्शन उपयोग का स्थानीय बँटवारा भी केवल एक संकेत है। सबएजेंट, प्लगइन, स्किल आदि का विवरण इसी मशीन की हाल की हिस्ट्री से आता है। यह अन्य डिवाइस और वेब का पूरा उपयोग नहीं बताता, और न ही यह कारण-सहित प्रमाण है कि “किसी प्लगइन ने कितना उपयोग बेकार किया।” Showing last-known usage दिखाई दे तो दिखाए जा रहे डेटा का समय लिखें और तुलना से पहले रीफ़्रेश करें। उपयोग के बँटवारे का दायरा और कैश आँकड़े

इसके लिए जटिल मूल्यांकन प्रणाली बनाने की ज़रूरत नहीं। स्पष्ट दायरे वाला ऐसा काम चुनें जिसे सुरक्षित रूप से दोहराया जा सके। पहले उसकी स्वीकृति शर्तें लिखें और शुरुआत तथा अंत में ये रिकॉर्ड लें:

क्या दर्ज करें	किन सवालों के जवाब चाहिए
काम, शुरुआत का कोड संस्करण, मॉडल, effort, क्लाइंट संस्करण	क्या पहले और बाद में एक ही तरह के काम और सेटिंग्स की तुलना हो रही है?
/context और compaction प्रक्रिया	क्या कोई शर्त छूटी, दोबारा पढ़ना पड़ा या फिर समझाना पड़ा?
सबएजेंट और प्रतीक्षा का व्यवहार	कौन-से काम नए बने या फिर शुरू हुए, एक साथ अधिकतम कितने चले, और क्या बिना नई जानकारी वाली जाँचें दोहराई गईं?
उपयोग के आँकड़े, समय और रीसेट की सीमा	क्या बीच में कोटा रीसेट हुआ, क्या दूसरे सेशन का उपयोग मिला, और क्या API में सभी संबंधित मॉडल गिने गए?
वास्तविक डिलिवरी और जाँच परिणाम	क्या आवश्यकताएँ पूरी हुईं, संबंधित जाँचें पास हुईं, और कितना मानव-संचालित दोबारा काम बाकी है?

केवल एक तरीका बदलें, जैसे जाँच पूरी होने के बाद compact करना या नए सबएजेंटों की समवर्ती संख्या सीमित करना। मूल स्वीकृति शर्तें बनाए रखें; कम उपयोग दिखाने के लिए चुपचाप कार्य का दायरा न घटाएँ। तुलना में यह भी दर्ज करें कि कैश की स्थिति अलग थी या नहीं। दोनों बार अलग मॉडल, कोड संस्करण या काम का आकार हो तो पूरे अंतर का कारण compact को न मानें।

कुछ टोकन बच गए लेकिन आवश्यकताएँ छूट गईं या सत्यापन इंसान पर छोड़ दिया गया, तो यह सुधार नहीं है। दूसरी तरफ, अधिक कॉन्टेक्स्ट रखने से काम एक ही प्रयास में, बिना दोबारा जाँचबीन के पूरा हो गया हो, तो केवल विंडो अधिक भरी होने के आधार पर उसे बर्बादी नहीं कहा जा सकता।

अलग API एक्सेस और सब्सक्रिप्शन का हिसाब खास तौर पर अलग रखें। बिलिंग का स्रोत बदलने से मूल सब्सक्रिप्शन का कोटा रीसेट नहीं होता, न ही क्लाइंट का काम सौंपना, प्रतीक्षा करना और compact करना अपने-आप बदलता है। यह तय करने के लिए कि बदलाव उचित है या नहीं, एक ही काम पूरा करने का कुल उपयोग और दोबारा करना पड़ा काम तुलना में लें, केवल किसी मॉडल की इकाई कीमत नहीं। बिलिंग के तरीकों का अंतर · API टोकन बिलिंग संरचना

compact का फैसला प्लगइन को देने से पहले देखें कि वह बाहर क्या भेजता है

Kun Chen का शुरुआती सवाल व्यावहारिक था: “when should i /compact my session” — मौजूदा सेशन को कब compact करना चाहिए? उनका compact-adviser TypeSafe के Jev से तय करता है कि काम किसी ऐसे चरण पर पहुँचा है या नहीं जहाँ compact करना उचित हो। इसमें सुझाव वाला मोड और सक्रिय रूप से चुनना पड़ने वाला स्वचालित मोड है। प्रोजेक्ट का विवरण

इस लेख की जाँच कमिट d1655faa16a22b68bff60c3d7deb0123e1e52a53 पर तय की गई थी। उसमें Claude Code प्लगइन मैनिफ़ेस्ट का संस्करण 0.1.4 है। प्रोजेक्ट को Node.js 22 या बाद का संस्करण और Claude Code 2.1.274 या बाद का संस्करण चाहिए; प्रोजेक्ट के अनुसार 2.1.275 पर सत्यापन किया गया है। Claude Code का इंटीग्रेशन प्रयोगात्मक function hooks पर निर्भर है और इसके लिए CLAUDE_CODE_ENABLE_FUNCTION_HOOKS=1 चाहिए। ये प्रोजेक्ट द्वारा बताई गई संगतता शर्तें हैं, इस लेख के लिए इंस्टॉल करके किए गए परीक्षण के परिणाम नहीं। तय संस्करण का मैनिफ़ेस्ट · संस्करण और इंटीग्रेशन की आवश्यकताएँ

अधिक महत्वपूर्ण बात यह है कि hint मोड का मतलब केवल यह है कि compact अपने-आप नहीं होगा। इसका मतलब स्थानीय निर्णय या कॉन्टेक्स्ट बाहर न भेजना नहीं है। प्रोजेक्ट का सुरक्षा दस्तावेज़ कहता है कि इंस्टॉल होने के बाद, लॉन्च एनवायरनमेंट, सहेजी गई सेटिंग्स या कार्य-डायरेक्टरी की .env फ़ाइल से Key मिल जाए और कॉल की शर्तें पूरी हों, तो सेशन के चुने हुए अंश TypeSafe भेजे जाते हैं। इनमें उपयोगकर्ता की शर्तें, हाल के दिखाई देने वाले उत्तर और टूल परिणाम, मौजूद सारांश और बने हुए आउटपुट के नाम शामिल हैं। साझा करने की पुष्टि का कोई अलग स्विच नहीं है। इन अंशों में कोड या कारोबारी जानकारी हो सकती है; संवेदनशील जानकारी हटाने का यथासंभव प्रयास, उसके पूरी तरह अनुपस्थित होने की गारंटी नहीं है। कॉन्टेक्स्ट बाहर भेजने की सीमा

जिन्होंने प्लगइन इंस्टॉल किया है, वे /compact-adviser off से बंद कर सकते हैं, या इस तरह शुरू कर सकते हैं:

COMPACT_ADVISER_DISABLE=1 claude

प्रोजेक्ट के अनुसार इससे प्लगइन के अनुरोध, सुझाव और स्वचालित compaction रुकते हैं। इससे प्लगइन बंद होता है, Claude Code का अपना स्वचालित compaction नहीं। अगर काम की सामग्री अतिरिक्त रूप से TypeSafe भेजने की अनुमति नहीं है, तो प्लगइन बंद करें या अनइंस्टॉल करें; केवल auto से hint पर न बदलें। बंद करने का तरीका

लेखक द्वारा बताई गई 40 सेशन की जाँच प्रोजेक्ट की अपनी जाँच है, और उसका डेटासेट सार्वजनिक नहीं है। इससे यह गारंटी नहीं मिलती कि आपके काम के विवरण नहीं खोएँगे। प्लगइन “compact करना उचित है” बताए, तब भी अंतिम सवाल यही है कि उसके बाद काम सही तरह से जारी हो सकता है या नहीं। मूल्यांकन की सीमाएँ

बिना प्लगइन भी ये सब किया जा सकता है: काम के चरणों के अंत में स्थिति सहेजें और अगले कदम को सच में चाहिए वही विवरण रखें; सबएजेंटों को स्पष्ट, स्वतंत्र काम दें; प्रतीक्षा और फिर जारी होने के समय दोबारा शुरुआत से बचें; और परिणाम तथा उपयोग रिकॉर्ड, दोनों से असर का आकलन करें।

लंबे काम के प्रबंधन का लक्ष्य विंडो भरना या हर अनुरोध को सबसे सस्ता दिखाना नहीं है। लक्ष्य वह काम कम करना है जो कार्य को आगे नहीं बढ़ाता, और जो शुरू किया है उसे भरोसेमंद ढंग से पूरा करना है।