विषय-सूची

Claude Code का /compact ऐसी चीज़ नहीं है जिसे आप टाइमर से दबाएँ। दबाने का सही पल है काम का पड़ाव — एक टास्क खत्म, अगला शुरू होने ही वाला है। आधिकारिक दस्तावेज़ यही बात साफ़ शब्दों में कहते हैं: काम के किसी स्वाभाविक पड़ाव पर /compact चलाएँ, जैसे दो टास्क के बीच में, बजाय इसके कि आप टास्क के बीचोंबीच ऑटो-कॉम्पैक्शन के चलने का इंतज़ार करें (Claude Code दस्तावेज़, "Prompt caching")।

"हर 30 मिनट पर दबाओ" या "कॉन्टेक्स्ट 70% पार कर जाए तो दबाओ" जैसे नियम गलत निशाने पर लगे हैं। बाकी लेख इसकी वजह खोलकर बताता है, पर छोटा जवाब यह है: कॉम्पैक्शन की कीमत और उसका नुकसान इससे तय नहीं होता कि आपने कब दबाया, बल्कि इससे कि आपने क्या फेंका और cache गर्म था या नहीं।

📌 ये तथ्य कहाँ से आए: नीचे दिए हर स्पेसिफिकेशन, वर्ज़न नंबर और सेटिंग के नाम को 8 अगस्त 2026 को Claude Code के दस्तावेज़ और रिलीज़ नोट्स से जाँचा गया है (उस समय नवीनतम: v2.1.226, 8 अगस्त 2026)। Claude Code तेज़ी से बदलता है, और कॉम्पैक्शन वाले हिस्से में हाल की रिलीज़ में भी नया व्यवहार जुड़ा है (/autocompact के लिए v2.1.221 या उससे नया बिल्ड चाहिए)। अपना बिल्ड claude --version से जाँच लें।

1. छोटा जवाब — घड़ी देखकर नहीं, काम के पड़ाव पर दबाएँ

पहले फैसले की तालिका। यह इसलिए है ताकि आप घड़ी के बजाय हालात देखकर तय करें।

✅ कब दबाएँ

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

🟡 कब /clear बेहतर है

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

🔵 कब /rewind बेहतर है

जब आप पूरी दिशा ही फेंक देना चाहते हैं। रिवाइंड ऐसे बिंदु तक काट देता है जो पहले से cache में है, इसलिए वह कॉम्पैक्शन से सस्ता पड़ता है, जिसे बिलकुल नया prefix बनाना होता है।

❌ कब न दबाएँ

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

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

2. कॉम्पैक्शन तीन चरणों में चलती है — दस्तावेज़ असल में क्या कहते हैं

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

"जैसे-जैसे आप सीमा के पास पहुँचते हैं, Claude Code कॉन्टेक्स्ट अपने आप सँभालता है: पहले वह पुराने टूल आउटपुट गिराता है, फिर ज़रूरत पड़ने पर बातचीत का सारांश बनाता है। आपकी माँगें और अहम कोड स्निपेट बचा लिए जाते हैं, पर बातचीत के शुरू में दिए गए बारीक निर्देश खो सकते हैं। स्थायी नियम बातचीत के इतिहास के भरोसे छोड़ने के बजाय CLAUDE.md में रखें।" (How Claude Code works)

यानी चरण हैं: (1) पुराने टूल आउटपुट गिराए जाते हैं, (2) बातचीत का सारांश अपने आप बनता है, (3) आप /compact दबाते हैं।

1. टूल आउटपुट गिराना

बातचीत जस की तस रहती है और सिर्फ़ पुराने टूल नतीजे झड़ जाते हैं। आपको कुछ नहीं करना पड़ता। यह परत सारांश की नौबत आने से पहले ही काम कर जाती है।

2. ऑटो-कॉम्पैक्शन

जब चरण 1 काफ़ी नहीं पड़ता, तो बातचीत खुद एक सारांश से बदल दी जाती है। यह हाथ से चलाए गए /compact जैसी ही प्रक्रिया है; फर्क सिर्फ़ इतना है कि यह कब चलती है।

3. हाथ से /compact

इसका इकलौता असली काम है चरण 2 को अपनी सुविधा के पल तक आगे खींच लाना। इसके ऊपर, आप बता सकते हैं कि क्या रखना है — चरण 2 से दूसरा फर्क यही है।

