Claude Code session को धीमा और महंगा होने से कैसे रोकें

Claude Code session को धीमा और महंगा होने से कैसे रोकें

एक लंबी Claude Code session इसलिए धीमी और महंगी हो जाती है क्योंकि हर टर्न पर पूरा context फिर से भेजा जाता है, और यह context लगातार बढ़ता रहता है। इसका समाधान एक निश्चित क्रम में स्वच्छता बनाए रखना है। यह देखने के लिए कि window में क्या भर रहा है, /context चलाएं, उन items को हटा दें जिनके लिए आप हर request पर भुगतान करते हैं, फिर असंबंधित कार्यों के बीच /clear का उपयोग करें और एक लंबे कार्य के भीतर निर्देश देने के लिए /compact का उपयोग करें। लगातार काम करें, क्योंकि cold prompt cache एक सस्ते read को आपके द्वारा कही गई हर बात के पूर्ण re-write में बदल देता है।

मीटर क्यों चलता है, इसका उत्तर agent session के पीछे के token meter में दिया गया है।

किसी भी बदलाव से पहले /context पढ़ें

यह अनुमान न लगाएँ कि विंडो में क्या भरा है। Claude Code आपको बताएगा।

/context [all] वर्तमान context उपयोग को एक रंगीन ग्रिड के रूप में दिखाता है, जिसमें context-heavy टूल्स और मेमोरी bloat के लिए अनुकूलन सुझाव दिए गए हैं; all फुलस्क्रीन मोड में प्रति-आइटम विवरण को विस्तृत करता है। परिणाम को पाँच बाल्टियों (buckets) के रूप में पढ़ें।

• सिस्टम प्रॉम्प्ट। Claude Code के स्वयं के हार्नेस निर्देश। सत्र के लिए निश्चित।
• टूल परिभाषाएँ। हर उस टूल का स्कीमा जिसे एजेंट कॉल कर सकता है, जिसमें प्रत्येक कनेक्टेड MCP (Model Context Protocol) सर्वर शामिल है।
• मेमोरी फाइलें। CLAUDE.md और ऑटो मेमोरी, जो सत्र शुरू होने पर लोड होती हैं।
• फाइलें और टूल परिणाम। पढ़ी गई प्रत्येक फाइल, और आपके कमांड्स द्वारा प्रिंट किया गया सब कुछ।
• संदेश इतिहास। आपकी बारी और उसके उत्तर।

पहली तीन एक निश्चित कर (fixed tax) हैं, जो सत्र के दौरान प्रत्येक अनुरोध पर चुकाया जाता है। अंतिम दो बढ़ती रहती हैं। निश्चित कर को एक बार, शुरुआत में ही कम करें; बढ़ते हुए हिस्से को लगातार प्रबंधित करें।

दो स्ट्रिंग्स आपको बताती हैं कि विंडो भर गई है:

Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.
Context is 94k tokens past the 200k-token compaction window — run /compact to reduce usage.

पहली एक हार्ड लिमिट है, और अनुरोध अस्वीकार कर दिया जाता है; संबंधित API (application programming interface) त्रुटि Prompt is too long पढ़ती है। दूसरी एक कॉम्पैक्शन विंडो है, जो 1 मिलियन टोकन मॉडल पर मॉडल की वास्तविक context विंडो से नीचे हो सकती है। अनुरोध इसके बाद भी सफल होते हैं, इसलिए वह एक चेतावनी है न कि इनकार।

पेड प्लान पर, /usage दूसरा आधा हिस्सा जोड़ता है, जो लंबे context या cache misses जैसे व्यवहारों को चिह्नित करता है और हालिया उपयोग को व्यक्तिगत स्किल्स, सब-एजेंट्स और MCP सर्वर्स के लिए जिम्मेदार ठहराता है। यदि यह आपको बताता है कि भत्ता (allowance) पहले ही खर्च हो चुका है, तो आप किस लिमिट विंडो की प्रतीक्षा कर रहे हैं यह तय करता है कि क्या context को ट्रिम करना अभी आपकी मदद करेगा या आपको काम पर वापस जाने के लिए किसी अलग रास्ते की आवश्यकता है।

