Claude Code session संथ आणि खर्चिक का होते?

Claude Code session संथ आणि खर्चिक होण्यापासून कशी थांबवावी

Claude Code session संथ आणि खर्चिक होते कारण प्रत्येक turn मध्ये संपूर्ण context पुन्हा पाठवला जातो आणि तो context सतत वाढत जातो. याचे निराकरण करण्यासाठी ठराविक क्रमाने स्वच्छता (hygiene) करणे आवश्यक आहे. विंडोमध्ये काय भरत आहे हे पाहण्यासाठी /context चालवा, प्रत्येक request साठी पैसे लागणारे items काढून टाका, त्यानंतर असंबधित tasks मध्ये /clear वापरा आणि एका लांब task मध्ये सूचना देण्यासाठी /compact वापरा. सततच्या कामाच्या तुकड्यांमध्ये (continuous stints) काम करा, कारण cold prompt cache मुळे स्वस्त read चे रूपांतर तुम्ही म्हटलेल्या सर्व गोष्टींच्या पूर्ण re-write मध्ये होते.

meter का चालतो याचे उत्तर agent session मधील token meter मध्ये दिले आहे.

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

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

/context [all] सध्याच्या context वापराचा रंगीत ग्रिड दर्शवते, ज्यामध्ये context-heavy टूल्स आणि memory bloat साठी optimization सूचना असतात; all फुलस्क्रीन मोडमध्ये प्रत्येक आयटमचा तपशील विस्तारते. निकाल पाच भागांमध्ये (buckets) वाचा.

• The system prompt. Claude Code च्या स्वतःच्या harness सूचना. सेशनसाठी स्थिर (fixed) असतात.
• Tool definitions. एजंट कॉल करू शकणाऱ्या प्रत्येक टूलचे schema, ज्यामध्ये प्रत्येक कनेक्टेड MCP (Model Context Protocol) सर्व्हर समाविष्ट आहे.
• Memory files. CLAUDE.md आणि auto memory, जे सेशन सुरू होताना लोड केले जातात.
• Files and tool results. वाचलेली प्रत्येक फाईल आणि तुमच्या कमांड्सनी प्रिंट केलेला सर्व डेटा.
• Message history. तुमचे प्रश्न आणि त्यांची उत्तरे.

पहिले तीन घटक हे 'fixed tax' आहेत, जे सेशनच्या कालावधीत प्रत्येक विनंतीसाठी (request) लागतात. शेवटचे दोन घटक वाढत जातात. सुरुवातीला एकदाच 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.

पहिली एक hard limit आहे आणि विनंती नाकारली जाते; संबंधित API (application programming interface) error Prompt is too long असा असतो. दुसरी एक compaction window आहे, जी 1 million token मॉडेलवर मॉडेलच्या वास्तविक context window पेक्षा कमी असू शकते. त्यानंतरही विनंत्या यशस्वी होतात, त्यामुळे ती नाकारण्याऐवजी एक चेतावणी (warning) आहे.

पेड प्लॅनवर, /usage दुसरी बाजू जोडते, जे long context किंवा cache misses सारख्या वर्तनांना फ्लॅग करते आणि अलीकडील वापराचे श्रेय वैयक्तिक skills, subagents आणि MCP servers ला देते.

CLAUDE.md is a permanent tax, so keep it lean

Your CLAUDE.md is loaded into context at session start and stays there. If it holds a detailed deployment procedure, those tokens are present while you fix a typo in a test file. Anthropic's guidance is to include only essentials and keep the file under 200 lines.

Move procedures into skills. A skill loads only when invoked, so a workflow you run twice a week costs nothing on the other days. Skills have their own budget after a compaction: bodies are re-injected, capped at 5,000 tokens per skill and 25,000 in total, oldest dropped first. Truncation keeps the start of the file, so put the most important instructions near the top of SKILL.md.

What survives a compaction decides where an instruction belongs.

• The system prompt and output style are unchanged, because they are not part of message history.
• The project-root CLAUDE.md, unscoped rules, and auto memory are re-injected from disk.
• A rule with paths: frontmatter is lost until a matching file is read again.
• A nested CLAUDE.md in a subdirectory is lost until a file in that subdirectory is read again.
• Hooks are unaffected, because a hook runs as code and never enters context.

So a rule you depend on belongs in the project-root CLAUDE.md: Claude Code clears older tool outputs first and then summarizes, so instructions from early in the conversation may be lost. Edit memory with /memory. Claude Code holds the copy it loaded at session start, so a mid-session trim keeps the prompt cache and does not apply until the next /clear, /compact, or restart.

/clear कामांमध्ये वापरण्यासाठी, /compact एकाच कामासाठी

हे दोन्ही पर्याय सारखे वाटू शकतात, परंतु त्यांच्या खर्चात मोठा फरक आहे.

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

/compact [instructions] त्याच conversation मध्ये context मोकळा करते: ते आतापर्यंतचा इतिहास summarize करते आणि तो बदलून टाकते. जेव्हा तुम्हाला एकाच कामात continuity हवी असते, तेव्हा याचा वापर करा.

