Claude Code session slow aur costly kaise roke

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

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

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

कुछ भी बदलने से पहले /context पढ़ें

Window में क्या डेटा है, इसका अनुमान न लगाएं। Claude Code आपको यह बता देगा।

/context [all] वर्तमान context usage को एक colored grid के रूप में दिखाता है। यह context-heavy tools और memory bloat के लिए optimization suggestions भी देता है; all fullscreen mode में per-item breakdown को विस्तार से दिखाता है। परिणाम को पांच buckets के रूप में पढ़ें।

• The system prompt. Claude Code के अपने harness instructions. यह session के लिए fixed रहते हैं।
• Tool definitions. हर उस tool का schema जिसे agent call कर सकता है, जिसमें सभी connected MCP (Model Context Protocol) servers शामिल हैं।
• Memory files. CLAUDE.md और auto memory, जो session start पर load होते हैं।
• Files and tool results. पढ़ा गया हर file, और आपके commands द्वारा print किया गया सारा output।
• Message history. आपके messages और Claude Code के replies.

पहले तीन items एक fixed tax हैं, जो session के दौरान हर request पर लगते हैं। आखिरी दो items बढ़ते जाते हैं। शुरुआत में fixed tax को एक बार समझ लें; बढ़ते हुए हिस्से को लगातार manage करें।

दो strings बताती हैं कि window भर गई है:

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.

पहली एक hard limit है, और request refuse कर दी जाती है; संबंधित API (application programming interface) error Prompt is too long होता है। दूसरी एक compaction window है, जो 1 million token वाले model पर model के real context window से कम हो सकती है। इसके बाद भी requests सफल होती हैं, इसलिए वह refusal के बजाय एक warning है।

Paid plan पर, /usage दूसरी जानकारी जोड़ता है। यह long context या cache misses जैसे behaviors को flag करता है और recent usage को individual skills, subagents और MCP servers के साथ जोड़ता है।

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

आपका CLAUDE.md सेशन की शुरुआत में context में लोड हो जाता है और वहीं रहता है। यदि इसमें विस्तृत deployment procedure है, तो test file में typo ठीक करते समय भी वे tokens मौजूद रहेंगे। Anthropic का सुझाव है कि केवल आवश्यक जानकारी ही शामिल करें और file को 200 lines से कम रखें।

Procedures को skills में ले जाएँ। एक skill केवल बुलाने (invoke) पर ही लोड होती है, इसलिए सप्ताह में दो बार चलने वाला workflow अन्य दिनों में कोई cost नहीं लेता। Compaction के बाद skills का अपना budget होता है: bodies को फिर से inject किया जाता है, जो प्रति skill 5,000 tokens और कुल 25,000 tokens तक सीमित है; इसमें सबसे पुराना डेटा पहले हटाया जाता है। Truncation file के शुरुआत वाले हिस्से को सुरक्षित रखता है, इसलिए सबसे महत्वपूर्ण instructions को SKILL.md के शीर्ष पर रखें।

Compaction के बाद क्या बचता है, यह तय करता है कि कोई instruction कहाँ रहेगी।

• System prompt और output style अपरिवर्तित रहते हैं, क्योंकि वे message history का हिस्सा नहीं हैं।
• Project-root CLAUDE.md, unscoped rules, और auto memory को disk से फिर से inject किया जाता है।
• paths: frontmatter वाली rule तब तक खो जाती है जब तक कि उससे मेल खाने वाली file दोबारा न पढ़ी जाए।
• Subdirectory में nested CLAUDE.md तब तक खो जाती है जब तक कि उस subdirectory की कोई file दोबारा न पढ़ी जाए।
• Hooks पर कोई प्रभाव नहीं पड़ता, क्योंकि hook code के रूप में चलता है और कभी context में प्रवेश नहीं करता।

इसलिए, जिस rule पर आप निर्भर हैं, उसे project-root CLAUDE.md में रखें: Claude Code पहले पुराने tool outputs को clear करता है और फिर summarize करता है, इसलिए conversation की शुरुआत के instructions खो सकते हैं। Memory को /memory से edit करें। Claude Code उस copy को रखता है जो session start पर load हुई थी, इसलिए session के बीच में की गई trimming prompt cache को सुरक्षित रखती है और अगली /clear, /compact, या restart तक लागू नहीं होती है।

tasks के बीच /clear का उपयोग करें, एक task के अंदर /compact का उपयोग करें

ये दोनों विकल्प एक जैसे लग सकते हैं, लेकिन इनकी लागत (cost) बहुत अलग है।

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

/compact [instructions] एक ही conversation को जारी रखते हुए context को खाली करता है: यह अब तक के history को summarize करके उसे replace कर देता है। इसका उपयोग एक लंबे task के अंदर करें, जहाँ आपको continuity की आवश्यकता हो।