यही जवाब का दिल है। हाथ से चलाया /compact उस चीज़ को पहले खींच लाता है जो वैसे भी होनी ही थी। यह ऐसा लीवर नहीं है जो जितनी बार खींचो उतना अतिरिक्त कॉन्टेक्स्ट बचा दे। इसे दबाना तभी सार्थक है जब समय खुद चुनने की कोई कीमत हो।

⚠️ शब्दावली पर एक बात। कई लेख चरण 1 को "माइक्रो-कॉम्पैक्शन" (micro-compaction) कहते हैं, पर 8 अगस्त 2026 तक आधिकारिक दस्तावेज़ इस नाम का इस्तेमाल नहीं करते। दस्तावेज़ जो देते हैं वह व्यवहार का वर्णन है — पुराने टूल आउटपुट पहले गिराए जाते हैं। अगर आप यह शब्द खोजें और कुछ आधिकारिक न मिले, तो वजह यही है।

3. क्या बचता है और क्या गायब हो जाता है

कॉम्पैक्शन के दौरान आपके नियमों का क्या होगा, यह पूरी तरह इस पर निर्भर है कि वे लोड कैसे हुए थे। दस्तावेज़ हर तंत्र के लिए अलग सूची देते हैं, इसलिए वही यहाँ सिलसिलेवार है।

तंत्र कॉम्पैक्शन के बाद व्यवहार में इसका मतलब
सिस्टम प्रॉम्प्ट और आउटपुट स्टाइल अपरिवर्तित वे बातचीत के इतिहास का हिस्सा ही नहीं हैं
प्रोजेक्ट रूट का CLAUDE.md और बिना स्कोप वाले नियम डिस्क से दोबारा इंजेक्ट रखने की सबसे सुरक्षित जगह। आपके संपादन आखिरकार यहीं लागू होते हैं (देखें खंड 8)
ऑटो मेमोरी डिस्क से दोबारा इंजेक्ट यह सेशन-दर-सेशन टिकने के लिए ही बना है, इसलिए कॉम्पैक्शन झेल जाना इसके लिए मामूली बात है
paths: वाले नियम खो जाते हैं (जब तक मेल खाती फाइल दोबारा न पढ़ी जाए) इन्हें बनाए रखना है तो paths: कुंजी हटा दें या नियम को रूट के CLAUDE.md में ले जाएँ
सब-डायरेक्टरी में नेस्टेड CLAUDE.md खो जाते हैं (जब तक उस डायरेक्टरी की कोई फाइल दोबारा न पढ़ी जाए) ऊपर जैसा ही, और यही चूक सबसे आसानी से नज़र से छूटती है
आपने जो स्किल चलाईं, उनका मूल पाठ दोबारा इंजेक्ट, पर सीमा के साथ प्रति स्किल 5,000 टोकन और कुल 25,000, जिसमें सबसे पुराना पहले गिरता है
हुक्स लागू ही नहीं वे कॉन्टेक्स्ट की तरह नहीं, कोड की तरह चलते हैं

इस तालिका से तीन व्यावहारिक नतीजे निकलते हैं।

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

दूसरा, स्किल फाइल का शुरुआती हिस्सा ही असली है। दोबारा इंजेक्ट करते समय की गई कटाई फाइल की शुरुआत बचाती है, इसलिए SKILL.md के अहम निर्देश ऊपर होने चाहिए। इसके अलावा, दस्तावेज़ के कॉन्टेक्स्ट वाले हिस्से के मुताबिक सेशन शुरू होते समय लोड हुई स्किल की सूची /compact के बाद दोबारा इंजेक्ट नहीं होती; सिर्फ़ वही स्किल बचती हैं जिन्हें आपने वाकई चलाया था।

तीसरा, क्या खोया इसकी कोई घोषणा नहीं होती। और ठीक इसीलिए यह सिद्धांत टिकता है: जिसे खोना तकलीफ़ देगा, उसे बातचीत में नहीं, फाइल में रखें।

4. लागत कॉन्टेक्स्ट के आकार से तय नहीं होती

यह मान लेना स्वाभाविक है कि "बड़ा कॉन्टेक्स्ट /compact को महँगा बनाता है", और यह आधा ही सही है। कीमत को असल में जो चलाता है वह है prompt cache गर्म है या नहीं। दस्तावेज़ की व्याख्या यह रही।

