Claude Code సెషన్ నెమ్మదించకుండా ఎలా ఆపాలి

Claude Code సెషన్ నెమ్మదించకుండా మరియు ఖర్చు పెరగకుండా ఎలా ఆపాలి

Claude Code సెషన్ ఎక్కువ సేపు కొనసాగితే అది నెమ్మదించడమే కాకుండా ఖర్చును కూడా పెంచుతుంది. ఎందుకంటే ప్రతి turn లోనూ మొత్తం context మళ్ళీ పంపబడుతుంది, మరియు ఆ context నిరంతరం పెరుగుతూనే ఉంటుంది. దీనిని పరిష్కరించడానికి నిర్ణీత క్రమంలో కొన్ని పద్ధతులను పాటించాలి. విండోలో ఏ అంశాలు ఉన్నాయో చూడటానికి /context ఉపయోగించండి, ప్రతి request లోనూ మీరు చెల్లించే అంశాలను తొలగించండి, ఆపై సంబంధం లేని పనుల మధ్య /clear మరియు ఒకే పెద్ద పనిలో సూచనలను ఉపయోగించడానికి /compact వాడండి. పనులను నిరంతరాయంగా చేయండి, ఎందుకంటే cold prompt cache వల్ల తక్కువ ఖర్చుతో కూడిన read, మీరు చెప్పిన ప్రతిదాని యొక్క పూర్తి re-write గా మారుతుంది.

ఎందుకు ఖర్చు పెరుగుతుందో agent session వెనుక ఉన్న token meter లో వివరించబడింది.

ఏవైనా మార్పులు చేసే ముందు /context చదవండి

విండోలో ఏముందో ఊహించకండి. Claude Code మీకు తెలియజేస్తుంది.

/context [all] ప్రస్తుత context usageను రంగుల గ్రిడ్‌గా చూపుతుంది. ఇది context-heavy tools మరియు memory bloat కోసం optimization సూచనలను అందిస్తుంది; all fullscreen modeలో ప్రతి item యొక్క వివరాలను విస్తరిస్తుంది. ఫలితాన్ని ఐదు భాగాలుగా (buckets) పరిగణించండి.

• The system prompt. Claude Code యొక్క సొంత harness instructions. ఇవి session అంతా స్థిరంగా ఉంటాయి.
• Tool definitions. agent పిలవగల ప్రతి tool యొక్క schema, అన్ని connected MCP (Model Context Protocol) servers తో కలిపి.
• Memory files. session ప్రారంభంలో లోడ్ చేయబడే CLAUDE.md మరియు auto memory.
• Files and tool results. చదివిన ప్రతి file మరియు మీ commands ద్వారా వచ్చిన output.
• Message history. మీ ప్రశ్నలు మరియు వాటికి వచ్చిన సమాధానాలు.

మొదటి మూడు అంశాలు session అంతా ప్రతి request కి అయ్యే స్థిరమైన ఖర్చు (fixed tax). చివరి రెండు అంశాలు క్రమంగా పెరుగుతాయి. ప్రారంభంలోనే స్థిరమైన ఖర్చును తగ్గించుకోండి; పెరుగుతున్న భాగంపై నిరంతరం పర్యవేక్షణ ఉంచండి.

విండో నిండిపోయిందని చెప్పడానికి రెండు stringలు ఉంటాయి:

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 లో model యొక్క అసలు context window కంటే తక్కువగా ఉండవచ్చు. దీని తర్వాత కూడా requests విజయవంతమవుతాయి, కాబట్టి ఇది నిరాకరణ కంటే హెచ్చరిక మాత్రమే.

Paid plan లో, /usage మిగిలిన సగభాగాన్ని చూపుతుంది. ఇది long context లేదా cache misses వంటి ప్రవర్తనలను గుర్తించి, ఇటీవలి usage ను individual skills, subagents మరియు MCP servers కి కేటాయిస్తుంది.

CLAUDE.md అనేది శాశ్వత పన్ను వంటిది, కాబట్టి దీనిని తక్కువ పరిమాణంలో ఉంచండి

మీ CLAUDE.md సెషన్ ప్రారంభంలో context లోకి లోడ్ అవుతుంది మరియు అక్కడే ఉంటుంది. ఒకవేళ అందులో వివరణాత్మకమైన deployment procedure ఉంటే, మీరు ఒక test file లో typo ని సరిచేస్తున్నప్పుడు కూడా ఆ tokens ఖర్చవుతాయి. Anthropic మార్గదర్శకాల ప్రకారం, కేవలం అవసరమైన వాటిని మాత్రమే చేర్చాలి మరియు ఆ file ని 200 lines లోపు ఉంచాలి.

