Claude Code सत्र मंद आणि महाग होऊ नये यासाठी उपाय

दीर्घ Claude Code सत्र मंद आणि महाग होण्यापासून कसे थांबवावे

दीर्घ Claude Code सत्र मंद आणि महाग होते, कारण प्रत्येक turn मध्ये संपूर्ण context पुन्हा पाठवला जातो आणि तो context सतत वाढत राहतो. यावर उपाय म्हणजे ठरावीक क्रमाने hygiene करणे. कोणत्या गोष्टी window भरत आहेत हे पाहण्यासाठी /context चालवा, प्रत्येक request मध्ये ज्यासाठी पैसे मोजावे लागतात त्या बाबी कमी करा, त्यानंतर असंबंधित tasks दरम्यान /clear वापरा आणि एका दीर्घ task मध्ये सूचना देऊन /compact वापरा. सलग stints मध्ये काम करा, कारण cold prompt cache मुळे स्वस्त read ऐवजी तुम्ही आतापर्यंत सांगितलेल्या प्रत्येक गोष्टीचे पूर्ण re-write करावे लागते.

Agent session मागील token meter कशामुळे चालतो, याचे उत्तर agent session मागील token meter येथे दिले आहे.

काहीही बदलण्यापूर्वी /context वाचा

विंडोमध्ये काय भरले आहे याचा अंदाज लावू नका. Claude Code तुम्हाला ते सांगेल.

/context [all] सध्याच्या context वापराचे रंगीत grid दाखवते. तसेच context-heavy साधने आणि memory bloat यांसाठी optimization सूचना देते; all fullscreen mode मध्ये प्रत्येक घटकाचे सविस्तर विभाजन दाखवते. परिणामाचे पाच buckets म्हणून वाचन करा.

• System prompt. Claude Code च्या स्वतःच्या harness सूचना. त्या session साठी स्थिर असतात.
• Tool definitions. Agent कॉल करू शकणाऱ्या प्रत्येक tool चे schema. यात प्रत्येक जोडलेला MCP (Model Context Protocol) server समाविष्ट असतो.
• Memory files. Session सुरू होताना लोड होणाऱ्या CLAUDE.md आणि auto memory फाइल्स.
• Files and tool results. वाचलेली प्रत्येक file आणि तुमच्या commands ने परत छापलेली प्रत्येक गोष्ट.
• Message history. तुमचे turns आणि त्याची replies.

पहिल्या तीन घटकांचा fixed tax प्रत्येक request वेळी session च्या संपूर्ण कालावधीत भरावा लागतो. शेवटचे दोन घटक वाढत जातात. सुरुवातीला fixed tax एकदाच कमी करा; वाढणारा भाग सतत व्यवस्थापित करा.

Window भरल्याचे दोन strings सांगतात:

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 नाकारली जाते; त्यासंबंधित API (application programming interface) error Prompt is too long असा दिसतो. दुसरी compaction window आहे. 1 million token model मध्ये ती वास्तविक context window पेक्षा कमी असू शकते. तिच्यापुढेही requests यशस्वी होतात. त्यामुळे ती refusal नसून warning असते.

Paid plan वर /usage दुसरा भागही जोडते. ते long context किंवा cache misses सारख्या वर्तनांची नोंद करते आणि अलीकडील वापराचे श्रेय individual skills, subagents आणि MCP servers यांना देते. Allowance आधीच खर्च झाल्याचे ते सांगत असल्यास, तुम्ही कोणत्या limit window ची प्रतीक्षा करत आहात यावरून context कमी केल्याने आत्ता मदत होईल की काम पुन्हा सुरू करण्यासाठी वेगळा मार्ग घ्यावा लागेल हे ठरते.

CLAUDE.md हा कायमचा कर असतो; त्यामुळे तो संक्षिप्त ठेवा

तुमचा CLAUDE.md सत्र सुरू होताना context मध्ये load होतो आणि तिथेच राहतो. त्यात deployment ची सविस्तर प्रक्रिया असल्यास, test file मधील typo दुरुस्त करतानाही ते tokens उपस्थित असतात. Anthropic च्या मार्गदर्शनानुसार त्यात फक्त आवश्यक सूचना असाव्यात आणि ही file 200 lines पेक्षा कमी असावी.