"सारांश बनाने के लिए Claude Code एक अलग रिक्वेस्ट भेजता है, उसी सिस्टम प्रॉम्प्ट, उन्हीं टूल और उसी इतिहास के साथ, जिसके अंत में सारांश बनाने का निर्देश जुड़ा होता है। जब तक cache गर्म है, वह रिक्वेस्ट आपका prefix cache से पढ़ती है, इसलिए वह कॉन्टेक्स्ट के आकार से जितना लगेगा उससे कहीं कम खर्च करती है, और ज़्यादातर समय सारांश बनाने में जाता है। [...] cache की उम्र से लंबे ब्रेक के बाद पढ़ने लायक कोई cache बचती ही नहीं, इसलिए सारांश वाली रिक्वेस्ट पूरे इतिहास को बिना cache के इनपुट की तरह दोबारा प्रोसेस करती है। यही वजह है कि पुराना सेशन दोबारा शुरू करने पर /compact सबसे महँगा पड़ता है।" (Prompt caching)

यह एक पैराग्राफ ही शेड्यूल पर कॉम्पैक्शन चलाने के खिलाफ़ सबसे मज़बूत दलील है।

सेशन के बीच दबाया (cache गर्म)

prefix cache से पढ़ा जाता है। आपको सिर्फ़ सारांश लिखने में लगा समय महसूस होता है। यहाँ की एक कॉम्पैक्शन सस्ती है।

ब्रेक के बाद दबाया (cache ठंडा)

सारांश बनने से पहले पूरा इतिहास दोबारा प्रोसेस होता है। उसी कमांड के लिए यही सबसे महँगा पल है। "सुबह सबसे पहले ज़रा सफ़ाई कर लूँ" सबसे बुरी चाल साबित हो सकती है।

दबाने के ठीक बाद वाली टर्न

cache एक छोटे सारांश से दोबारा बनती है, इसलिए यह हिस्सा भारी नहीं है। "कॉम्पैक्शन के बाद चीज़ें धीमी हो जाती हैं" वाला एहसास आमतौर पर ऊपर के दो मामलों से आता है, यहाँ से नहीं।

cache की उम्र इस पर निर्भर है कि आप किस तरह प्रमाणित होते हैं। Claude की सब्सक्रिप्शन पर एक घंटे का TTL अपने आप माँगा जाता है; API key या किसी क्लाउड प्रदाता के ज़रिए डिफ़ॉल्ट पाँच मिनट है (ENABLE_PROMPT_CACHING_1H=1 इसे एक घंटा कर देता है)। मतलब यह कि "खाना खाकर लौटे, पहले /compact चला लें" API key पर लगभग तय रूप से एक ठंडा रन होगा।

/compact खुद एक बड़ी रिक्वेस्ट है, इस पर लागत वाले दस्तावेज़ में भी ज़ोर दिया गया है: "/compact उसी बातचीत को पढ़ता है जिसका सारांश बना रहा है, इसलिए बड़े कॉन्टेक्स्ट की कॉम्पैक्शन खुद एक बड़ी रिक्वेस्ट है। अगर आपको निरंतरता नहीं, नई शुरुआत चाहिए तो /clear मुफ़्त है।" (Manage costs effectively)। टोकन बचत के नज़रिए से देखें तब भी, ऐसे कई मौके हैं जहाँ आदतन दबाए गए /compact से /clear बेहतर पड़ता है।

5. /compact, /clear, /rewind और /recap में से क्या चुनें

कॉन्टेक्स्ट हल्का करने का रास्ता सिर्फ़ /compact नहीं है। अलग-अलग मकसद वाली कमांड गड्डमड्ड कर दीजिए और आप महँगी वाली का बिल भरने लगेंगे।

कमांड बातचीत का इतिहास cache कब चुनें
/compact [निर्देश] सारांश से बदल दिया जाता है बातचीत वाली परत रद्द हो जाती है आप आगे बढ़ रहे हैं, पर इतिहास का ब्योरा अब नहीं चाहिए
/clear [नाम] खाली कर दिया जाता है दोबारा बनती है (सारांश का कोई खर्च नहीं) अगला काम असंबंधित है। नाम दे दें तो /resume उसे वापस ले आता है
/rewind पिछले किसी बिंदु तक काट दिया जाता है पुरानी cache पर लगती है आप पूरी दिशा हटाना चाहते हैं। कोड भी साथ लौटाया जा सकता है
/recap अछूता (यह सिर्फ़ एक सारांश दिखाता है) जस की तस आप बस "अब तक कहाँ पहुँचे" पढ़ना चाहते हैं
/context [all] अछूता बनी रहती है कुछ भी दबाने से पहले नापें। किस चीज़ ने कितनी जगह घेरी है, यह रंगों में दिखता है