CLAUDE.md एक स्थायी टैक्स है, इसलिए इसे संक्षिप्त रखें

आपका CLAUDE.md सेशन शुरू होते ही कॉन्टेक्स्ट में लोड हो जाता है और वहीं रहता है। यदि इसमें विस्तृत डिप्लॉयमेंट प्रक्रिया शामिल है, तो वे टोकन तब भी मौजूद रहते हैं जब आप किसी टेस्ट फाइल में टाइपो ठीक कर रहे होते हैं। Anthropic का मार्गदर्शन यह है कि केवल आवश्यक चीजें शामिल करें और फाइल को 200 लाइनों से कम रखें।

प्रक्रियाओं को स्किल्स में ले जाएं। एक स्किल केवल तभी लोड होती है जब उसे इनवोक किया जाता है, इसलिए जिस वर्कफ्लो को आप सप्ताह में दो बार चलाते हैं, उसकी अन्य दिनों में कोई लागत नहीं होती। कॉम्पैक्शन के बाद स्किल्स का अपना बजट होता है: बॉडीज को फिर से इंजेक्ट किया जाता है, जिसकी सीमा प्रति स्किल 5,000 टोकन और कुल 25,000 टोकन होती है, जिसमें सबसे पुराने को पहले हटाया जाता है। ट्रंकेशन फाइल की शुरुआत को बनाए रखता है, इसलिए सबसे महत्वपूर्ण निर्देशों को SKILL.md के शीर्ष के पास रखें।

कॉम्पैक्शन के बाद क्या बचता है, यह तय करता है कि कोई निर्देश कहाँ संबंधित है।

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

इसलिए जिस नियम पर आप निर्भर हैं, वह प्रोजेक्ट-रूट CLAUDE.md में संबंधित है: Claude Code पहले पुराने टूल आउटपुट को क्लियर करता है और फिर सारांशित करता है, इसलिए बातचीत की शुरुआत के निर्देश खो सकते हैं। /memory के साथ मेमोरी को एडिट करें। Claude Code उस कॉपी को रखता है जिसे उसने सेशन की शुरुआत में लोड किया था, इसलिए मिड-सेशन ट्रिम प्रॉम्प्ट कैश को बनाए रखता है और अगले /clear, /compact, या रीस्टार्ट तक लागू नहीं होता है। कॉन्टेक्स्ट का खोना केवल एक कारण है कि कोई नियम फॉलो होना बंद हो जाता है, इसलिए जब नियम स्पष्ट रूप से विंडो में होता है और फिर भी अनदेखा कर दिया जाता है, तो इसे फिर से लिखने से पहले अन्य कारणों पर काम करें।

/clear और /compact के बीच का अंतर

ये दोनों कमांड एक जैसे लग सकते हैं, लेकिन इनकी लागत बहुत अलग है।

/clear [name] खाली कॉन्टेक्स्ट के साथ एक नया कन्वर्सेशन शुरू करता है। यह कोई रिक्वेस्ट नहीं भेजता, इसलिए इसकी कोई लागत नहीं है। पिछले कन्वर्सेशन को /resume पिकर में लेबल करने के लिए एक नाम दें; /reset और /new इसके उपनाम (aliases) हैं। जब भी आप किसी असंबंधित कार्य (task) पर स्विच करें, तो तुरंत इसका उपयोग करें, क्योंकि ऐसा न करने पर पुराने कार्य का डेटा हर नए मैसेज के साथ फिर से भेजा जाएगा और उसका शुल्क लगेगा।

/compact [instructions] एक ही कन्वर्सेशन को जारी रखते हुए कॉन्टेक्स्ट को खाली करता है: यह अब तक के इतिहास का सारांश (summarize) तैयार करता है और उसे रिप्लेस कर देता है। इसका उपयोग एक लंबे कार्य के दौरान करें, जहाँ आपको निरंतरता की आवश्यकता हो।