प्रक्रिया skills मध्ये हलवा. Skill फक्त invoke केल्यावर load होतो. त्यामुळे आठवड्यातून दोनदा चालवलेल्या workflow चा इतर दिवशी कोणताही खर्च होत नाही. Compaction नंतर skills साठी स्वतंत्र budget असतो: प्रत्येक skill साठी 5,000 tokens आणि एकूण 25,000 tokens. सर्वात जुने skills आधी काढले जातात. Truncation मुळे file ची सुरुवात कायम राहते. त्यामुळे SKILL.md च्या सुरुवातीला सर्वात महत्त्वाच्या सूचना ठेवा.

Compaction नंतर काय टिकून राहते, यावर एखादी सूचना कुठे ठेवायची हे ठरते.

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

म्हणून ज्या rule वर तुम्ही अवलंबून आहात ती project-root CLAUDE.md मध्ये असावी. Claude Code आधी जुने tool outputs काढून टाकतो आणि त्यानंतर summary तयार करतो. त्यामुळे संभाषणाच्या सुरुवातीच्या सूचना गमावल्या जाऊ शकतात. /memory वापरून memory संपादित करा. Claude Code सत्र सुरू होताना load केलेली copy context मध्ये ठेवतो. त्यामुळे सत्राच्या मध्यावर केलेली trim prompt cache कायम ठेवते आणि पुढील /clear, /compact किंवा restart होईपर्यंत लागू होत नाही. Context गमावणे हे एखादा rule पाळला न जाण्याचे एकमेव कारण नाही. त्यामुळे rule window मध्ये स्पष्टपणे उपलब्ध असूनही दुर्लक्षित होत असेल, तर तो पुन्हा लिहिण्यापूर्वी इतर कारणांचा तपास करा.

कार्यांमध्ये /clear, एका कार्यात /compact

ही दोन commands परस्पर समान वाटतात; मात्र त्यांची किंमत खूप वेगळी असते.

/clear [name] रिकाम्या context सह नवीन conversation सुरू करते. ती कोणतीही request पाठवत नाही, त्यामुळे तिची किंमत शून्य असते. मागील conversation ला /resume picker मध्ये label देण्यासाठी name द्या; /reset आणि /new हे aliases आहेत. असंबंधित task कडे वळताच याचा वापर करा. अन्यथा जुन्या task ची माहिती नवीन task मधील प्रत्येक message सोबत पुन्हा पाठवली जाईल आणि पुन्हा bill केली जाईल.

/compact [instructions] त्याच conversation मध्ये पुढे सुरू ठेवत context कमी करते. ती आतापर्यंतच्या history चा summary तयार करून मूळ history च्या जागी ठेवते. continuity आवश्यक असलेल्या एका दीर्घ task मध्ये याचा वापर करा.

/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. दाखवते. याचा अर्थ फक्त अद्याप कोणतीही history उपलब्ध नाही.

येथे दोन वेगवेगळ्या खर्चांचा गोंधळ होतो. Summarization request तुमचा prefix share करते. त्यामुळे history पुन्हा process करण्याऐवजी ती विद्यमान cache वाचते आणि तिचा बहुतांश वेळ summary तयार करण्यात जातो. मोठा context compact करणे तरीही मोठी request असते, कारण summarize केली जाणारी conversation हीच input असते. Compaction नंतरचा turn हा धीमा भाग नसतो. तो खूपच लहान prompt साठी cache पुन्हा तयार करतो.

यासाठी दोन कमी खर्चिक commands उपलब्ध आहेत. /rewind [description] code आणि conversation ला checkpoint पर्यंत rollback करते. एखादा path पूर्णपणे सोडायचा असल्यास compact करण्यापेक्षा ही command चांगली आहे, कारण ती आधीच cached असलेल्या prefix पर्यंत मजकूर कमी करते. /recap history बदलण्याऐवजी command output म्हणून summary जोडते. त्यामुळे cached prefix तसाच राहतो.

Automatic compaction वारंवार सुरू झाल्यास हे छापले जाते:

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

