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 एक स्थायी tax है, इसलिए इसे संक्षिप्त रखें

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

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

Compaction के बाद कौन-सी जानकारी बचती है, इससे तय होता है कि instruction कहाँ रखनी चाहिए।

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

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

कामों के बीच /clear, एक ही काम के भीतर /compact

ये दोनों commands एक-दूसरे के समान लगती हैं, लेकिन इनकी लागत में काफी अंतर होता है।

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

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

/compact को हमेशा कोई instruction दें। केवल /compact चलाने पर यह ऐसे default prompt के आधार पर summary बनाता है, जिसे यह पता नहीं होता कि काम के किस हिस्से की आपको अभी आवश्यकता है। Instruction देने पर यह उस हिस्से को बनाए रखता है:

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

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

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

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

यदि automatic compaction बार-बार शुरू हो, तो यह दिखाई देता है:

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

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

MCP servers एक स्थिर अतिरिक्त भार हैं

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

Claude Code इस प्रभाव को कम करता है। MCP tool definitions default रूप से deferred रहती हैं, इसलिए Claude के किसी specific tool का उपयोग करने तक context में केवल tool names आते हैं। अपने 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 disabled है, उपलब्ध नहीं है या उसकी auto threshold से नीचे है, तो यही बदलाव अगले 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 की 1.25x होती है, या one-hour lifetime पर 2x। इसे फिर से पढ़ने की लागत Haiku 5.5 पर 0.1x, Opus 5.5 और Sonnet 5.5 पर 0.05x ($0.20 और $0.10 per million tokens), तथा Fable 5.1 पर 0.025x ($0.25 per million) होती है। हर उपयोग entry को बिना अतिरिक्त लागत के refresh करता है, इसलिए clock last use से चलती है। ये multipliers bill का स्वरूप बताते हैं, लेकिन कुल राशि नहीं बताते। इसलिए इन्हें एक million tokens की वास्तविक लागत के साथ देखें, ताकि पूरे context window को dollars की राशि में बदला जा सके।

आपको कौन-सी lifetime मिलेगी, यह इस बात पर निर्भर करता है कि आप authenticate कैसे करते हैं। इसी कारण सामान्य रूप से यह कहना गलत है कि "आपका cache five minutes बाद expire हो जाता है।"

• Claude subscription पर Claude Code requests अपने-आप one-hour lifetime का उपयोग करती हैं।
• जब आप अपने plan की limit पार करके usage credits का उपयोग करते हैं, तो उस usage का billing होता है और lifetime फिर five minutes हो जाती है।
• API key या cloud provider पर lifetime five minutes रहती है। promptCacheTtl को 1h या ENABLE_PROMPT_CACHING_1H=1 पर set करने से one-hour lifetime चुनी जाती है, और FORCE_PROMPT_CACHING_5M=1 इसे फिर five minutes पर ले आता है।

दोनों स्थितियों में rhythm संबंधी सलाह समान है: लगातार सत्रों में काम करें, क्योंकि lifetime से अधिक लंबा idle gap होने पर अगली turn में अब तक जमा पूरा prefix फिर से लिखना पड़ता है। tmux में detached Claude Code session idle रहने पर कोई लागत नहीं लेता, लेकिन idle समय के बदले warm cache समाप्त हो जाता है।

कुछ actions आपके काम करते रहने के दौरान भी cache हटा देते हैं: models बदलना, पुराने models पर effort level बदलना, fast mode चालू करना, MCP server connect या disconnect करना, tool definitions पहले से load होने पर किसी पूरे tool को deny करना, tools जोड़ने वाले plugin को enable या disable करना, compacting करना, conversation में images की संख्या बहुत बढ़ जाने पर पुरानी images हटाना, और Claude Code upgrade करना। API key या subscription के साथ Opus 5.5, Sonnet 5.5, Haiku 5.5 और Fable 5.1 पर effort बदलने से अब cache बना रहता है। /model आम तौर पर अप्रत्याशित स्थिति होती है, क्योंकि हर model का अपना cache होता है। इसलिए अगली request पूरी history को बिना किसी cache hit के पढ़ती है, भले ही content समान हो। इस दोबारा पढ़ने का billing destination model की rates पर fresh cache write के रूप में होता है। इसलिए session के बीच Fable पर switch करने पर आपकी पूरी accumulated history के लिए Fable की प्रकाशित cache-write rates लागू होती हैं: five-minute lifetime पर $12.50 per million tokens या one-hour पर $20। यही rates Fable 5 और Fable 5.1 पर भी लागू होती हैं।

