Claude Code का उपयोग: सेशन मैनेजमेंट और 1M कॉन्टेक्स्ट

हाल ही में Claude Code उपयोगकर्ताओं के साथ मेरी बातचीत में, एक विषय बार-बार सामने आता है: 1M टोकन संदर्भ विंडो एक दोधारी तलवार है।

यह Claude Code को लंबे समय तक स्वायत्त रूप से काम करने और कार्यों को अधिक विश्वसनीय रूप से संभालने की अनुमति देता है, लेकिन यह संदर्भ प्रदूषण (context pollution) का द्वार भी खोलता है यदि आप अपने सत्रों के प्रबंधन में सावधान नहीं हैं।

सत्र प्रबंधन पहले से कहीं अधिक महत्वपूर्ण हो गया है और ऐसा लगता है कि इसके बारे में बहुत सारे प्रश्न हैं। क्या आप एक टर्मिनल में एक सत्र खुला रखते हैं, या दो? हर प्रॉम्प्ट के साथ नया शुरू करते हैं? आपको compact, rewind, या subagents का उपयोग कब करना चाहिए? खराब compact का कारण क्या है?

यहाँ आश्चर्यजनक रूप से बहुत सारी बारीकियाँ हैं जो वास्तव में Claude Code के साथ आपके अनुभव को आकार दे सकती हैं, और यह लगभग पूरी तरह से आपके संदर्भ विंडो के प्रबंधन से आता है।

संदर्भ, संक्षेपण (Compaction) और संदर्भ क्षय (Context Rot) पर एक त्वरित प्राइमर

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

दुर्भाग्य से, संदर्भ का उपयोग करने की एक छोटी सी लागत है, जिसे अक्सर संदर्भ क्षय (context rot) कहा जाता है। संदर्भ क्षय यह अवलोकन है कि जैसे-जैसे संदर्भ बढ़ता है, मॉडल का प्रदर्शन कम होता जाता है क्योंकि ध्यान अधिक टोकनों पर फैल जाता है, और पुरानी, अप्रासंगिक सामग्री वर्तमान कार्य से ध्यान भटकाने लगती है। हमारे 1MM संदर्भ मॉडल के लिए, हम लगभग ~300-400k टोकन के आसपास कुछ स्तर का संदर्भ क्षय देखते हैं, लेकिन यह कार्य पर अत्यधिक निर्भर है - कोई निश्चित नियम नहीं है।

संदर्भ विंडो एक कठोर सीमा है, इसलिए जब आप संदर्भ विंडो के अंत के करीब पहुँच रहे होते हैं, तो आपको उस कार्य को संक्षेप में प्रस्तुत करना होगा जिस पर आप काम कर रहे हैं, एक छोटे विवरण में, और एक नए संदर्भ विंडो में काम जारी रखना होगा, हम इसे संक्षेपण (compaction) कहते हैं। आप स्वयं भी संक्षेपण को ट्रिगर कर सकते हैं।

हर मोड़ एक शाखा बिंदु है

मान लीजिए कि आपने अभी-अभी Claude से कुछ करने के लिए कहा और उसने पूरा कर लिया, अब आपके संदर्भ में कुछ जानकारी है (टूल कॉल, टूल आउटपुट, आपके निर्देश) और आपके पास आगे क्या करना है, इसके लिए आश्चर्यजनक रूप से कई विकल्प हैं:

• जारी रखें (Continue) — उसी सत्र में एक और संदेश भेजें
• /rewind (esc esc) — पिछले संदेश पर वापस जाएँ और वहाँ से पुनः प्रयास करें
• /clear — एक नया सत्र शुरू करें, आमतौर पर एक संक्षिप्त विवरण के साथ जो आपने अभी सीखा है
• Compact — अब तक के सत्र का सारांश बनाएँ और उस सारांश के शीर्ष पर काम जारी रखें
• Subagents — काम के अगले भाग को एक एजेंट को सौंपें जिसका अपना साफ संदर्भ हो, और केवल उसका परिणाम वापस लाएँ