Compaction यशस्वी झाले; मात्र file किंवा tool output ने window सलग अनेक वेळा पुन्हा भरली. त्यामुळे Claude Code ने पुन्हा प्रयत्न करणे थांबवले. मोठ्या file मधील मजकूर line ranges मध्ये वाचून, मोठा output वगळणारा focus देऊन /compact चालवून, ते काम subagent कडे हलवून किंवा आधीची conversation पूर्ण झाली असल्यास /clear वापरून पुनर्प्राप्त करा.

MCP servers स्थिर overhead असतात

तुम्ही जोडलेला प्रत्येक MCP server संपूर्ण session मधील प्रत्येक request मध्ये भर घालतो. तुम्ही तो वापरलात किंवा नाही, तरी त्याची किंमत मोजावी लागते.

Claude Code ही अडचण काही प्रमाणात कमी करतो. MCP tool definitions डीफॉल्टनुसार deferred असतात. त्यामुळे Claude एखादे विशिष्ट tool वापरेपर्यंत context मध्ये फक्त tool names येतात. तुमच्या servers ची प्रत्यक्ष किंमत पाहण्यासाठी /context चालवा. आज वापरणार नसलेला server काढण्यासाठी /mcp disable <name> चालवा. तुम्ही स्वतःचे MCP servers VPS वर चालवत असल्यास, किती tools एका server ने उपलब्ध करून द्यावेत यावर हीच गणना मर्यादा घालते.

हे session च्या सुरुवातीलाच करा. Definitions deferred असताना server जोडणे किंवा disconnect करणे केवळ conversation मध्ये भर घालते आणि cache कायम राहतो. त्याऐवजी definitions prefix मध्ये load होत असल्यास, म्हणजे tool search बंद असल्यास किंवा एखादा server deferral मधून वगळला असल्यास, हाच बदल केल्यावर पुढील request मध्ये सर्वकाही पुन्हा वाचले जाते.

Tool चा verbose output context मध्ये जाण्यापूर्वी filter करा

Tool चा result हा input असतो आणि पुढील प्रत्येक turn मध्ये तो पुन्हा पाठवला जातो. 20,000 tokens चा output देणारी test run ही एकदाच होणारी किंमत नाही. तो output window मधून बाहेर जाईपर्यंत प्रत्येक turn मध्ये त्यासाठी पुन्हा किंमत मोजावी लागते.

Source वरच filter करा. Claude ला output दिसण्यापूर्वी test run मधील फक्त failures ठेवणारा hook, मोठ्या output ला या turn मध्ये आणि प्रत्येक resend मध्ये काहीशे tokens मध्ये कमी करतो:

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

Hooks स्वतः context मध्ये प्रवेश करत नाहीत, कारण ते code म्हणून चालतात. ज्याच्या output ची लांबी एका screen पेक्षा जास्त आहे अशा कोणत्याही tool साठी ही पद्धत वापरा. हाच नियम 3,000-line file साठीही लागू होतो: आवश्यक line range मागा, कारण पूर्ण file एकदा आल्यावर ती window मध्येच राहते.

एजंटने काय वाचावे याची व्याप्ती निश्चित करा आणि जास्त आउटपुट असलेली कामे सोपवा

फाइलचे नाव आणि लक्षण स्पष्टपणे नमूद करणारा prompt ती फाइल वाचतो. प्रकल्प व्यवस्थित करण्याची खुली विनंती केल्यास एजंटला संबंधित वाटणाऱ्या सर्व गोष्टी तो वाचतो आणि त्या प्रत्येक वाचनाचा संदर्भ window मध्येच राहतो.

जास्त आउटपुट असलेले काम subagent कडे सोपवा. Test runs आणि log processing या दोन्हींमध्ये वास्तविक context वापरला जातो; subagent हे आउटपुट स्वतःच्या window मध्ये ठेवतो आणि फक्त सारांश परत करतो. यातील तडजोड अशी आहे: subagent स्वतःचा cache तयार करतो, त्यामुळे पहिल्या call वेळी cache hit मिळत नाही; तसेच subscription असतानाही पाच मिनिटांचा cache lifetime लागू राहतो. Delegation मुळे तुमच्या मुख्य context चे संरक्षण विश्वसनीयपणे होते. मात्र एकूण tokens नेहमीच कमी होतील असे नाही.