हमेशा /compact को एक instruction दें। बिना instruction के /compact एक default prompt का उपयोग करके summarize करता है, जिसे यह नहीं पता होता कि आपको काम के किस हिस्से की आवश्यकता है। instruction देने पर यह उसे बनाए रखता है:

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

यदि आप हर बार एक ही कारण से compact करना चाहते हैं, तो अपने project के CLAUDE.md में # Compact instructions heading के तहत एक standing instruction रखें। एक नए session में /compact Not enough messages to compact. प्रिंट करता है, जिसका अर्थ है कि अभी कोई history नहीं है।

यहाँ दो costs के बीच भ्रम हो सकता है। Summarization request आपके prefix को साझा करती है, इसलिए यह history को दोबारा process करने के बजाय existing cache को पढ़ती है, और इसका अधिकांश समय summary generate करने में जाता है। एक बड़े context को compact करना अभी भी एक बड़ा request है, क्योंकि summarize की जा रही conversation ही input होती है। Compaction के बाद वाला turn धीमा नहीं होता है: यह बहुत छोटे prompt के लिए cache को rebuild करता है।

दो सस्ते commands उपलब्ध हैं। /rewind [description] code और conversation को एक checkpoint पर वापस ले जाता है; उस path के लिए जिसे आप पूरी तरह छोड़ना चाहते हैं, यह compact करने से बेहतर है, क्योंकि यह एक ऐसे prefix तक truncate कर देता है जो पहले से cached है। /recap history को replace करने के बजाय command output के रूप में summary जोड़ता है, जिससे cached prefix intact रहता है।

Automatic compaction के बार-बार चलने पर यह प्रिंट होता है:

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

Compaction सफल रहा, लेकिन किसी file या tool output ने लगातार कई बार window को भर दिया, इसलिए Claude Code ने retry करना बंद कर दिया। Recovery के लिए oversized file को line ranges में पढ़ें, /compact को एक ऐसे focus के साथ चलाएं जो बड़े output को हटा दे, उस काम को subagent पर भेजें, या यदि पिछली conversation पूरी हो गई है तो /clear का उपयोग करें।

MCP servers का overhead निश्चित होता है

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

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

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

Context में जाने से पहले verbose tool output को filter करें

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

Source पर ही filter करें। Claude द्वारा देखे जाने से पहले test run को केवल failures तक सीमित करने वाला hook, output के उस बड़े ढेर को कुछ सौ tokens में बदल देता है, इस turn पर और इसके हर resend पर:

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

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

Agent के reading scope को सीमित करें, और शोर वाले कार्यों को delegate करें

यदि prompt में किसी file का नाम और symptom दिया गया है, तो agent केवल उसी file को पढ़ता है। यदि project को व्यवस्थित करने के लिए open request दी गई है, तो agent स्वयं तय करता है कि कौन सी जानकारी relevant है, और वे सभी reads context window में रहते हैं।

Verbose कार्यों को subagent को delegate करें। Test runs और log processing दोनों ही context का अधिक उपयोग करते हैं; subagent उस output को अपने स्वयं के window में रखता है और केवल एक summary वापस करता है। इसका tradeoff यह है कि: पहले call पर subagent का अपना cache खाली होता है, और subscription होने पर भी यह five-minute cache lifetime का उपयोग करता है। Delegation आपके main context को सुरक्षित रखता है। यह हमेशा total tokens को कम नहीं करता है।

Cache clock: stints mein kaam karein

Prompt caching ki wajah se resend affordable ho jata hai: prefix read karne ke liye base input rate ka 0.1x, write karne ke liye 1.25x, ya ek-ghante ki lifetime ke liye 2x charge lagta hai. Har use ke saath entry bina kisi extra cost ke refresh ho jati hai, isliye clock last use se chalti hai.

Aapko kaunsi lifetime milegi, yeh aapke authentication method par depend karta hai. Isliye "aapka cache paanch minute mein expire ho jata hai" jaise general statements galat hote hain.

• Claude subscription par, Claude Code automatically ek-ghante ki lifetime request karta hai.
• Jab aap apne plan ki limit cross kar lete hain aur usage credits ka istemaan karte hain, toh us usage ke liye billing hoti hai, isliye lifetime ghatkar paanch minute ho jati hai.
• API key ya cloud provider par, yeh paanch minute par hi rehti hai. ENABLE_PROMPT_CACHING_1H=1 ek-ghante ki lifetime ka option deta hai, aur FORCE_PROMPT_CACHING_5M=1 ise wapas kam kar deta hai.

Dono hi cases mein kaam karne ka tarika ek hi hai: continuous stints mein kaam karein, kyunki lifetime ke baad ka idle gap aapke agle turn mein poore accumulated prefix ko phir se write karwa deta hai. Ek tmux mein detached Claude Code session idle rehne par koi cost nahi leta, aur idle time ka fayda warm cache se milta hai.