Files edit करना, CLAUDE.md edit करना, skills और commands invoke करना, /recap चलाना, rewind करना और subagent spawn करना cache को बनाए रखते हैं। इसका scope एक machine और एक directory तक सीमित है, इसलिए अलग directories में चल रहे दो sessions एक-दूसरे के cache का उपयोग नहीं कर सकते। यह scope आपके account के बजाय CLI से जुड़ा होता है। इसलिए इसका कोई हिस्सा Claude desktop app में transfer नहीं होता। Linux पर यह CLI के साथ अलग beta install है।

Caching काम कर रही है या नहीं, यह देखने के लिए current_usage पढ़ें। cache_creation_input_tokens को cache write rate पर लिखा गया था। cache_read_input_tokens को model की cache read rate पर serve किया गया था, जो model के अनुसार standard input rate की 2.5% से 10% के बीच होती है। Read-to-creation ratio अधिक होना अच्छा संकेत है। यदि creation हर turn में अधिक बनी रहती है, तो आपके prefix में कुछ लगातार बदल रहा है।

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

आंशिक रूप से। हर वर्तमान model (Fable 5.1, Opus 5.5, Sonnet 5.5 और Haiku 5.5) 1 million token context window पर चलता है, और बड़ी सीमा पर compaction उसी तरह काम करता है। Economics नहीं बदलती, क्योंकि पूरा prompt हर turn पर फिर से भेजा जाता है और उसका billing भी हर turn पर होता है। बड़ा window यह तय करता है कि आपको कब कार्रवाई करनी पड़ेगी; hygiene लागत तय करती है। यदि समस्या ceiling के बजाय bill है, तो आपके काम करने के तरीके के लिए कौन-सा Claude plan उपयुक्त है यह तय करता है कि आप dollars खर्च कर रहे हैं या plan allowance।

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

यदि आप Messages API पर अपना agent बना रहे हैं, तो इसमें कोई slash commands नहीं होतीं और आपको यह व्यवस्था स्वयं लागू करनी होगी। इस काम के लिए शुरुआत से ही बजट रखें, क्योंकि छोटे signup credit के अलावा API का कोई free tier नहीं है। हर turn में बिना trim किया गया पूरा history फिर से भेजा जाता है और उसका पूरा शुल्क लगता है: prefix cached होने पर cache read rate के अनुसार, और cached न होने पर full input rate या cache-write premium के अनुसार। कोई भी trimming होने से पहले ही आपके द्वारा चुना गया provider यह गणना तय कर देता है। इसलिए यदि चुनाव अभी खुला है, तो headline per-token rates की तुलना करने के बजाय दोनों APIs पर समान workload की लागत निकालें। यह काम दो server-side features करते हैं, लेकिन दोनों एक ही feature नहीं हैं।

Context editing conversation history बढ़ने पर उसमें से चुनी हुई specific content को हटाता है। हटाए गए प्रत्येक result की जगह 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 default 100,000 input tokens है, keep का default अंतिम 3 tool uses है और clear_tool_inputs का default false है। इसलिए inputs बने रहते हैं और केवल results हटते हैं।