कॅशचे घड्याळ: सलग सत्रांमध्ये काम करा

Prompt caching मुळे prompt पुन्हा पाठवणे परवडते: prefix वाचण्यासाठी मूळ input दराच्या 0.1x इतका खर्च होतो, तर तो लिहिण्यासाठी 1.25x इतका खर्च होतो; one-hour lifetime मध्ये लिहिण्यासाठी हा दर 2x असतो. प्रत्येक वापरामुळे entry कोणत्याही अतिरिक्त खर्चाशिवाय refresh होते, त्यामुळे घड्याळ शेवटच्या वापरापासून सुरू होते. हे multipliers बिलाची रचना दाखवतात, परंतु एकूण रक्कम दाखवत नाहीत. त्यामुळे एक million tokens साठी प्रत्यक्ष किती खर्च येतो हे पाहून पूर्ण context window ची डॉलरमधील किंमत काढा.

तुम्हाला कोणता lifetime मिळतो हे authentication पद्धतीवर अवलंबून असते. त्यामुळे "तुमचा cache पाच मिनिटांनी expire होतो" असे सर्वांसाठी सांगणे चुकीचे आहे.

• Claude subscription वर Claude Code आपोआप one-hour lifetime ची विनंती करतो.
• तुमच्या plan ची मर्यादा संपल्यानंतर usage credits वापरल्यास त्या वापरासाठी billing होते आणि lifetime पुन्हा five minutes वर येतो.
• API key किंवा cloud provider वापरत असल्यास lifetime five minutes राहतो. ENABLE_PROMPT_CACHING_1H=1 one-hour lifetime निवडते आणि FORCE_PROMPT_CACHING_5M=1 तो पुन्हा five minutes वर आणते.

दोन्ही पद्धतींमध्ये काम करण्याचा सल्ला समान आहे: सलग सत्रांमध्ये काम करा. lifetime पेक्षा मोठा idle gap आल्यास पुढील turn मध्ये आतापर्यंत जमा झालेला संपूर्ण prefix पुन्हा लिहावा लागतो. tmux मधील detached Claude Code session idle असताना कोणताही खर्च करत नाही. मात्र idle वेळेमुळे warm cache उपलब्ध राहत नाही.

तुम्ही अजून काम करत असतानाही काही कृती cache नष्ट करतात: models बदलणे, effort level बदलणे, fast mode सुरू करणे, MCP server जोडणे किंवा तोडणे, plugin enable किंवा disable करणे, एखादे संपूर्ण tool नाकारणे, compacting करणे आणि Claude Code upgrade करणे. /model हे नेहमीचे अनपेक्षित कारण आहे. प्रत्येक model साठी स्वतंत्र cache असतो. त्यामुळे content समान असले तरी पुढील request संपूर्ण history cache hits शिवाय वाचते. हा पुन्हा केलेला read destination model च्या दराने bill होतो. म्हणून session च्या मध्ये Fable वर switch केल्यास तुमच्या संपूर्ण जमा झालेल्या history साठी Fable 5 चा प्रकाशित input दर लागू होतो.

Files संपादित करणे, CLAUDE.md संपादित करणे, skills आणि commands invoke करणे, /recap चालवणे, rewind करणे आणि subagent सुरू करणे यामुळे cache टिकून राहतो. हा cache एका machine आणि एका directory पुरता मर्यादित असतो. त्यामुळे वेगवेगळ्या directories मधील दोन sessions एकमेकांचा cache वापरू शकत नाहीत. ही मर्यादा तुमच्या account ऐवजी CLI चे अनुसरण करते. त्यामुळे cache चा कोणताही भाग Claude desktop app मध्ये जात नाही. Linux वर ते CLI सोबत स्वतंत्र beta install म्हणून चालते.

Caching कार्यरत आहे का हे पाहण्यासाठी current_usage वाचा. cache_creation_input_tokens cache write दराने लिहिले गेले. cache_read_input_tokens standard input दराच्या साधारण एक दशांश दराने पुरवले गेले. Read-to-creation ratio जास्त असणे चांगले लक्षण आहे. प्रत्येक turn नंतर creation जास्तच राहत असेल, तर तुमच्या prefix मधील काहीतरी सतत बदलत आहे.