Kuch actions kaam ke dauran hi cache ko delete kar dete hain: models badalna, effort level badalna, fast mode on karna, MCP server connect ya disconnect karna, plugin enable ya disable karna, kisi poore tool ko deny karna, compacting, aur Claude Code upgrade karna. /model ek aam surprise hai, kyunki har model ka apna cache hota hai, isliye content identical hone ke bawajood agla request bina kisi cache hit ke poori history read karta hai.

Files edit karna, CLAUDE.md edit karna, skills aur commands ko invoke karna, /recap run karna, rewinding, aur subagent spawn karna, sab cache ko barkarar rakhte hain. Yeh ek machine aur ek directory tak limited hai, isliye alag-alag directories mein chalne wale do sessions ek dusre ka cache use nahi kar sakte.

Caching kaam kar rahi hai ya nahi, yeh dekhne ke liye current_usage padhein. cache_creation_input_tokens cache write rate par likha gaya tha; cache_read_input_tokens standard input rate ke lagbhag ek-dasve (1/10) hisse par serve kiya gaya tha. High read-to-creation ratio ek achha sanket hai. Agar creation har turn mein high rehta hai, toh iska matlab hai ki aapke prefix mein kuch badal raha hai.

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

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

API में Context editing और compaction दो अलग चीजें हैं

यदि आप Messages API पर अपना खुद का agent बना रहे हैं, तो कोई slash commands उपलब्ध नहीं होते हैं और आपको इन्हें स्वयं implement करना होगा। दो server-side features इस कार्य को करते हैं, और वे एक ही feature नहीं हैं।

Context editing बातचीत के इतिहास (conversation history) के बढ़ने पर उसमें से विशिष्ट content को चुनिंदा रूप से हटा देता है। यह हटाए गए प्रत्येक परिणाम को placeholder text से बदल देता है ताकि Claude को पता चल सके कि कुछ हटाया गया है। यह एक beta है: anthropic-beta: context-management-2025-06-27 भेजें और context_management.edits के अंतर्गत strategies configure करें। clear_tool_uses_20250919 tool results को हटाता है, और clear_thinking_20251015 thinking blocks को manage करता है। इसका trigger डिफ़ॉल्ट रूप से 100,000 input tokens पर सेट है, keep पिछले 3 tool uses पर, और clear_tool_inputs false पर, ताकि inputs बने रहें और केवल results हटें।

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

Compaction का एक handoff rule है जो agents को चुपचाप खराब कर देता है। response की शुरुआत एक compaction content block से होती है जिसमें summary होती है, जिसके बाद सामान्य text block आता है। आपको उस block को बाद के requests में वापस भेजना होगा, और API उसके पहले के सभी content blocks को हटा देता है। व्यावहारिक रूप से: केवल text ही नहीं, बल्कि response.content का पूरा हिस्सा append करें।

Anthropic का documentation server-side compaction को लंबी बातचीत में context manage करने की प्राथमिक strategy बताता है, और context editing को उस content पर सूक्ष्म नियंत्रण (finer control) पाने का विकल्प बताता है जिसे हटाया जाना है। पहले model support की जाँच करें। वर्तमान Opus, Sonnet और Fable models compaction को support करते हैं; claude-haiku-4-5 नहीं करता है, और compaction page पर live list उपलब्ध है। इनमें से कोई भी Claude Code के /compact को संचालित नहीं करता है, जिसे इसके documentation में client द्वारा भेजी गई एक-बार की summarization request बताया गया है।

FAQ

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

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

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

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

मैं यह कैसे देख सकता हूँ कि Claude Code context window का उपयोग क्या कर रहा है?

/context चलाएँ, या प्रत्येक item का पूरा breakdown देखने के लिए /context all चलाएँ। यह system prompt, tool definitions, MCP servers, memory files, और history को एक colored grid के रूप में दिखाता है। यह context-heavy tools और memory bloat के लिए सुझाव भी देता है। Paid plan पर, /usage हाल ही के usage को individual skills, subagents और MCP servers के साथ भी जोड़ता है।

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

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

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

Context editing चुनिंदा रूप से पुराने content (मुख्य रूप से tool results) को हटाता है, और जहाँ वे थे वहाँ placeholder text छोड़ देता है ताकि Claude को पता रहे कि उन्हें हटा दिया गया है। Compaction एक summary बनाता है और पूरी history को उससे बदल देता है। Anthropic के documentation में compaction को long-running conversations के लिए प्राथमिक strategy बताया गया है, और context editing को एक fine-grained option के रूप में रखा गया है। दोनों ही betas हैं और Claude Code के /compact से अलग हैं।