हमेशा /compact को एक निर्देश दें। बिना निर्देश के /compact एक डिफ़ॉल्ट प्रॉम्प्ट के आधार पर सारांश बनाता है, जिसे यह नहीं पता होता कि आपको काम का कौन सा हिस्सा अभी भी चाहिए। एक निर्देशित कमांड उस हिस्से को सुरक्षित रखता है:

/compact focus on the auth bug fix
/compact keep only the plan and the diff

यदि आप हर बार एक ही कारण से कॉम्पैक्ट (compact) करते हैं, तो अपने प्रोजेक्ट के CLAUDE.md में # Compact instructions हेडिंग के तहत एक स्थायी निर्देश रखें। नए सेशन में /compact चलाने पर Not enough messages to compact. प्रिंट होता है, जिसका अर्थ केवल यह है कि अभी तक कोई इतिहास मौजूद नहीं है।

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

दो सस्ते कमांड भी उपलब्ध हैं। /rewind [description] कोड और कन्वर्सेशन को चेकपॉइंट पर वापस ले जाता है; जिस पाथ को आप पूरी तरह छोड़ना चाहते हैं, उसके लिए यह कॉम्पैक्ट करने से बेहतर है, क्योंकि यह उसे उस प्रीफ़िक्स तक ट्रंकेट (truncate) कर देता है जो पहले से ही कैश में है। /recap इतिहास को बदलने के बजाय कमांड आउटपुट के रूप में एक सारांश जोड़ता है, जिससे कैश किया गया प्रीफ़िक्स सुरक्षित रहता है।

बार-बार ऑटोमैटिक कॉम्पैक्शन होने पर यह प्रिंट होता है:

Autocompact is thrashing: the context refilled to the limit...

कॉम्पैक्शन सफल रहा, लेकिन किसी फाइल या टूल आउटपुट ने विंडो को लगातार कई बार भर दिया, इसलिए Claude Code ने दोबारा कोशिश करना बंद कर दिया। इसे ठीक करने के लिए बड़ी फाइल को लाइन रेंज में पढ़ें, /compact को ऐसे फोकस के साथ चलाएं जो बड़े आउटपुट को हटा दे, उस काम को किसी सब-एजेंट (subagent) पर ले जाएं, या यदि पिछला कन्वर्सेशन पूरा हो गया है तो /clear का उपयोग करें।

MCP servers एक fixed overhead हैं

आप जिस भी MCP server को connect करते हैं, वह पूरे session के दौरान हर request में जुड़ जाता है। आप इसका उपयोग करें या न करें, आपको इसकी कीमत चुकानी पड़ती है।

Claude Code इस प्रभाव को कम करता है। MCP tool definitions डिफ़ॉल्ट रूप से deferred रहती हैं, इसलिए जब तक Claude किसी विशिष्ट tool का उपयोग नहीं करता, तब तक केवल tool के नाम ही context में जाते हैं। यह देखने के लिए कि आपके servers वास्तव में कितनी लागत ले रहे हैं, /context चलाएं, और जिसे आप आज उपयोग नहीं करना चाहते उसे हटाने के लिए /mcp disable <name> का उपयोग करें। यदि आप अपने स्वयं के MCP servers को VPS पर चलाते हैं, तो यही गणित यह सीमित करता है कि एक server को कितने tools expose करने चाहिए।

यह काम session की शुरुआत में करें। जबकि definitions deferred रहती हैं, server को connect या disconnect करने से केवल conversation में जानकारी जुड़ती है, और cache सुरक्षित रहता है। जिन स्थितियों में definitions prefix में load होती हैं, क्योंकि tool search बंद है या कोई server deferral से मुक्त है, वहां यही बदलाव अगली request को सब कुछ फिर से पढ़ने के लिए मजबूर करता है।

Verbose tool output को context में भेजने से पहले filter करें

Tool का परिणाम input होता है, और यह input हर बाद के turn पर फिर से भेजा जाता है। एक test run जो 20,000 tokens का output dump करता है, वह केवल एक बार की लागत नहीं है: आप इसे तब तक हर turn पर चुकाते हैं जब तक वह window से बाहर नहीं निकल जाता।