मोठी context window ही समस्या सोडवते का?

अंशतः. सध्याच्या काही models मध्ये 1 million token context window समर्थित आहे आणि मोठ्या मर्यादेतही compaction त्याच पद्धतीने कार्य करते. Economics बदलत नाहीत, कारण प्रत्येक turn वेळी संपूर्ण prompt पुन्हा पाठवला जातो आणि त्यासाठी पुन्हा billing होते. मोठी window तुम्हाला कधी अनिवार्यपणे कृती करावी लागेल हे ठरवते; hygiene खर्च ठरवते. मर्यादा नव्हे, तर bill ही समस्या असल्यास, तुमच्या कामाच्या पद्धतीला कोणता Claude plan योग्य आहे हे ठरवते की तुम्ही dollars खर्च करत आहात की plan allowance.

API मधील context editing आणि compaction या वेगवेगळ्या गोष्टी आहेत

तुम्ही Messages API वर स्वतःचा agent तयार करत असाल, तर slash commands उपलब्ध नसतात आणि ही प्रक्रिया तुम्हालाच implement करावी लागते. या कामासाठी सुरुवातीपासूनच वेळ आणि संसाधने राखून ठेवा, कारण लहान signup credit पलीकडे API ला कोणताही free tier नाही. त्यामुळे trim न केलेल्या history मधील प्रत्येक turn चे पूर्ण billing होते. Trimming करण्यापूर्वीच तुम्ही कोणत्या provider वर build करता यामुळे हा खर्च ठरतो. त्यामुळे provider ची निवड अजून निश्चित नसेल, तर headline per-token rates ची तुलना करण्याऐवजी दोन्ही APIs वर समान workload चा खर्च मोजा. हे काम करण्यासाठी server-side दोन features आहेत. ती एकच feature नाहीत.

Context editing conversation history वाढत असताना त्यातील विशिष्ट content निवडकपणे काढून टाकते. काढलेल्या प्रत्येक परिणामाच्या जागी placeholder text ठेवले जाते, त्यामुळे काहीतरी काढले गेले आहे हे Claude ला कळते. हे beta feature आहे: anthropic-beta: context-management-2025-06-27 पाठवा आणि context_management.edits अंतर्गत strategies configure करा. clear_tool_uses_20250919 tool results काढते, तर clear_thinking_20251015 thinking blocks व्यवस्थापित करते. trigger चे default 100,000 input tokens आहे, keep चे default शेवटचे 3 tool uses आहे आणि clear_tool_inputs चे default false आहे. त्यामुळे inputs ठेवले जातात आणि फक्त results काढले जातात.

Compaction summary तयार करते आणि संपूर्ण conversation history तिच्याने बदलते. हे देखील beta feature आहे: anthropic-beta: compact-2026-01-12 पाठवा आणि compact_20260112 हा edit type वापरा. Trigger चे default {"type": "input_tokens", "value": 150000} आहे आणि value किमान 50,000 असणे आवश्यक आहे.

Compaction मध्ये एक handoff rule आहे, ज्यामुळे agents मध्ये शांतपणे समस्या निर्माण होऊ शकते. Response ची सुरुवात summary असलेल्या compaction content block ने होते आणि त्यानंतर नेहमीचा text block येतो. पुढील requests मध्ये हा block परत पाठवणे आवश्यक आहे. त्यानंतर API त्यापूर्वीचे सर्व content blocks काढून टाकते. प्रत्यक्षात, केवळ text नव्हे तर संपूर्ण response.content append करा.

Anthropic च्या documentation नुसार, दीर्घकाळ चालणाऱ्या conversations मध्ये context व्यवस्थापित करण्यासाठी server-side compaction ही प्राथमिक strategy आहे. कोणता content काढायचा यावर अधिक सूक्ष्म नियंत्रण हवे असल्यास context editing वापरता येते. आधी model support तपासा. सध्याचे Opus, Sonnet आणि Fable models compaction ला support करतात; claude-haiku-4-5 करत नाही. Compaction page वर सध्याची live list दिली आहे. कोणताही beta Claude Code चे स्वतःचे /compact चालवत नाही. त्याच्या documentation नुसार, ते client कडून पाठवलेली एकदाच केली जाणारी summarization request आहे.