/compact ला नेहमी instruction द्या. केवळ /compact वापरल्यास default prompt नुसार summarization होते, ज्याला तुम्हाला कामाचा कोणता भाग हवा आहे हे माहित नसते. 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) उपलब्ध नाही.

येथे दोन खर्चांबाबत गोंधळ होऊ शकतो. summarization request मध्ये तुमचा prefix समाविष्ट असतो, त्यामुळे ते history पुन्हा process करण्याऐवजी existing cache वाचते आणि त्याचा बहुतेक वेळ summary तयार करण्यात जातो. मोठ्या context ला compact करणे हा अजूनही एक मोठा request असतो, कारण ज्या conversation चे summarization करायचे आहे तोच input असतो. compaction नंतरचा turn स्लो नसतो: ते खूप लहान prompt साठी cache पुन्हा तयार करते.

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

Automatic compaction वारंवार घडल्यास हे प्रिंट होते:

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

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

MCP servers are fixed overhead

तुम्ही कनेक्ट केलेल्या प्रत्येक MCP server मुळे संपूर्ण session मधील प्रत्येक request वर अतिरिक्त भार पडतो. तुम्ही त्या tool चा वापर केला असो वा नसो, त्याचा खर्च येतो.

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

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

Context मध्ये जाण्यापूर्वी verbose tool output फिल्टर करा

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

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

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

Hooks स्वतः कधीही context मध्ये येत नाहीत, कारण ते code म्हणून चालतात. ज्या tool चे output स्क्रीनच्या मर्यादेपलीकडे जाते, त्यांच्यासाठी असे करा. हीच logic 3,000-line फाईलसाठी देखील लागू होते: तुम्हाला हव्या असलेल्या line range ची मागणी करा, कारण फाईल एकदा context मध्ये आली की ती window मध्ये राहते.

Agent काय वाचतो याची व्याप्ती ठरवा आणि गोंधळात टाकणारी कामे सोपवा

ज्या prompt मध्ये फाईलचे नाव आणि लक्षणे (symptom) दिली आहेत, agent ती फाईल वाचतो. प्रोजेक्ट व्यवस्थित करण्यासाठी दिलेली खुली (open) request agent ला आवश्यक वाटेल ती सर्व माहिती वाचण्यास सांगते, आणि त्यातील प्रत्येक वाचन context window मध्ये राहते.

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

कॅशे क्लॉक: सलग कामाचे टप्पे

Prompt caching मुळे पुन्हा पाठवणे (resend) परवडणारे होते: prefix वाचण्यासाठी base input rate च्या 0.1x, ते लिहिण्यासाठी 1.25x, किंवा एक तासाच्या lifetime साठी 2x दर लागतो. प्रत्येक वापरामुळे कोणतीही अतिरिक्त किंमत न लागता entry refresh होते, त्यामुळे clock शेवटच्या वापरापासून सुरू होतो.

तुम्हाला कोणता lifetime मिळेल हे तुम्ही कशा प्रकारे authenticate करता यावर अवलंबून असते. त्यामुळेच "तुमची कॅशे पाच मिनिटांनी संपते" असे सर्वत्र लागू होत नाही.

• Claude subscription मध्ये, Claude Code आपोआप one-hour lifetime request करते.
• एकदा का तुम्ही तुमच्या plan ची मर्यादा ओलांडली आणि usage credits वापरण्यास सुरुवात केली की, त्या वापरासाठी शुल्क आकारले जाते, त्यामुळे lifetime पाच मिनिटांवर येते.
• API key किंवा cloud provider वर, ते पाच मिनिटांवर राहते. ENABLE_PROMPT_CACHING_1H=1 मुळे one-hour lifetime मिळते, आणि FORCE_PROMPT_CACHING_5M=1 मुळे ते पुन्हा कमी होते.

दोन्ही प्रकरणांमध्ये कामाचा ताल (rhythm) सारखाच आहे: सलग टप्प्यात काम करा, कारण lifetime च्या पलीकडे असलेला idle gap तुमच्या पुढच्या वेळी संपूर्ण accumulated prefix पुन्हा लिहिण्यास भाग पाडतो. tmux मधील detached Claude Code session idle असताना काहीही खर्च करत नाही, आणि idle वेळेमुळे मिळणारा warm cache हाच तुमचा फायदा असतो.

काही कृतींमुळे तुम्ही काम करत असतानाच कॅशे निघून जातो: models बदलणे, effort level बदलणे, fast mode चालू करणे, MCP server कनेक्ट किंवा डिस्कनेक्ट करणे, plugin enable किंवा disable करणे, संपूर्ण tool ना नकार देणे, compacting, आणि Claude Code upgrade करणे. /model हे सामान्य आश्चर्य आहे, कारण प्रत्येक model ची स्वतःची कॅशे असते, त्यामुळे मजकूर identical असूनही पुढच्या request मध्ये कोणतीही cache hit न होता संपूर्ण history वाचावे लागते.