Source पर ही filter करें। एक ऐसा hook जो Claude द्वारा देखे जाने से पहले test run को केवल उसकी विफलताओं (failures) तक सीमित कर देता है, वह output की उस लंबी सूची को कुछ सौ tokens में बदल देता है, इस turn पर भी और इसके हर बार resend होने पर भी:

npm test 2>&1 | grep -E "FAIL|Error:" | head -40

Hooks कभी भी खुद context में प्रवेश नहीं करते, क्योंकि वे code के रूप में चलते हैं। किसी भी ऐसे tool के लिए ऐसा करें जिसका output एक screen से अधिक हो। यही तर्क 3,000-line वाली file पर भी लागू होता है: केवल उन lines की range मांगें जिनकी आपको आवश्यकता है, क्योंकि एक बार file आ जाने के बाद पूरी file window में बनी रहती है।

एजेंट क्या पढ़ता है इसका दायरा तय करें और शोर मचाने वाले काम सौंपें

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

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

कैश क्लॉक: अंतराल में काम करें

Prompt caching ही resend को किफायती बनाता है: prefix को पढ़ने के लिए base input rate का 0.1x, जबकि इसे लिखने के लिए 1.25x, या एक घंटे की lifetime पर 2x खर्च होता है। प्रत्येक उपयोग बिना किसी अतिरिक्त लागत के entry को refresh कर देता है, इसलिए क्लॉक अंतिम उपयोग से चलती है। ये multipliers आपको बिल का स्वरूप बताते हैं, उसका आकार नहीं, इसलिए पूर्ण context window को डॉलर में बदलने के लिए इसे एक मिलियन टोकन की वास्तविक लागत के साथ जोड़ें।

आपको कौन सी lifetime मिलेगी, यह इस पर निर्भर करता है कि आप authenticate कैसे करते हैं, और यहीं पर "आपका कैश पांच मिनट बाद expire हो जाता है" जैसा सामान्य दावा गलत साबित होता है।

• Claude subscription पर, Claude Code स्वचालित रूप से एक घंटे की lifetime का अनुरोध करता है।
• एक बार जब आप अपने plan की limit पार कर लेते हैं और usage credits का उपयोग करते हैं, तो आपसे उस उपयोग के लिए शुल्क लिया जाता है, इसलिए यह वापस पांच मिनट पर आ जाता है।
• API key या cloud provider पर, यह पांच मिनट पर ही रहता है। ENABLE_PROMPT_CACHING_1H=1 एक घंटे की lifetime का विकल्प चुनता है, और FORCE_PROMPT_CACHING_5M=1 इसे वापस कम कर देता है।

दोनों ही स्थितियों में लय के लिए सलाह एक ही है: निरंतर अंतराल में काम करें, क्योंकि lifetime के बाद का idle gap आपके अगले turn में पूरे संचित prefix को फिर से लिखने पर मजबूर कर देता है। tmux में एक detached Claude Code session idle रहने पर कुछ खर्च नहीं करता, और idle समय में जो खोता है वह warm cache है।

कुछ क्रियाएं काम के दौरान ही कैश को हटा देती हैं: model बदलना, effort level बदलना, fast mode चालू करना, MCP server को connect या disconnect करना, plugin को enable या disable करना, किसी tool को पूरी तरह से deny करना, compacting करना, और Claude Code को upgrade करना। /model अक्सर आश्चर्य का कारण बनता है, क्योंकि प्रत्येक model का अपना कैश होता है, इसलिए अगला अनुरोध पूरी history को बिना किसी cache hit के पढ़ता है, भले ही content समान हो। उस re-read का शुल्क destination model की दरों पर लिया जाता है, इसलिए session के बीच में Fable पर स्विच करने से आपकी पूरी संचित history का शुल्क Fable 5 की प्रकाशित input rate पर लगता है।

files को edit करना, CLAUDE.md को edit करना, skills और commands को invoke करना, /recap चलाना, rewinding करना, और subagent spawn करना—ये सभी कैश को बनाए रखते हैं। यह एक machine और एक directory तक सीमित है, इसलिए अलग-अलग directories में चल रहे दो sessions एक-दूसरे के कैश का उपयोग नहीं कर पाते। यह scope आपके account के बजाय CLI का अनुसरण करता है, इसलिए इसमें से कुछ भी Claude desktop app में नहीं जाता, जो Linux पर CLI के साथ एक अलग beta install है।