Procedures ని skills లోకి మార్చండి. ఒక skill కేవలం పిలవబడినప్పుడు మాత్రమే లోడ్ అవుతుంది, కాబట్టి వారానికి రెండుసార్లు మీరు ఉపయోగించే workflow వల్ల మిగిలిన రోజుల్లో ఎటువంటి ఖర్చు ఉండదు. Compaction తర్వాత skills కి సొంత budget ఉంటుంది: bodies మళ్లీ re-inject చేయబడతాయి, ప్రతి skill కి 5,000 tokens మరియు మొత్తం 25,000 tokens కి పరిమితి ఉంటుంది, పాతవి ముందుగా తొలగించబడతాయి. Truncation వల్ల file ప్రారంభ భాగం అలాగే ఉంటుంది, కాబట్టి అత్యంత ముఖ్యమైన సూచనలను SKILL.md యొక్క పైన ఉంచండి.

Compaction తర్వాత ఏది మిగులుతుందో, దాని ఆధారంగానే ఒక instruction ఎక్కడ ఉండాలో నిర్ణయించబడుతుంది.

• System prompt మరియు output style మారవు, ఎందుకంటే అవి message history లో భాగం కావు.
• Project-root CLAUDE.md, unscoped rules, మరియు auto memory డిస్క్ నుండి re-inject చేయబడతాయి.
• paths: frontmatter ఉన్న rule, సరిపోలే file మళ్లీ చదివే వరకు కోల్పోబడుతుంది.
• ఒక subdirectory లో ఉన్న nested CLAUDE.md, ఆ subdirectory లోని file మళ్లీ చదివే వరకు కోల్పోబడుతుంది.
• Hooks ప్రభావితం కావు, ఎందుకంటే hook కోడ్‌గా రన్ అవుతుంది మరియు ఎప్పుడూ context లోకి రాదు.

కాబట్టి మీరు ఆధారపడే rule project-root CLAUDE.md లో ఉండాలి: Claude Code పాత tool outputs ని ముందుగా క్లియర్ చేసి, ఆపై summarize చేస్తుంది, కాబట్టి సంభాషణ ప్రారంభంలో ఉన్న instructions కోల్పోయే అవకాశం ఉంది. /memory తో memory ని ఎడిట్ చేయండి. Claude Code సెషన్ ప్రారంభంలో లోడ్ చేసిన కాపీని కలిగి ఉంటుంది, కాబట్టి mid-session trim prompt cache ని అలాగే ఉంచుతుంది మరియు తదుపరి /clear, /compact, లేదా restart వరకు వర్తించదు.

/clear పనుల మధ్యలో, /compact ఒకే పనిలో వాడండి

ఈ రెండు కమాండ్లు ఒకేలా అనిపించవచ్చు, కానీ వీటి ఖర్చు వేరువేరుగా ఉంటుంది.

/clear [name] ఖాళీ context తో కొత్త సంభాషణను ప్రారంభిస్తుంది. ఇది ఎటువంటి request ని పంపదు, కాబట్టి దీనికి ఖర్చు ఉండదు. /resume picker లో పాత సంభాషణను గుర్తించడానికి ఒక పేరును ఇవ్వండి; /reset మరియు /new అనేవి దీనికి సమానమైనవి (aliases). మీరు సంబంధం లేని పనికి మారిన వెంటనే దీనిని ఉపయోగించండి, లేకపోతే పాత పని ప్రతి కొత్త మెసేజ్ తో పాటు మళ్ళీ పంపబడుతుంది మరియు మళ్ళీ బిల్లు చేయబడుతుంది.

/compact [instructions] ఒకే సంభాషణను కొనసాగిస్తూ context ని ఖాళీ చేస్తుంది: ఇది ఇప్పటివరకు ఉన్న చరిత్రను (history) సారాంశంగా (summarize) మార్చి, దాని స్థానంలో ఉంచుతుంది. మీకు కొనసాగింపు అవసరమైనప్పుడు, ఒకే సుదీర్ఘమైన పనిలో దీనిని ఉపయోగించండి.