Files edit करणे, CLAUDE.md edit करणे, skills आणि commands वापरणे, /recap चालवणे, rewinding, आणि subagent तयार करणे यांमुळे कॅशे कायम राहतो. हे एका machine आणि एका directory पर्यंत मर्यादित असते, त्यामुळे वेगवेगळ्या directories मधील दोन sessions एकमेकांची कॅशे वापरू शकत नाहीत.

कॅशिंग काम करते की नाही हे पाहण्यासाठी current_usage वाचा. cache_creation_input_tokens हा cache write rate वर लिहिला गेला होता; cache_read_input_tokens हा standard input rate च्या साधारण दहाव्या भागात सर्व्ह केला गेला होता. High read-to-creation ratio असणे चांगले लक्षण आहे. जर creation दर सतत उच्च राहत असेल, तर तुमच्या prefix मधील काहीतरी सतत बदलत आहे.

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

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

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

जर तुम्ही Messages API वर स्वतःचा agent तयार करत असाल, तर slash commands उपलब्ध नसतात आणि तुम्हाला ते स्वतः लागू करावे लागतात. दोन server-side फीचर्स हे काम करतात आणि ते दोन्ही सारखी वैशिष्ट्ये नाहीत.

Context editing संभाषणाच्या इतिहासातील (conversation history) विशिष्ट मजकूर निवडकपणे काढून टाकते. जसा इतिहास वाढतो, तसा तो मजकूर काढून त्या जागी placeholder text टाकले जाते, जेणेकरून Claude ला काहीतरी काढले गेले आहे हे समजेल. हे beta आहे: anthropic-beta: context-management-2025-06-27 पाठवा आणि context_management.edits अंतर्गत strategies कॉन्फिगर करा. clear_tool_uses_20250919 मुळे tool results निघून जातात आणि clear_thinking_20251015 thinking blocks व्यवस्थापित करते. याचा 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 नियम आहे ज्यामुळे agents मध्ये त्रुटी येऊ शकतात. प्रतिसाद (response) compaction content block ने सुरू होतो ज्यामध्ये सारांश असतो, त्यानंतर सामान्य text block येतो. तुम्हाला तो block नंतरच्या requests मध्ये पुन्हा पाठवणे आवश्यक आहे, त्यानंतर API त्या आधीचे सर्व content blocks काढून टाकते. प्रत्यक्ष व्यवहारात: फक्त text न पाठवता, response.content पूर्णपणे append करा.

Anthropic च्या documentation नुसार, server-side compaction हे दीर्घकालीन संभाषणांमध्ये context व्यवस्थापित करण्यासाठीची प्राथमिक strategy आहे, तर context editing हे काय काढायचे यावर सूक्ष्म नियंत्रण मिळवण्यासाठीचे (finer control) वैशिष्ट्य आहे. प्रथम model support तपासा. सध्याचे Opus, Sonnet आणि Fable models compaction ला सपोर्ट करतात; claude-haiku-4-5 ला करत नाही, आणि compaction पेजवर याची live list उपलब्ध आहे. यापैकी कोणतेही beta Claude Code च्या /compact ला नियंत्रित करत नाही, ज्याचे documentation मध्ये वर्णन केल्याप्रमाणे क्लायंटद्वारे पाठवलेली एक one-off summarization request आहे.

FAQ

Claude Code सेशन जितके जास्त वेळ चालेल तितके ते संथ आणि महाग का होते?

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

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

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

Claude Code context window मध्ये काय वापरले जात आहे हे मी कसे पाहीन?

/context चालवा, किंवा प्रत्येक आयटमचा तपशीलवार तपशील पाहण्यासाठी /context all वापरा. हे system prompt, tool definitions, MCP servers, memory files आणि history एका रंगीत ग्रिडमध्ये दाखवते. तसेच context-heavy tools आणि memory bloat साठी सूचना देखील देते. पेड प्लॅनवर, /usage अलीकडील वापराचे श्रेय वैयक्तिक skills, subagents आणि MCP servers ला देखील देते.

Compacting करण्याऐवजी मी 1 million token context window वापरले पाहिजे का?

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

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

Context editing जुना मजकूर, प्रामुख्याने tool results, निवडकपणे काढून टाकते आणि जिथे तो मजकूर होता तिथे placeholder text ठेवते, जेणेकरून Claude ला तो भाग काढला गेला आहे हे समजेल. Compaction एक summary तयार करते आणि संपूर्ण history त्याच्या जागी बदलते. Anthropic च्या documentation नुसार, compaction ही दीर्घकाळ चालणाऱ्या संभाषणांसाठी प्राथमिक रणनीती आहे, तर context editing हा एक सूक्ष्म (fine-grained) पर्याय आहे. दोन्ही सध्या beta मध्ये आहेत आणि Claude Code च्या /compact पासून वेगळे आहेत.