जबकि सबसे स्वाभाविक विकल्प केवल जारी रखना है, अन्य चार विकल्प आपके संदर्भ को प्रबंधित करने में मदद करने के लिए मौजूद हैं।

नया सत्र कब शुरू करें

नई 1M संदर्भ विंडो का मतलब है कि अब आप लंबे कार्यों को अधिक विश्वसनीय रूप से कर सकते हैं, उदाहरण के लिए, इसे शुरू से एक फुल-स्टैक ऐप बनाने के लिए कहना। लेकिन सिर्फ इसलिए कि आपके मॉडल का संदर्भ समाप्त नहीं हुआ है, इसका मतलब यह नहीं है कि आपको एक नया सत्र शुरू नहीं करना चाहिए।

हमारा सामान्य नियम यह है कि जब आप एक नया कार्य शुरू करते हैं, तो आपको एक नया सत्र भी शुरू करना चाहिए।

एक ग्रे एरिया तब होता है जब आप संबंधित कार्य करना चाहते हैं जहाँ कुछ संदर्भ अभी भी आवश्यक है, लेकिन सब कुछ नहीं।

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

सुधारने के बजाय रिवाइंड करना

अगर मुझे एक ऐसी आदत चुननी हो जो अच्छे संदर्भ प्रबंधन का संकेत देती है, तो वह है रिवाइंड (rewind)।

Claude Code में, Esc को दो बार दबाने (या /rewind चलाने) से आप किसी भी पिछले संदेश पर वापस जा सकते हैं और वहाँ से पुनः प्रॉम्प्ट कर सकते हैं। उस बिंदु के बाद के संदेश संदर्भ से हटा दिए जाते हैं।

रिवाइंड अक्सर सुधार के लिए बेहतर दृष्टिकोण होता है। उदाहरण के लिए, Claude पाँच फ़ाइलें पढ़ता है, एक दृष्टिकोण आज़माता है, और वह काम नहीं करता। आपकी प्रवृत्ति "वह काम नहीं किया, इसके बजाय X आज़माएँ" टाइप करने की हो सकती है, लेकिन बेहतर कदम फ़ाइल पढ़ने के ठीक बाद रिवाइंड करना है, और आपने जो सीखा है उसके साथ पुनः प्रॉम्प्ट करना है। "दृष्टिकोण A का उपयोग न करें, foo मॉड्यूल वह एक्सपोज़ नहीं करता है — सीधे B पर जाएँ।"

आप "यहाँ से सारांश बनाएँ" (summarize from here) का उपयोग करके Claude से अपनी सीख का सारांश बनाने और एक हैंडऑफ़ संदेश बनाने के लिए भी कह सकते हैं, जैसे कि Claude के पिछले संस्करण के लिए उसके भविष्य के स्व से एक संदेश जिसने कुछ आज़माया और वह काम नहीं किया।

कॉम्पैक्ट बनाम ताज़ा सत्र

एक बार जब कोई सत्र लंबा हो जाता है, तो आपके पास वजन कम करने के दो तरीके होते हैं: /compact या /clear (और ताज़ा शुरू करें)। वे समान लगते हैं लेकिन बहुत अलग व्यवहार करते हैं।

Compact मॉडल से अब तक की बातचीत का सारांश बनाने के लिए कहता है, फिर इतिहास को उस सारांश से बदल देता है। यह हानिपूर्ण (lossy) है, आप Claude पर भरोसा कर रहे हैं कि वह तय करे कि क्या मायने रखता है, लेकिन आपको खुद कुछ लिखना नहीं पड़ा और Claude महत्वपूर्ण सीख या फ़ाइलों को शामिल करने में अधिक संपूर्ण हो सकता है। आप निर्देश पास करके इसे निर्देशित भी कर सकते हैं (/compact focus on the auth refactor, drop the test debugging)।