/compact కి ఎల్లప్పుడూ ఒక instruction ఇవ్వండి. కేవలం /compact వాడితే, పనిలో మీకు ఏ భాగం అవసరమో తెలియని ఒక default prompt తో సారాంశం తయారవుతుంది. instruction ఇచ్చినప్పుడు అది సరిగ్గా ఉంటుంది:

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

ప్రతిసారీ ఒకే కారణం కోసం మీరు compact చేయాలనుకుంటే, మీ ప్రాజెక్ట్ యొక్క CLAUDE.md లో # Compact instructions heading కింద ఒక standing instructionను ఉంచండి. కొత్త session లో /compact అనేది Not enough messages to compact. అని ప్రింట్ చేస్తుంది, దీని అర్థం ఇంకా చరిత్ర (history) లేదని.

ఇక్కడ రెండు రకాల ఖర్చులు గందరగోళానికి గురవుతాయి. summarization request మీ prefix ని ఉపయోగిస్తుంది, కాబట్టి ఇది చరిత్రను మళ్ళీ ప్రాసెస్ చేయకుండా ఇప్పటికే ఉన్న cache ని చదువుతుంది, దీనివల్ల ఎక్కువ సమయం సారాంశాన్ని రూపొందించడానికే (generating) ఉపయోగపడుతుంది. పెద్ద context ని compact చేయడం అనేది ఇప్పటికీ ఒక పెద్ద request, ఎందుకంటే సారాంశం చేయబడే సంభాషణే input గా మారుతుంది. compaction తర్వాత వచ్చే turn నెమ్మదిగా ఉండదు: ఇది చాలా చిన్న prompt కోసం cache ని మళ్ళీ నిర్మిస్తుంది.

మరింత తక్కువ ఖర్చుతో కూడిన రెండు కమాండ్లు ఉన్నాయి. /rewind [description] కోడ్ మరియు సంభాషణను ఒక checkpoint కి మారుస్తుంది; మీరు పూర్తిగా వదిలేయాలనుకుంటున్న path కోసం ఇది compacting కంటే మెరుగైనది, ఎందుకంటే ఇది ఇప్పటికే cached గా ఉన్న prefix కి మారుస్తుంది. /recap చరిత్రను మార్చడానికి బదులుగా, కమాండ్ అవుట్‌పుట్‌గా సారాంశాన్ని జోడిస్తుంది, తద్వారా 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 కి బదిలీ చేయడం ద్వారా, లేదా పాత సంభాషణ పూర్తయితే /clear ఉపయోగించడం ద్వారా దీనిని సరిచేయవచ్చు.

MCP servers are fixed overhead

మీరు కనెక్ట్ చేసే ప్రతి MCP server, మొత్తం session లోని ప్రతి request కి అదనపు overhead ని జోడిస్తుంది. మీరు ఆ tool ని ఉపయోగించినా లేకపోయినా, దాని వల్ల ఖర్చు (cost) పెరుగుతుంది.

Claude Code దీని ప్రభావాన్ని తగ్గిస్తుంది. MCP tool definitions డిఫాల్ట్‌గా deferred గా ఉంటాయి, కాబట్టి Claude ఒక నిర్దిష్ట tool ని ఉపయోగించే వరకు కేవలం tool names మాత్రమే context లోకి వస్తాయి. మీ servers నిజంగా ఎంత cost అవుతున్నాయో చూడటానికి /context ని, మరియు ఈరోజు మీకు అవసరం లేని server ని తొలగించడానికి /mcp disable <name> ని ఉపయోగించండి. మీరు your own MCP servers on a VPS నడుపుతుంటే, ఒక server ఎన్ని tools ని expose చేయాలనే దానిపై కూడా ఇదే లెక్కలు వర్తిస్తాయి.

దీనిని session ప్రారంభంలో చేయండి. Definitions deferred గా ఉన్నంత కాలం, ఒక server ని కనెక్ట్ చేయడం లేదా డిస్కనెక్ట్ చేయడం కేవలం conversation కి మాత్రమే చేరుతుంది, మరియు cache అలాగే ఉంటుంది. ఒకవేళ tool search ఆపివేసి ఉన్నా లేదా ఒక server deferral నుండి మినహాయింపు పొంది ఉన్నా, definitions prefix లోకి లోడ్ అవుతాయి. అటువంటప్పుడు, పైన పేర్కొన్న మార్పు వల్ల తదుపరి request లోకి ప్రతిదీ మళ్ళీ రీడ్ చేయాల్సి వస్తుంది.