/recap को याद रखना फायदेमंद है। बहुत लोग /compact इसलिए दबाते हैं कि "बातचीत लंबी हो गई है, इसका सारांश चाहिए" — और इस मकसद के लिए इतिहास तोड़ने की कोई ज़रूरत नहीं। दस्तावेज़ के मुताबिक /recap सारांश को कमांड आउटपुट की तरह बस जोड़ देता है, इसलिए cache किया हुआ prefix जस का तस बचा रहता है।

/rewind का स्वभाव भी उतना ही मायने रखता है। दस्तावेज़ बताते हैं कि रिवाइंड आपको ठीक उसी सामग्री पर लौटाता है जो उस बिंदु पर cache हुई थी, इसलिए अगली रिक्वेस्ट पुरानी cache पर लगती है। जब आप गलत दिशा में चले गए हों, तो सही जवाब /rewind है, /compact नहीं — कॉम्पैक्शन नया prefix बनाती है, जबकि रिवाइंड सिर्फ़ पहले से मौजूद prefix पर लौटता है। चेकपॉइंटिंग और रिवाइंड पर अलग लेख है।

6. ऑटो-कॉम्पैक्शन की विंडो आप खुद हिला सकते हैं

हाथ से दबाने पर सिर खपाने से पहले यह जान लेना फायदेमंद है कि अपने आप चलने वाली कॉम्पैक्शन का बिंदु आप हिला सकते हैं। v2.1.221 से आगे, /autocompact कमांड आपको यह तय करने देती है कि ऑटो-कॉम्पैक्शन शुरू होने से पहले कॉन्टेक्स्ट कितना भर जाना चाहिए।

विंडो 500K टोकन पर सेट करें (यूज़र सेटिंग्स में सहेजी जाती है, इसलिए आगे के सेशन पर भी लागू होती है)

/autocompact 500k

मॉडल के हिसाब वाले डिफ़ॉल्ट पर लौटें

/autocompact auto

स्वीकार्य दायरा है 100K से 1M टोकन। आप 200000 जैसा सादा नंबर लिख सकते हैं, 500k या 1M जैसा प्रत्यय वाला मान, या 200 जैसा 100 और 1000 के बीच का नंगा नंबर (जिसे हज़ारों में पढ़ा जाता है)। यह सेटिंग चार जगहों से आ सकती है, और उनकी वरीयता तय है।

1. एनवायरनमेंट वेरिएबल (सबसे ऊपर)

CLAUDE_CODE_AUTO_COMPACT_WINDOW। जब तक यह सेट है, यह कमांड, फ्लैग और सेटिंग्स फाइल तीनों पर भारी पड़ता है

2. लॉन्च फ्लैग

claude --autocompact 500k। सिर्फ़ उसी लॉन्च पर लागू, आपकी सहेजी सेटिंग्स नहीं बदलता

3. कमांड

/autocompact। यह आपकी यूज़र सेटिंग्स के autoCompactWindow में लिखता है

4. सेटिंग्स फाइल

autoCompactWindow। अगर आपके संगठन की मैनेज्ड सेटिंग ऊपर मौजूद है, तो वही जीतती है

⚠️ एनवायरनमेंट वेरिएबल ही वह है जिसका प्रारूप अलग है। दस्तावेज़ साफ़ लिखते हैं कि CLAUDE_CODE_AUTO_COMPACT_WINDOW सिर्फ़ सादा पूर्णांक स्वीकार करता है, और 500k जैसा मान 500 पढ़ा जाकर 100K की न्यूनतम सीमा पर क्लैंप कर दिया जाता है। कमांड जैसी लिखावट यहाँ भी कर दी, तो आपने जो चाहा था उसका हज़ारवाँ हिस्सा माँगा, और फिर क्लैंप होकर कहीं ज़्यादा बार कॉम्पैक्शन झेलने लगे।

इसी जगह एक दूसरी चेतावनी भी है। स्टेटस लाइन का used_percentage हमेशा मॉडल की पूरी कॉन्टेक्स्ट विंडो के मुकाबले नापता है, इसलिए यह वेरिएबल सेट करते ही वह प्रतिशत यह बताना बंद कर देता है कि कॉम्पैक्शन कब चलेगी। "प्रतिशत देखो और हाथ से दबाओ" वाला तरीका ठीक यहीं ढह जाता है।