/clear के साथ, आप लिखते हैं कि क्या मायने रखता है ("हम auth मिडलवेयर को रीफैक्टर कर रहे हैं, बाधा X है, मायने रखने वाली फ़ाइलें A और B हैं, हमने दृष्टिकोण Y को खारिज कर दिया है") और साफ शुरू करते हैं। यह अधिक काम है, लेकिन परिणामी संदर्भ वही है जो आपने तय किया कि प्रासंगिक है।

खराब कॉम्पैक्ट का कारण क्या है?

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

उदाहरण के लिए, ऑटोकॉम्पैक्ट एक लंबे डिबगिंग सत्र के बाद चालू होता है और जांच का सारांश बनाता है, और आपका अगला संदेश है "अब bar.ts में हमने जो दूसरी चेतावनी देखी थी, उसे ठीक करें।"

लेकिन क्योंकि सत्र डिबगिंग पर केंद्रित था, दूसरी चेतावनी सारांश से हटा दी गई हो सकती है।

यह विशेष रूप से कठिन है, क्योंकि संदर्भ क्षय के कारण, मॉडल कॉम्पैक्ट करते समय अपने सबसे कम बुद्धिमान बिंदु पर होता है। दस लाख संदर्भ के साथ, आपके पास /compact को सक्रिय रूप से करने के लिए अधिक समय है, जिसमें आप जो करना चाहते हैं उसका विवरण शामिल हो।

उप-एजेंट और ताज़ा संदर्भ विंडो

उप-एजेंट (Subagents) संदर्भ प्रबंधन का एक रूप हैं, जो तब उपयोगी होते हैं जब आप पहले से जानते हैं कि काम का एक हिस्सा बहुत सारा मध्यवर्ती आउटपुट उत्पन्न करेगा जिसकी आपको फिर से आवश्यकता नहीं होगी।

जब Claude Agent टूल के माध्यम से एक उप-एजेंट को स्पॉन करता है, तो उस उप-एजेंट को अपनी स्वयं की ताज़ा संदर्भ विंडो मिलती है। वह जितना आवश्यक हो उतना काम कर सकता है, और फिर अपने परिणामों को संश्लेषित कर सकता है ताकि केवल अंतिम रिपोर्ट मूल (parent) के पास वापस आए।

हम जिस मानसिक परीक्षण का उपयोग करते हैं: क्या मुझे इस टूल आउटपुट की फिर से आवश्यकता होगी, या केवल निष्कर्ष की?

जबकि Claude Code स्वचालित रूप से उप-एजेंटों को कॉल करेगा, आप इसे स्पष्ट रूप से ऐसा करने के लिए कहना चाह सकते हैं। उदाहरण के लिए, आप इसे यह बता सकते हैं:

• "निम्नलिखित spec फ़ाइल के आधार पर इस कार्य के परिणाम को सत्यापित करने के लिए एक उप-एजेंट स्पॉन करें"
• "एक उप-एजेंट को स्पॉन करें जो इस अन्य कोडबेस को पढ़े और संक्षेप में बताए कि उसने auth फ़्लो को कैसे लागू किया, फिर इसे स्वयं उसी तरह लागू करें"
• "मेरे git बदलावों के आधार पर इस सुविधा पर दस्तावेज़ लिखने के लिए एक उप-एजेंट को स्पॉन करें"

सारांश

संक्षेप में, जब Claude ने एक मोड़ पूरा कर लिया है और आप एक नया संदेश भेजने वाले हैं, तो आपके पास एक निर्णय बिंदु है।

समय के साथ हम उम्मीद करते हैं कि Claude इसे स्वयं संभालने में आपकी मदद करेगा, लेकिन अभी के लिए, यह उन तरीकों में से एक है जिनसे आप Claude के आउटपुट को निर्देशित कर सकते हैं।