यह देखने के लिए कि क्या caching काम कर रहा है, current_usage पढ़ें। cache_creation_input_tokens को cache write rate पर लिखा गया था; cache_read_input_tokens को मानक input rate के लगभग दसवें हिस्से पर serve किया गया था। एक उच्च read-to-creation ratio अच्छा संकेत है। यदि हर turn के बाद creation दर अधिक बनी रहती है, तो इसका मतलब है कि आपके prefix में कुछ लगातार बदल रहा है।

क्या बड़ा context window इसे ठीक करता है?

आंशिक रूप से। वर्तमान में कई models 1 million token के context window का समर्थन करते हैं, और compaction बड़े limit पर भी उसी तरह काम करता है। इसके आर्थिक पहलू में कोई बदलाव नहीं आता, क्योंकि पूरा prompt हर बार फिर से भेजा जाता है और हर turn पर उसका billing होता है। बड़ा window यह तय करता है कि आपको कब कार्रवाई करने के लिए मजबूर होना पड़ेगा; जबकि hygiene यह तय करती है कि लागत कितनी होगी। यदि समस्या ceiling के बजाय billing है, तो आपके काम करने के तरीके के अनुसार कौन सा Claude plan उपयुक्त है यह तय करता है कि आप डॉलर खर्च कर रहे हैं या plan allowance का उपयोग कर रहे हैं।

API में कॉन्टेक्स्ट एडिटिंग और कॉम्पैक्शन अलग-अलग चीजें हैं

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

कॉन्टेक्स्ट एडिटिंग बातचीत के इतिहास के बढ़ने पर विशिष्ट सामग्री को चुनिंदा रूप से हटा देती है, और प्रत्येक हटाए गए परिणाम को प्लेसहोल्डर टेक्स्ट से बदल देती है ताकि Claude को पता चले कि कुछ हटा दिया गया है। यह एक बीटा सुविधा है: anthropic-beta: context-management-2025-06-27 भेजें और context_management.edits के तहत रणनीतियाँ कॉन्फ़िगर करें। clear_tool_uses_20250919 टूल परिणामों को हटाता है, और clear_thinking_20251015 थिंकिंग ब्लॉक्स को प्रबंधित करता है। इसका trigger डिफ़ॉल्ट रूप से 100,000 इनपुट टोकन पर सेट है, keep अंतिम 3 टूल उपयोगों पर, और clear_tool_inputs को false पर सेट किया गया है, ताकि इनपुट बने रहें और केवल परिणाम हटें।

कॉम्पैक्शन एक सारांश तैयार करता है और पूरे बातचीत के इतिहास को उससे बदल देता है। यह भी एक बीटा सुविधा है: anthropic-beta: compact-2026-01-12 भेजें और compact_20260112 एडिट टाइप का उपयोग करें। ट्रिगर डिफ़ॉल्ट रूप से {"type": "input_tokens", "value": 150000} पर सेट है, और इसका मान कम से कम 50,000 होना चाहिए।

कॉम्पैक्शन में एक हैंडऑफ़ नियम है जो एजेंटों को चुपचाप तोड़ देता है। प्रतिक्रिया एक compaction कंटेंट ब्लॉक के साथ शुरू होती है जिसमें सारांश होता है, जिसके बाद सामान्य टेक्स्ट ब्लॉक आता है। आपको बाद के अनुरोधों पर उस ब्लॉक को वापस पास करना होगा, और फिर API उसके पहले के हर कंटेंट ब्लॉक को हटा देता है। व्यवहार में: केवल टेक्स्ट ही नहीं, बल्कि पूरे response.content को जोड़ें।