టూల్ అవుట్‌పుట్‌ను context లోకి పంపే ముందు filter చేయండి

టూల్ రిజల్ట్ అనేది ఇన్‌పుట్, మరియు ప్రతి తదుపరి turn లో ఇన్‌పుట్ మళ్ళీ పంపబడుతుంది. 20,000 tokens అవుట్‌పుట్‌ను ఇచ్చే టెస్ట్ రన్ అనేది ఒక్కసారి మాత్రమే అయ్యే ఖర్చు కాదు: అది విండో నుండి వెళ్ళిపోయే వరకు ప్రతి turn లోనూ మీరు దాని కోసం మళ్ళీ చెల్లిస్తారు.

మూలం (source) వద్దే filter చేయండి. Claude చూసే ముందే టెస్ట్ రన్‌ను కేవలం failure లకే పరిమితం చేసే hook, ఆ అవుట్‌పుట్ గోడను కొన్ని వందల tokens గా మారుస్తుంది; ఇది ప్రస్తుత turn కి మరియు దానిని మళ్ళీ పంపే ప్రతిసారీ వర్తిస్తుంది:

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

Hooks ఎప్పుడూ context లోకి ప్రవేశించవు, ఎందుకంటే అవి code గా రన్ అవుతాయి. అవుట్‌పుట్ స్క్రీన్‌ను దాటి వెళ్లే ఏ టూల్కైనా ఇలా చేయండి. 3,000-line ఫైల్‌కు కూడా ఇదే లాజిక్ వర్తిస్తుంది: మీకు కావలసిన line range ని మాత్రమే అడగండి, ఎందుకంటే ఫైల్ మొత్తం విండోలో ఉండిపోతుంది.

ఏజెంట్ చదివే పరిధిని నిర్ణయించండి మరియు అనవసరమైన పనులను వేరే వారికి అప్పగించండి

ఫైల్ పేరు మరియు సమస్యను పేర్కొనే ప్రాంప్ట్ ఆ ఫైల్‌ను చదువుతుంది. ప్రాజెక్ట్‌ను క్రమబద్ధీకరించమని అడిగినప్పుడు, ఏజెంట్ దేనిని సంబంధితమైనదిగా భావిస్తే దానిని చదువుతుంది; ఆ ప్రతి రీడ్ (read) విండోలోనే ఉంటుంది.

విస్తృతమైన పనులను subagent కి అప్పగించండి. Test runs మరియు log processing రెండూ context ని ఎక్కువగా వినియోగిస్తాయి; subagent ఆ అవుట్‌పుట్‌ను దాని స్వంత విండోలో ఉంచుకుని, కేవలం సారాంశాన్ని (summary) మాత్రమే తిరిగి ఇస్తుంది. దీని వల్ల కలిగే లాభనష్టాలు: మొదటిసారి పిలిచినప్పుడు subagent తన స్వంత cache ని నిర్మించుకుంటుంది (hits ఉండవు), మరియు subscription ఉన్నప్పటికీ 5-minute cache lifetime ని ఉపయోగిస్తుంది. Delegation పద్ధతి మీ main context ని నమ్మదగ్గ విధంగా రక్షిస్తుంది. ఇది ఎల్లప్పుడూ మొత్తం tokens సంఖ్యను తగ్గించకపోవచ్చు.

The cache clock: work in stints

Prompt caching వల్ల resend ఖర్చు తగ్గుతుంది: prefix చదవడానికి base input rate లో 0.1x మాత్రమే పడుతుంది, దానిని రాయడానికి 1.25x, లేదా ఒక గంట lifetime ఉన్నప్పుడు 2x పడుతుంది. ప్రతిసారి ఉపయోగించినప్పుడు ఎటువంటి అదనపు ఖర్చు లేకుండా entry refresh అవుతుంది, కాబట్టి clock చివరిసారి ఉపయోగించిన సమయం నుండి ప్రారంభమవుతుంది.

మీకు లభించే lifetime మీరు ఉపయోగించే authentication పద్ధతిపై ఆధారపడి ఉంటుంది. కాబట్టి "మీ cache ఐదు నిమిషాల్లో expire అవుతుంది" అని చెప్పడం తప్పు.