Compaction एक summary बनाता है और पूरे conversation history को उससे replace कर देता है। इसके दो beta रूप हैं। Threshold compaction आपके सामान्य requests के भीतर चलता है: anthropic-beta: compact-2026-01-12 भेजें और compact_20260112 edit type इस्तेमाल करें। इसका trigger default रूप से {"type": "input_tokens", "value": 150000} है और value कम से कम 50,000 होनी चाहिए। On-demand compaction में आपका code तय करता है कि इसे कब चलाना है: top-level "compaction": {"type": "summarize"} के साथ anthropic-beta: compact-2026-09-04 भेजें। इसका response केवल summary block होता है। Anthropic का compaction overview कहता है कि जहाँ on-demand compaction उपलब्ध हो, वहाँ उसका उपयोग करें।

Threshold compaction में handoff का एक नियम है, जिसे न मानने पर agents चुपचाप विफल हो सकते हैं। Response की शुरुआत summary रखने वाले compaction content block से होती है। इसके बाद सामान्य text block आता है। बाद के requests में आपको यह block वापस भेजना होगा। इसके बाद API उससे पहले के सभी content blocks हटा देता है। व्यवहार में, response.content का पूरा भाग append करें, केवल उसका text नहीं। On-demand compaction इसके उलट काम करता है। summarized messages को आपको स्वयं हटाना होता है। Returned block को messages में सबसे पहले रखें और signature सहित उसे ठीक उसी रूप में वापस भेजें।

Anthropic का documentation server-side compaction को लंबे समय तक चलने वाली conversations में context manage करने की primary strategy बताता है। Context editing को वह यह नियंत्रित करने का विकल्प बताता है कि क्या हटाया जाए। पहले model support जाँचें। सभी current models दोनों प्रकार के compaction को support करते हैं, जिसमें Haiku 5.5 भी शामिल है। पुराना claude-haiku-4-5 इन्हें support नहीं करता। प्रत्येक compaction page पर live list दी गई है। इनमें से कोई भी beta Claude Code के अपने /compact को संचालित नहीं करता। उसके documentation के अनुसार वह एक अलग summarization request है, जिसे client आपके history के साथ भेजता है।

FAQ

मेरी Claude Code session जितनी देर चलती है, उतनी धीमी और महंगी क्यों होती जाती है?

क्योंकि हर turn पर पूरी conversation फिर से भेजी जाती है। इसलिए पूरे दिन खुली session में एक पंक्ति का सवाल भी पूरे दिन का context साथ लेकर जाता है। Prompt caching cache warm रहने तक इस लागत को कम रखती है: Haiku 5.5 पर read की लागत base input rate की 0.1x, Opus 5.5 और Sonnet 5.5 पर 0.05x, और Fable 5.1 पर 0.025x होती है। जब किसी turn में cache miss होता है, तो वही prefix 1.25x पर फिर से लिखा जाता है। एक घंटे के lifetime पर यह 2x होता है। Window में क्या भर रहा है, यह देखने के लिए /context चलाएँ। इस mechanism के लिए Claude Code session के लिए आपसे किस चीज़ का billing होता है पढ़ें।

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

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

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

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

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

बड़ी window समस्या हल करने के बजाय उसे टालती है। हर current model (Fable 5.1, Opus 5.5, Sonnet 5.5 और Haiku 5.5) 1 million token context window चलाता है। वहाँ भी compaction इसी तरह काम करता है। हर turn में पूरा prompt फिर से भेजा जाता है और उसका billing भी होता है। इसलिए 400,000-token conversation महंगी रहेगी, चाहे वह window में fit हो या नहीं।

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

Context editing पुराने content को चुनिंदा रूप से clear करता है, खासकर tool results को। हर हटाए गए item की जगह placeholder text रहता है, ताकि Claude को पता रहे कि उसे हटाया गया था। Compaction summary बनाकर पूरी history को उससे replace करता है। Anthropic के documentation में long-running conversations के लिए compaction को primary strategy बताया गया है। Context editing को fine-grained option के रूप में रखा गया है। दोनों beta features हैं और इनके अपने headers हैं। दोनों Claude Code के /compact से अलग हैं।