Anthropic का डॉक्यूमेंटेशन सर्वर-साइड कॉम्पैक्शन को लंबी बातचीत में कॉन्टेक्स्ट प्रबंधित करने की प्राथमिक रणनीति बताता है, और कॉन्टेक्स्ट एडिटिंग को उस चीज़ पर बेहतर नियंत्रण के लिए विकल्प बताता है जिसे हटाया जाना है। पहले मॉडल सपोर्ट की जाँच करें। वर्तमान Opus, Sonnet और Fable मॉडल कॉम्पैक्शन का समर्थन करते हैं; claude-haiku-4-5 नहीं करता है, और कॉम्पैक्शन पेज पर लाइव सूची उपलब्ध है। इनमें से कोई भी बीटा Claude Code के अपने /compact को संचालित नहीं करता है, जिसे उसका डॉक्यूमेंटेशन क्लाइंट द्वारा भेजे गए एक बार के सारांश अनुरोध के रूप में वर्णित करता है।

FAQ

Claude Code session लंबे समय तक चलने पर धीमी और महंगी क्यों हो जाती है?

क्योंकि हर टर्न पर पूरी बातचीत दोबारा भेजी जाती है, इसलिए पूरे दिन खुली रही session में एक लाइन का सवाल भी पूरे दिन का डेटा साथ लेकर चलता है। Prompt caching cache warm रहने पर इसे सस्ता रखती है, जो read के लिए base input rate का 0.1x होता है; एक बार जब कोई टर्न cache miss करता है, तो वही prefix 1.25x पर दोबारा लिखा जाता है। यह देखने के लिए कि window में क्या भर रहा है, /context चलाएं, और इसके मैकेनिज्म के लिए Claude Code session आपसे किस चीज का शुल्क लेती है पढ़ें।

Claude Code में /clear और /compact के बीच क्या अंतर है?

/clear खाली context के साथ एक नई बातचीत शुरू करता है। यह कोई request नहीं भेजता, इसलिए इसकी कोई लागत नहीं आती, और असंबंधित कार्यों के बीच यह सही विकल्प है। /compact उसी बातचीत को जारी रखता है और इतिहास को एक सारांश (summary) से बदल देता है, इसलिए एक लंबे कार्य के दौरान यह सही विकल्प है। इसे एक focus दें, जैसे /compact keep only the plan and the diff में, क्योंकि निर्देश ही तय करता है कि क्या सुरक्षित रहेगा।

मैं कैसे देखूँ कि मेरा Claude Code context window क्या इस्तेमाल कर रहा है?

/context चलाएं, या प्रति-आइटम पूर्ण विवरण के लिए /context all चलाएं। यह system prompt, tool definitions, MCP servers, memory files और इतिहास को एक रंगीन ग्रिड के रूप में दिखाता है, जिसमें context-heavy tools और memory bloat के लिए सुझाव भी होते हैं। Paid plan पर, /usage हालिया उपयोग को व्यक्तिगत skills, subagents और MCP servers के आधार पर भी वर्गीकृत करता है।

क्या मुझे compacting के बजाय 1 million token context window का उपयोग करना चाहिए?

एक बड़ी window समस्या को हल करने के बजाय केवल टालती है। कई वर्तमान models 1 million token context window चलाते हैं, जिनमें Opus 4.8 और Sonnet 5 शामिल हैं, और compaction वहां भी उसी तरह काम करता है। हर टर्न अभी भी पूरा prompt दोबारा भेजता है और उसका शुल्क लेता है, इसलिए 400,000-token की बातचीत महंगी होती है, चाहे वह window में फिट हो या न हो।

Claude API में context editing और compaction के बीच क्या अंतर है?

Context editing चुनिंदा रूप से पुरानी सामग्री, मुख्य रूप से tool results को हटाती है, और हर जगह placeholder text छोड़ देती है ताकि Claude को पता रहे कि उसे हटा दिया गया है। Compaction एक सारांश तैयार करता है और पूरे इतिहास को उससे बदल देता है। Anthropic का documentation compaction को लंबी बातचीत के लिए प्राथमिक रणनीति मानता है, और context editing को fine-grained विकल्प के रूप में रखता है। दोनों ही अपने-अपने headers के साथ betas हैं, और दोनों Claude Code के /compact से अलग हैं।