जब आप कोई विंडो सेट नहीं करते, तब का डिफ़ॉल्ट भी दर्ज है। कुछ भी कॉन्फ़िगर न हो तो कॉम्पैक्शन तब होती है जब मॉडल की कॉन्टेक्स्ट सीमा पहुँच जाती है, कुछ अपवादों के साथ: क्लाउड सेशन सीमा के पास पहुँचते ही जल्दी कॉम्पैक्ट होते हैं, बिना एक्सटेंडेड कॉन्टेक्स्ट वाले Sonnet 4.6 और Opus 4.6 200K की सीमा पर कॉम्पैक्ट होते हैं, Amazon Bedrock, Google Cloud के Agent Platform या Microsoft Foundry पर 200K कॉन्टेक्स्ट के साथ चलने वाले Opus 4.8 और Opus 5 भी वैसा ही बर्ताव करते हैं, और Sonnet 5 उस मॉडल की अपनी डिफ़ॉल्ट सीमा पर चलता है।

आप ऑटो-कॉम्पैक्शन पूरी तरह बंद भी कर सकते हैं, autoCompactEnabled सेटिंग से (डिफ़ॉल्ट true, /config में "Auto-compact" के नाम से) या DISABLE_AUTO_COMPACT एनवायरनमेंट वेरिएबल से। पर यह सलाह के लायक नहीं है। बंद करने से कुछ सिकुड़ता नहीं; कॉन्टेक्स्ट बस छत से टकराता है और आप कॉम्पैक्शन की जगह "Prompt is too long" एरर ले लेते हैं। ऑटो-कॉम्पैक्शन आपको बचाने वाला फीचर है, रास्ता रोकने वाला नहीं।

7. तीन हालात जहाँ तयशुदा शेड्यूल उल्टा पड़ता है

ये ब्योरे हाथ में हों, तो साफ़ दिखने लगता है कि "बस नियमित दबाते रहो" कहाँ घाटे का सौदा है।

1. टास्क के बीच में दबाना

जो ब्योरा आप अभी इस्तेमाल करने वाले थे, वह समरी में चपटा हो जाता है। ऊपर से paths: नियम और नेस्टेड CLAUDE.md फाइलें झड़ जाती हैं, इसलिए उसके तुरंत बाद का काम चुपचाप आपके नियम चूकने लगता है। यह उस किस्म की गिरावट है जिसकी वजह पकड़ में नहीं आती।

2. ब्रेक के बाद सबसे पहले दबाना

cache खत्म हो चुकी है, इसलिए सारांश बनने से पहले पूरा इतिहास दोबारा प्रोसेस होता है। उसी /compact के लिए यही सबसे महँगा पल है — और "शुरू करने से पहले ज़रा सफ़ाई कर लूँ" वाली नेक नीयत सीधे इसी में जा गिरती है।

3. छोटे सेशन में दबाना

सारांश के लायक इतिहास न हो तो आपको बस Not enough messages to compact. मिलता है। यह तब भी होता है जब एक ही विशाल पेस्ट ने कॉन्टेक्स्ट भर दिया हो — और वहाँ सही जवाब सारांश नहीं, /clear है।

इसे उलट दें तो नियम मिल जाता है: हाथ से की गई सबसे कीमती कॉम्पैक्शन वही है जो किसी लंबे काम को शुरू करने से ठीक पहले हो। वहाँ दबाने से बीच रास्ते ऑटो-कॉम्पैक्शन के दखल देने की संभावना घट जाती है। कीमत गिनती में नहीं, समय के चुनाव में है।

8. असल इस्तेमाल में — दबाने से पहले जो करते हैं वह ज़्यादा मायने रखता है

/compact के साथ जो चीज़ सचमुच फर्क डालती है वह है दबाने का तरीका नहीं, बल्कि दबाने से पहले आप फाइलों में क्या दर्ज कर चुके हैं। जैसा खंड 3 की तालिका दिखाती है, प्रोजेक्ट रूट का CLAUDE.md और आपकी ऑटो मेमोरी डिस्क से दोबारा इंजेक्ट होते हैं। वहाँ लिखी कोई भी बात कितनी भी कॉम्पैक्शन झेल जाती है।

एक और गुण है जिस पर नज़र नहीं जाती। सेशन के बीच CLAUDE.md संपादित करने से वह वहीं-का-वहीं लागू नहीं हो जाता। दस्तावेज़ इसे यूँ रखते हैं: "संपादन cache को रद्द नहीं करते, पर वे लागू भी नहीं होते। नई सामग्री अगले /clear, /compact, या रीस्टार्ट पर लोड होती है।" उलटकर पढ़ें तो इसका मतलब है कि /compact वह क्रिया भी है जो सेशन के बीच तय किए गए नियमों को असल में लागू करती है।