FAQ

माझे Claude Code सत्र जितके जास्त वेळ चालते तितके ते धीमे आणि महाग का होते?

प्रत्येक turn वेळी संपूर्ण संभाषण पुन्हा पाठवले जाते. त्यामुळे दिवसभर उघडे असलेल्या सत्रातील एका ओळीच्या प्रश्नासोबत त्या संपूर्ण दिवसाचे संभाषणही पाठवले जाते. Prompt caching मुळे cache warm असताना हे स्वस्त राहते आणि read साठी base input rate च्या 0.1x दराने शुल्क आकारले जाते. एखाद्या turn वेळी cache miss झाल्यास तेच prefix 1.25x दराने पुन्हा लिहिले जाते. context window मध्ये काय भरत आहे हे पाहण्यासाठी /context चालवा. ही प्रक्रिया समजून घेण्यासाठी Claude Code सत्रासाठी कोणत्या गोष्टींचे शुल्क आकारले जाते हे वाचा.

Claude Code मधील /clear आणि /compact यांमध्ये काय फरक आहे?

/clear रिकाम्या context सह नवीन conversation सुरू करते. ती कोणतीही request पाठवत नाही, त्यामुळे तिच्यासाठी कोणतेही शुल्क आकारले जात नाही. परस्पर असंबंधित tasks मधील संक्रमणासाठी हा योग्य पर्याय आहे. /compact तीच conversation ठेवते आणि history च्या जागी summary ठेवते. त्यामुळे एकाच दीर्घ task च्या आत हा योग्य पर्याय आहे. /compact keep only the plan and the diff प्रमाणे त्याला focus द्या, कारण कोणती माहिती टिकून राहील हे instruction ठरवते.

माझ्या Claude Code context window मध्ये कोणती माहिती जागा वापरत आहे हे कसे पाहू?

/context चालवा किंवा प्रत्येक item चे संपूर्ण विभाजन पाहण्यासाठी /context all चालवा. यात system prompt, tool definitions, MCP servers, memory files आणि history हे रंगीत grid मध्ये दिसतात. तसेच context जास्त वापरणाऱ्या tools आणि memory bloat साठी सूचना मिळतात. सशुल्क plan वर /usage अलीकडील वापराचे श्रेय स्वतंत्र skills, subagents आणि MCP servers यांना देखील देते.

compact करण्याऐवजी 1 million token context window वापरावे का?

मोठे window समस्या सोडवत नाही; ते फक्त समस्या पुढे ढकलते. सध्याची अनेक models 1 million token context window चालवतात. त्यात Opus 4.8 आणि Sonnet 5 यांचाही समावेश आहे. तेथेही compaction त्याच प्रकारे कार्य करते. प्रत्येक turn वेळी संपूर्ण prompt पुन्हा पाठवला जातो आणि त्यासाठी शुल्क आकारले जाते. त्यामुळे 400,000-token conversation बसत असली तरी ती महागच असते.

Claude API मधील context editing आणि compaction यांमध्ये काय फरक आहे?

Context editing जुन्या content पैकी निवडक भाग, मुख्यतः tool results, साफ करते. प्रत्येक काढलेल्या भागाच्या जागी placeholder text ठेवला जातो, त्यामुळे तो काढला गेला आहे हे Claude ला समजते. Compaction summary तयार करते आणि संपूर्ण history तिच्या जागी ठेवते. दीर्घकाळ चालणाऱ्या conversations साठी compaction ही प्राथमिक strategy असल्याचे Anthropic च्या documentation मध्ये म्हटले आहे. Context editing हा सूक्ष्म नियंत्रणासाठीचा पर्याय म्हणून मांडला आहे. दोन्ही beta features आहेत आणि त्यांचे स्वतंत्र headers आहेत. दोन्ही Claude Code मधील /compact पेक्षा वेगळे आहेत.