• Claude subscription ఉపయోగిస్తుంటే, Claude Code ఆటోమేటిక్‌గా one-hour lifetimeని కోరుకుంటుంది.
• మీ plan limit దాటి usage credits ఉపయోగిస్తున్నప్పుడు, ఆ usage కి బిల్లు పడుతుంది, కాబట్టి అది తిరిగి five minutes కి మారుతుంది.
• API key లేదా cloud provider ఉపయోగిస్తుంటే, అది five minutes వద్దే ఉంటుంది. ENABLE_PROMPT_CACHING_1H=1 one-hour lifetimeని ఎంచుకుంటుంది, మరియు FORCE_PROMPT_CACHING_5M=1 దానిని తిరిగి తగ్గించేస్తుంది.

రెండు సందర్భాల్లోనూ ఒకే రకమైన సలహా: నిరంతరంగా (continuous stints) పని చేయండి, ఎందుకంటే lifetime దాటి ఖాళీగా ఉంటే, తదుపరిసారి మొత్తం accumulated prefixని మళ్ళీ re-write చేయాల్సి వస్తుంది. tmux లో detached Claude Code session ఖాళీగా ఉన్నప్పుడు ఎటువంటి ఖర్చు ఉండదు, కానీ idle time వల్ల warm cache నష్టపోతుంది.

మీరు పని చేస్తున్నప్పుడే కొన్ని పనులు cacheని తొలగిస్తాయి: models మార్చడం, effort level మార్చడం, fast mode ఆన్ చేయడం, MCP server ని కనెక్ట్ చేయడం లేదా డిస్కనెక్ట్ చేయడం, plugin ని enable లేదా disable చేయడం, ఒక tool ని నిరాకరించడం, compacting, మరియు Claude Code ని upgrade చేయడం. /model సాధారణంగా ఎదురయ్యే సమస్య, ఎందుకంటే ప్రతి model కి దాని స్వంత cache ఉంటుంది, కాబట్టి కంటెంట్ ఒకేలా ఉన్నప్పటికీ, తదుపరి request లో cache hits లేకుండా మొత్తం historyని చదవాల్సి వస్తుంది.

Files edit చేయడం, CLAUDE.md edit చేయడం, skills మరియు commands ని పిలవడం, /recap రన్ చేయడం, rewinding, మరియు subagent ని spawn చేయడం వల్ల cache అలాగే ఉంటుంది. ఇది ఒక machine మరియు ఒక directory కి మాత్రమే పరిమితం, కాబట్టి వేర్వేరు directories లో ఉన్న రెండు sessions ఒకదాని cache ని మరొకటి ఉపయోగించుకోలేవు.

Caching సరిగ్గా పనిచేస్తుందో లేదో చూడటానికి 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 ను సపోర్ట్ చేస్తాయి, మరియు పెద్ద limit వద్ద కూడా compaction একইভাবে పనిచేస్తుంది. దీని వల్ల ఖర్చు (economics) మారదు, ఎందుకంటే ప్రతి turn లోనూ పూర్తి prompt మళ్ళీ పంపబడుతుంది మరియు దానికి బిల్లు పడుతుంది. పెద్ద window మీరు ఎప్పుడు స్పందించాలో నిర్ణయిస్తుంది; hygiene ఖర్చును నిర్ణయిస్తుంది. సమస్య పరిమితి (ceiling) కంటే బిల్లు అయితే, మీ పనితీరుకు ఏ 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) రూపొందిస్తుంది మరియు పూర్తి సంభాషణ చరిత్ర స్థానంలో దానిని ఉంచుతుంది. ఇది కూడా ఒక beta ఫీచర్: anthropic-beta: compact-2026-01-12 పంపండి మరియు compact_20260112 అనే edit typeని ఉపయోగించండి. దీని trigger డిఫాల్ట్‌గా {"type": "input_tokens", "value": 150000} గా ఉంటుంది, మరియు దాని విలువ కనీసం 50,000 ఉండాలి.

Compactionలో agents పనితీరును దెబ్బతీసే ఒక handoff నియమం ఉంది. ప్రతిస్పందన (response) సమ్మరీని కలిగి ఉన్న compaction content blockతో ప్రారంభమవుతుంది, ఆ తర్వాత సాధారణ text block వస్తుంది. మీరు ఆ blockను తదుపరి రిక్వెస్ట్‌లలో తిరిగి పంపాలి, అప్పుడు మాత్రమే API దాని ముందున్న ప్రతి content blockను తొలగిస్తుంది. ఆచరణలో: కేవలం textను మాత్రమే కాకుండా, response.content మొత్తాన్ని జత చేయండి.