दबाने से पहले की चेकलिस्ट

  • क्या आपने इस सेशन के नियम और फैसले किसी फाइल में लिख दिए? (जो सिर्फ़ बातचीत में है, वह सारांश में पतला पड़ जाता है)
  • क्या आपने बता दिया कि क्या रखना है? आप फोकस सौंप सकते हैं, जैसे /compact keep the auth fix plan and the test results
  • क्या अगला काम सचमुच इसी की निरंतरता है? असंबंधित हो तो /clear सस्ता पड़ता है
  • क्या अभी cache गर्म है? (लंबे ब्रेक के ठीक बाद वाला पल टालें)
  • दुविधा हो तो /context चलाएँ और नापें कि असल में जगह कौन घेर रहा है

और यही वह बात है जिसे हाथ से कॉम्पैक्शन करने वाले सबसे ज़्यादा चूकते हैं। "मैं खुद पहले ही दबा देता हूँ, क्योंकि डर लगता है कि पीठ पीछे कॉम्पैक्ट हो जाएगा और सिलसिला टूट जाएगा" — यह आदत काफ़ी आम है। पर दस्तावेज़ ऑटो-कॉम्पैक्शन समझाने के ठीक बाद यह कहते हैं: कॉम्पैक्शन के आर-पार क्या बचे यह तय करने के लिए, अपने CLAUDE.md में एक "Compact Instructions" खंड जोड़ें, या /compact को फोकस के साथ चलाएँ (How Claude Code works)।

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

इसे लिखना मुश्किल नहीं है। दस्तावेज़ का अपना उदाहरण ऐसा दिखता है।

CLAUDE.md में रखे डिफ़ॉल्ट compact निर्देश (आधिकारिक दस्तावेज़ का उदाहरण)

# Compact instructions

When you are using compact, please focus on test output and code changes

जानकारी के लिए, इस साइट पर हम इसे कैसे चलाते हैं। इस ब्लॉग की रिपॉज़िटरी के CLAUDE.md में लंबे समय से दो नियम हैं: "कॉन्टेक्स्ट लंबा हो जाए तो यूज़र को /compact सुझाना" और "/compact चलाने से पहले, जो कुछ नियम बनने लायक है — फीडबैक, तरीके पर लिए गए फैसले — उसे मेमोरी में सहेजना"। यह लेख खुद एक ऐसे सेशन में लिखा गया जिसमें बीच में कॉम्पैक्शन हुई। रोज़ के इस्तेमाल में पहला नियम नहीं, दूसरा अपनी कीमत वसूल करता है। सारांश को गढ़ने की कोशिश करने से कहीं ज़्यादा भरोसेमंद यह है कि रखने लायक चीज़ें पहले ही फाइलों में उतार दी जाएँ।

एक बात और जोड़ने लायक है: कॉन्टेक्स्ट घटाने का रास्ता सिर्फ़ /compact नहीं है। लागत पर आधिकारिक मार्गदर्शन सलाह देता है कि भारी आउटपुट वाले काम — टेस्ट चलाना, दस्तावेज़ खींचना, लॉग प्रोसेस करना — subagent को सौंप दें। subagent के पास अपनी कॉन्टेक्स्ट विंडो होती है और वह सिर्फ़ एक सारांश लौटाता है, इसलिए मुख्य कॉन्टेक्स्ट फूलता ही नहीं। कॉम्पैक्शन की ज़रूरत ही न पड़े, ऐसा इंतज़ाम अच्छी कॉम्पैक्शन से बेहतर है।

9. दो संदेश जो आपको मिल सकते हैं

व्यवहार में मिलने वाले दो संदेश अपने आप में उतने साफ़ नहीं हैं।

संदेश इसका मतलब क्या करें
Not enough messages to compact. सारांश बनाने लायक कोई बातचीत ही नहीं है। यह तब भी होता है जब एक ही विशाल पेस्ट ने कॉन्टेक्स्ट भर दिया हो /clear से नए सिरे से शुरू करें
Autocompact is thrashing: the context refilled to the limit... कॉम्पैक्शन सफल रही, पर किसी विशाल फाइल या टूल आउटपुट ने तुरंत बाद कॉन्टेक्स्ट फिर भर दिया, और यह कई बार हुआ। अंतहीन लूप से बचने के लिए यह रुक गया है दाईं ओर बताए चार कदम (दस्तावेज़ का सुझाया क्रम)

दूसरे वाले की रिकवरी दस्तावेज़ में क्रम से लिखी है। (1) विशाल फाइलें टुकड़ों में पढ़ें, लाइन रेंज से या फंक्शन के हिसाब से। (2) कॉम्पैक्ट करते समय निर्देश में बताएँ कि कौन-सा आउटपुट गिराना है (जैसे /compact keep only the plan and the diff)। (3) उस काम को subagent पर ले जाएँ ताकि वह अलग कॉन्टेक्स्ट विंडो में चले। (4) पिछली बातचीत अब ज़रूरी न हो तो /clear। गौर करने की बात यह है कि कदम 1 पहले आता है: दस्तावेज़ असल में यही कह रहे हैं कि यह कॉम्पैक्शन की नहीं, पढ़ने के तरीके की समस्या है।

सारांश

आपको /compact हाथ से किसी शेड्यूल पर चलाने की ज़रूरत नहीं है। ऑटो-कॉम्पैक्शन आपके चलाए बिना भी चलती है, और वह वही प्रक्रिया है। खुद दबाने से आपको ठीक दो चीज़ें मिलती हैं — समय खुद चुनना, और यह बताना कि क्या रखना है — और ये दोनों एक ही जगह काम आती हैं: दो टास्क के बीच में।

लागत के हिसाब से भी शेड्यूल घाटे में है। कॉम्पैक्शन की कीमत इससे तय होती है कि cache गर्म है या नहीं, इसलिए ब्रेक के बाद वाला "शुरू करने से पहले सफ़ाई कर लूँ" उसका सबसे महँगा रूप है। नई शुरुआत से काम चल जाए तो /clear मुफ़्त है; दिशा बदलनी हो तो /rewind सस्ता है क्योंकि वह मौजूदा cache पर लौटता है; और सिर्फ़ सारांश पढ़ना हो तो /recap इतिहास को छेड़ता ही नहीं। इन चारों में से सही चुनना, एक ही को बार-बार दबाने से बेहतर है।

पर सबसे व्यावहारिक नतीजा इस सवाल के बाहर है कि दबाया कैसे जाए। जिसे खोना आपको भारी पड़े, वह बातचीत में नहीं, फाइल में होना चाहिए। प्रोजेक्ट रूट का CLAUDE.md और आपकी ऑटो मेमोरी डिस्क से दोबारा इंजेक्ट होते हैं, जबकि paths: नियम और नेस्टेड CLAUDE.md फाइलें चुपचाप झड़ जाती हैं। इस असमानता को जानना ही तय करता है कि लंबा सेशन टिकेगा या धीरे-धीरे बिगड़ता जाएगा।

FAQ

Q1. तो मुझे /compact कितने-कितने मिनट पर दबाना चाहिए?

इसे समय से तय करना ही नहीं चाहिए। इकलौता सुझाया गया पल है एक टास्क खत्म होने के ठीक बाद और अगला लंबा काम शुरू करने से पहले। दस्तावेज़ कहते हैं "काम के किसी स्वाभाविक पड़ाव पर, जैसे दो टास्क के बीच में", और कोई समय या प्रतिशत की सीमा नहीं देते।

Q2. क्या सब कुछ ऑटो-कॉम्पैक्शन पर छोड़ देना ठीक है?

अपने आप वाली और हाथ वाली एक ही प्रक्रिया हैं; फर्क सिर्फ़ समय का है। पेच यह है कि अपने आप वाली आपको टास्क के बीच में रोक सकती है। किसी लंबे काम से पहले एक बार हाथ से दबा देने से उस दखल की संभावना घटती है। और अपने आप वाली को भी निर्देश दिए जा सकते हैं — उन्हें CLAUDE.md में # Compact instructions शीर्षक के नीचे लिख दें, तो वे उस कॉम्पैक्शन पर भी लागू होंगे जो आपके डेस्क से दूर रहते चली (देखें खंड 8)।

Q2-2. अपने आप कॉम्पैक्ट होने के बाद लगता है मेरे निर्देश असर करना बंद कर देते हैं