Anthropic డాక్యుమెంటేషన్ ప్రకారం, సుదీర్ఘ సంభాషణలలో contextను నిర్వహించడానికి server-side compaction ప్రధాన వ్యూహం, మరియు దేనిని తొలగించాలో మరింత ఖచ్చితంగా నియంత్రించడానికి context editing ఒక ఆప్షన్. మొదట model supportను తనిఖీ చేయండి. ప్రస్తుత Opus, Sonnet మరియు Fable మోడల్స్ compactionను సపోర్ట్ చేస్తాయి; claude-haiku-4-5 సపోర్ట్ చేయదు, మరియు compaction పేజీలో తాజా జాబితా ఉంటుంది. ఏ beta ఫీచర్ కూడా Claude Code యొక్క /compactని నడపదు; దీని డాక్యుమెంటేషన్ ప్రకారం, ఇది క్లయింట్ పంపే ఒకేసారి చేసే summarization రిక్వెస్ట్.

FAQ

Claude Code session ఎంత సేపు నడుస్తుంటే అంత నెమ్మదిగా మరియు ఖరీదుగా ఎందుకు మారుతుంది?

ప్రతి turn లో మొత్తం సంభాషణ మళ్ళీ పంపబడుతుంది. కాబట్టి రోజంతా తెరిచి ఉన్న session లో మీరు అడిగే ఒకే ఒక్క లైన్ ప్రశ్న, రోజంతా జరిగిన సంభాషణ మొత్తాన్ని తనతో పాటు పంపుతుంది. Prompt caching ఉపయోగించి cache warm గా ఉన్నంత వరకు ఖర్చు తక్కువగా (read కోసం base input rate లో 0.1x) ఉంటుంది; ఒకవేళ turn లో cache miss అయితే, అదే prefix 1.25x రేటుతో మళ్ళీ పంపబడుతుంది. window ని ఏది నింపుతుందో చూడటానికి /context రన్ చేయండి, మరియు billing విధానం గురించి తెలుసుకోవడానికి what a Claude Code session bills you for చదవండి.

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 రన్ చేయండి, లేదా ప్రతి item యొక్క పూర్తి వివరాల కోసం /context all రన్ చేయండి. ఇది system prompt, tool definitions, MCP servers, memory files, మరియు history ని ఒక colored grid రూపంలో చూపిస్తుంది. అలాగే context ని ఎక్కువగా వాడే tools మరియు memory bloat గురించి సూచనలను కూడా ఇస్తుంది. Paid plan లో, /usage ఇటీవల జరిగిన usage ని individual skills, subagents మరియు MCP servers కి కూడా కేటాయిస్తుంది.

Compacting చేసే బదులు 1 million token context window వాడాలా?

పెద్ద window వాడటం వల్ల సమస్య పరిష్కారం కాదు, కేవలం ఆలస్యమవుతుంది. Opus 4.8 మరియు Sonnet 5 తో సహా ప్రస్తుతం ఉన్న కొన్ని models 1 million token context window ని సపోర్ట్ చేస్తున్నాయి, అక్కడ కూడా compaction একইভাবে పనిచేస్తుంది. ప్రతి turn లోనూ పూర్తి prompt మళ్ళీ పంపబడుతుంది మరియు దానికి బిల్లు పడుతుంది, కాబట్టి 400,000-token సంభాషణ ఎంత పెద్దదైనా ఖరీదుగా ఉంటుంది.

Claude API లో context editing మరియు compaction మధ్య తేడా ఏమిటి?

Context editing పాత కంటెంట్‌ను (ముఖ్యంగా tool results) ఎంపిక చేసిన முறையில் తొలగిస్తుంది, తొలగించిన చోట placeholder text ని ఉంచుతుంది, తద్వారా Claude ఆ సమాచారం తొలగించబడిందని తెలుస్తుంది. Compaction ఒక summary ని తయారు చేసి, పూర్తి history ని దానితో మారుస్తుంది. Anthropic డాక్యుమెంటేషన్ ప్రకారం, long-running conversations కి compaction ప్రధాన వ్యూహం, మరియు context editing అనేది fine-grained ఆప్షన్. ఇవి రెండూ beta వెర్షన్లు మరియు Claude Code యొక్క /compact కి భిన్నంగా ఉంటాయి.