यह आपका वहम नहीं है। दस्तावेज़ साफ़ कहते हैं कि "बातचीत के शुरू में दिए गए बारीक निर्देश खो सकते हैं"। इसके ऊपर, paths: नियम और नेस्टेड CLAUDE.md फाइलें तब तक झड़ी रहती हैं जब तक मेल खाती फाइल दोबारा न पढ़ी जाए, और चलाई गई स्किल कुल 25,000 टोकन पार करते ही सबसे पुरानी से गिरने लगती हैं। बात इतनी नहीं कि सामग्री गायब हो जाती है, बल्कि यह कि जिन नियमों का पालन हो रहा था वे चुपचाप पतले पड़ जाते हैं, इसलिए काम तो चलता रहता है और सिर्फ़ सटीकता गिरती है। तीन उपाय: (1) जिन नियमों को टिकाना है उन्हें रूट के CLAUDE.md में ले जाएँ, जहाँ वे दोबारा इंजेक्ट होते हैं; (2) # Compact instructions से बताएँ कि क्या रखना है; (3) /autocompact से इसे पहले चलवाएँ ताकि कॉम्पैक्शन ठीक छत पर न हो।

Q3. मुझे /compact इस्तेमाल करना चाहिए या /clear?

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

Q4. क्या कॉम्पैक्शन मेरे CLAUDE.md के नियम मिटा देती है?

प्रोजेक्ट रूट का CLAUDE.md नहीं मिटता — वह डिस्क से दोबारा इंजेक्ट होता है। जो जाता है वह है paths: फ्रंट मैटर वाले नियम और सब-डायरेक्टरी की नेस्टेड CLAUDE.md फाइलें, और वे तब तक नहीं लौटतीं जब तक मेल खाती कोई फाइल दोबारा न पढ़ी जाए। जिन नियमों को टिकाना है, उनसे paths: कुंजी हटा दें या उन्हें रूट के CLAUDE.md में ले जाएँ।

Q5. क्या मैं ऑटो-कॉम्पैक्शन बंद कर सकता हूँ?

कर सकते हैं (autoCompactEnabled सेटिंग को false, /config में "Auto-compact", या DISABLE_AUTO_COMPACT एनवायरनमेंट वेरिएबल)। पर यह सलाह के लायक नहीं है। बंद करने से आपका कॉन्टेक्स्ट घटता नहीं; आप बस छत से टकराते हैं और एरर पाते हैं। अगर आप चाहते हैं कि यह पहले चले, तो सही चाल इसे बंद करना नहीं, बल्कि /autocompact से विंडो सँकरी करना है।

Q6. /compact कितने टोकन खर्च करता है?

यह इस पर बहुत बदलता है कि cache गर्म है या नहीं। सेशन के बीच दबाएँ तो prefix cache से पढ़ा जाता है और खर्च, दस्तावेज़ के शब्दों में, कॉन्टेक्स्ट के आकार से जितना लगेगा उससे कहीं कम होता है। cache की उम्र से लंबे ब्रेक के बाद दबाएँ तो पूरा इतिहास बिना cache के दोबारा प्रोसेस होता है, और वही कमांड जितना महँगा हो सकता है उतना हो जाता है। cache की उम्र सब्सक्रिप्शन पर एक घंटा है, और API key या किसी क्लाउड प्रदाता के ज़रिए डिफ़ॉल्ट पाँच मिनट।

Q7. क्या मैं बता सकता हूँ कि क्या रखा जाए?

हाँ। /compact के बाद एक निर्देश लिख दें और सारांश उसी फोकस से बनेगा (जैसे /compact keep the auth fix plan and the test results)। अगर हर बार वही निर्देश काम करता है, तो CLAUDE.md में # Compact instructions शीर्षक बनाकर लिख दें और वह डिफ़ॉल्ट की तरह लागू होगा।

Q8. कॉम्पैक्शन के तुरंत बाद जवाब धीमे क्यों लगते हैं?

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

Q9. क्या "माइक्रो-कॉम्पैक्शन" नाम का कोई फीचर है?

वह व्यवहार मौजूद है — दस्तावेज़ समझाते हैं कि पुराने टूल आउटपुट पहले गिराए जाते हैं और बातचीत का सारांश सिर्फ़ ज़रूरत पड़ने पर बनता है, जो साफ़ तौर पर बताता है कि सारांश से पहले कुछ और होता है। पर 8 अगस्त 2026 तक आधिकारिक दस्तावेज़ "माइक्रो-कॉम्पैक्शन" नाम का इस्तेमाल नहीं करते। यह शब्द बाहरी लेखों से आया है, Anthropic से नहीं, इसलिए इसे उसी हिसाब से लें।

संबंधित लेख