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

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

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

meter ఎందుకు పనిచేస్తుందో agent session వెనుక ఉన్న token meter వివరిస్తుంది.

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

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

/context [all] ప్రస్తుత context వినియోగాన్ని రంగుల gridగా చూపిస్తుంది. Context ఎక్కువగా ఉపయోగించే tools మరియు memory bloat కోసం optimization సూచనలను కూడా చూపిస్తుంది. all fullscreen modeలో ప్రతి అంశం యొక్క breakdownను విస్తరిస్తుంది. ఫలితాన్ని ఐదు bucketsగా చదవండి.

• సిస్టమ్ prompt. Claude Code యొక్క స్వంత harness సూచనలు. ఇవి session అంతటా స్థిరంగా ఉంటాయి.
• Tool definitions. Agent call చేయగల ప్రతి tool యొక్క schema. అనుసంధానమైన ప్రతి MCP (Model Context Protocol) server schema కూడా ఇందులో ఉంటుంది.
• Memory files. Session ప్రారంభంలో లోడ్ అయ్యే CLAUDE.md మరియు auto memory.
• Files and tool results. చదివిన ప్రతి file, అలాగే మీ commands తిరిగి ముద్రించిన ప్రతిదీ.
• Message history. మీ turns మరియు వాటికి వచ్చిన replies.

మొదటి మూడు ప్రతి requestపై session మొత్తం వర్తించే స్థిరమైన భారం. చివరి రెండు నిరంతరం పెరుగుతాయి. ప్రారంభంలోనే స్థిరమైన భారాన్ని ఒకసారి తగ్గించండి. పెరుగుతున్న భాగాన్ని నిరంతరం నిర్వహించండి.

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లో model యొక్క నిజమైన context window కంటే తక్కువగా ఉండవచ్చు. దీన్ని దాటినా requests విజయవంతమవుతాయి. అందువల్ల అది refusal కాదు, warning మాత్రమే.

Paid planలో /usage మిగతా సగం సమాచారాన్ని కూడా జోడిస్తుంది. ఇది long context లేదా cache misses వంటి ప్రవర్తనలను గుర్తించి, ఇటీవలి వినియోగాన్ని individual skills, subagents మరియు MCP serversకు కేటాయిస్తుంది. Allowance ఇప్పటికే ఖర్చయిందని అది చెబితే, మీరు ఏ limit window కోసం వేచి ఉన్నారో నిర్ధారిస్తుంది: contextను trim చేయడం ఇప్పుడు సహాయపడుతుందా, లేక పని కొనసాగించడానికి వేరే మార్గం అవసరమా.

CLAUDE.md శాశ్వత భారం, కాబట్టి దాన్ని సంక్షిప్తంగా ఉంచండి

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

Procedures ను skills లోకి తరలించండి. Skill invoke చేసినప్పుడు మాత్రమే load అవుతుంది. కాబట్టి వారానికి రెండుసార్లు నడిపే workflow ఇతర రోజుల్లో ఎటువంటి ఖర్చును కలిగించదు. 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 నుంచి మళ్లీ 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 చేసి, తరువాత 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

ఈ రెండు ఆదేశాలు ఒకే విధంగా కనిపిస్తాయి. కానీ వాటి ఖర్చు చాలా భిన్నంగా ఉంటుంది.

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

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

/compact కు ఎల్లప్పుడూ instruction ఇవ్వండి. Instruction లేని /compact, మీకు పనిలో ఏ భాగం ఇంకా అవసరమో తెలియని default prompt ఆధారంగా summary తయారు చేస్తుంది. Instruction ఉన్నది ఈ విషయాన్ని కొనసాగిస్తుంది:

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

ప్రతిసారీ ఒకే కారణంతో compact చేస్తే, మీ project's CLAUDE.md లోని # Compact instructions heading కింద ఒక standing 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 చేయడం కంటే మెరుగైనది, ఎందుకంటే ఇది ఇప్పటికే cache అయిన prefix వరకు truncate చేస్తుంది. /recap history ను మార్చకుండా, summary ను command output గా append చేస్తుంది. అందువల్ల 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 స్థిరమైన అదనపు భారం

మీరు కనెక్ట్ చేసే ప్రతి MCP server మొత్తం sessionలోని ప్రతి requestకు అదనపు భారాన్ని చేర్చుతుంది. దాన్ని ఉపయోగించకపోయినా దాని కోసం ఖర్చు చెల్లించాలి.

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

Session ప్రారంభంలోనే దీన్ని చేయండి. Definitions deferredగా ఉన్నప్పుడు serverను connect చేయడం లేదా disconnect చేయడం conversationకు కొత్త సమాచారాన్ని మాత్రమే జోడిస్తుంది. Cache అలాగే ఉంటుంది. Tool search ఆఫ్‌లో ఉండటం లేదా ఏదైనా server deferral నుంచి మినహాయించబడటం వల్ల definitions prefixలోకి load అయితే, అదే మార్పు తరువాతి requestలో మొత్తం సమాచారాన్ని మళ్లీ చదివేలా చేస్తుంది.

Claude కు చేరకముందే verbose tool output ను filter చేయండి

Tool result ఒక input. తరువాతి ప్రతి turn లో ఆ input మళ్లీ పంపబడుతుంది. 20,000 tokens output ను dump చేసే test run ఒక్కసారి అయ్యే ఖర్చు కాదు. అది context window నుంచి తొలగిపోయే వరకు ప్రతి turn లో మళ్లీ ఖర్చవుతుంది.

Source వద్దే filter చేయండి. Claude చూడకముందే test run ను failures కు మాత్రమే పరిమితం చేసే hook, పెద్ద output ను కొన్ని వందల tokens గా మారుస్తుంది. ఇది ప్రస్తుత turn లోనూ, ఆ output మళ్లీ పంపబడే ప్రతి turn లోనూ వర్తిస్తుంది:

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

Hooks code గా నడుస్తాయి కాబట్టి అవి స్వయంగా context లోకి చేరవు. Output ఒక screen పరిమాణాన్ని మించిన ఏ tool కైనా ఇదే విధానాన్ని ఉపయోగించండి. 3,000-line file కు కూడా ఇదే వర్తిస్తుంది. అవసరమైన line range మాత్రమే అడగండి, ఎందుకంటే మొత్తం file వచ్చిన తర్వాత అది context window లోనే ఉంటుంది.

ఏ ఫైళ్లను agent చదవాలో పరిమితం చేసి, ఎక్కువ output వచ్చే పనిని delegate చేయండి

ఫైల్ పేరు మరియు సమస్య లక్షణాన్ని పేర్కొన్న prompt ఆ ఫైల్‌ను చదువుతుంది. ప్రాజెక్ట్‌ను శుభ్రం చేయమని స్పష్టమైన పరిమితులు లేని అభ్యర్థన ఇస్తే, agent సంబంధితమని నిర్ణయించిన ప్రతిదాన్ని చదువుతుంది. ఆ చదువులన్నీ context window లోనే ఉంటాయి.

ఎక్కువ output వచ్చే పనిని subagent కు delegate చేయండి. Test runs మరియు log processing రెండూ నిజమైన context ను వినియోగిస్తాయి. Subagent ఆ output ను తన స్వంత window లో ఉంచి, కేవలం సారాంశాన్ని మాత్రమే తిరిగి ఇస్తుంది. అయితే దీనికి ఒక ప్రతికూలత ఉంది: subagent తన స్వంత cache ను నిర్మిస్తుంది, మొదటి call లో cache hits ఉండవు. Subscription ఉన్నప్పటికీ ఐదు నిమిషాల cache lifetime వర్తిస్తుంది. Delegation మీ ప్రధాన context ను విశ్వసనీయంగా రక్షిస్తుంది. కానీ మొత్తం tokens వినియోగాన్ని ఇది ఎల్లప్పుడూ తగ్గించదు.

క్యాష్ గడియారం: నిరంతర పని విరామాల్లో పనిచేయండి

Prompt caching వల్ల మళ్లీ పంపడం తక్కువ ఖర్చుతో సాధ్యమవుతుంది: prefix ను చదవడానికి ప్రాథమిక input rate లో 0.1x మాత్రమే చెల్లించాలి. దాన్ని రాయడానికి 1.25x, ఒక గంట lifetime కోసం రాయడానికి 2x చెల్లించాలి. ప్రతి వినియోగం అదనపు ఖర్చు లేకుండా entry lifetime ను మళ్లీ ప్రారంభిస్తుంది. అందువల్ల గడియారం చివరి వినియోగం నుంచి ప్రారంభమవుతుంది. ఈ multipliers బిల్లు ఎలా లెక్కించబడుతుందో చూపిస్తాయి, కానీ మొత్తం పరిమాణాన్ని చూపించవు. అందుకే ఒక మిలియన్ tokens కు వాస్తవంగా ఎంత ఖర్చవుతుందో కూడా చూడండి. అప్పుడు పూర్తి context window ఖర్చును డాలర్లలో లెక్కించవచ్చు.

మీ authentication విధానాన్ని బట్టి మీకు లభించే lifetime మారుతుంది. అందువల్ల “మీ cache ఐదు నిమిషాల తర్వాత expire అవుతుంది” అనే సాధారణ నియమం సరైనది కాదు.

• Claude subscription ఉపయోగిస్తే, Claude Code ఒక గంట lifetime ను స్వయంచాలకంగా అభ్యర్థిస్తుంది.
• మీ plan limit దాటి usage credits వినియోగిస్తే, ఆ usage కు billing జరుగుతుంది. అప్పుడు lifetime ఐదు నిమిషాలకు తిరిగి మారుతుంది.
• API key లేదా cloud provider ఉపయోగిస్తే, lifetime ఐదు నిమిషాలుగానే ఉంటుంది. ENABLE_PROMPT_CACHING_1H=1 ఒక గంట lifetime ను ఎంచుకుంటుంది. FORCE_PROMPT_CACHING_5M=1 దాన్ని మళ్లీ ఐదు నిమిషాలకు పరిమితం చేస్తుంది.

ఏ విధానమైనా పని విధానం ఒకటే: నిరంతర విరామాల్లో పని చేయండి. Lifetime కంటే ఎక్కువ idle gap ఏర్పడితే, తదుపరి turn మొత్తం కూడబెట్టిన prefix ను మళ్లీ రాయాలి. tmux లో detached Claude Code session idle గా ఉన్నప్పుడు ఎటువంటి ఖర్చు ఉండదు. అయితే idle సమయం warm cache ను అందుబాటులో లేకుండా చేస్తుంది.

మీరు ఇంకా పని చేస్తుండగానే కొన్ని చర్యలు cache ను తొలగిస్తాయి: models మార్చడం, effort level మార్చడం, fast mode ప్రారంభించడం, MCP server ను connect లేదా disconnect చేయడం, plugin ను enable లేదా disable చేయడం, మొత్తం tool ను deny చేయడం, compacting చేయడం, మరియు Claude Code ను upgrade చేయడం. /model సాధారణంగా ఆశ్చర్యానికి కారణమవుతుంది. ప్రతి model కు ప్రత్యేక cache ఉంటుంది. అందువల్ల content ఒకటే అయినా, తదుపరి request cache hits లేకుండా మొత్తం history ను చదువుతుంది. ఆ మళ్లీ చదివిన content కు destination model rates వర్తిస్తాయి. కాబట్టి session మధ్యలో Fable కు మారితే, కూడబెట్టిన మొత్తం history కు Fable 5 యొక్క ప్రచురిత input rate ప్రకారం billing జరుగుతుంది.

Files ను edit చేయడం, CLAUDE.md ను edit చేయడం, skills మరియు commands ను invoke చేయడం, /recap ను run చేయడం, rewind చేయడం, మరియు subagent ను ప్రారంభించడం cache ను నిలుపుతాయి. Cache ఒక machine మరియు ఒక directory కు మాత్రమే పరిమితం అవుతుంది. అందువల్ల వేర్వేరు directories లోని రెండు sessions ఒకదానికొకటి cache ను ఉపయోగించలేవు. ఈ పరిమితి మీ account ను కాకుండా CLI ను అనుసరిస్తుంది. అందువల్ల cache లోని ఏదీ Claude desktop app కు బదిలీ కాదు. Linux లో అది CLI తో పాటు వేరుగా install చేసే beta.

Caching పనిచేస్తుందో లేదో తెలుసుకోవడానికి current_usage ను చదవండి. cache_creation_input_tokens cache write rate వద్ద రాయబడింది. cache_read_input_tokens సాధారణ input rate లో సుమారు పదో వంతు rate వద్ద అందించబడింది. Read-to-creation ratio ఎక్కువగా ఉండటం ఆరోగ్యకరమైన స్థితి. ప్రతి turn లో creation ఎక్కువగానే ఉంటే, మీ prefix లో ఏదో నిరంతరం మారుతోంది.

పెద్ద context window ఈ సమస్యను పరిష్కరిస్తుందా?

పాక్షికంగా. ప్రస్తుతం ఉన్న కొన్ని models 1 million token context window కు support ఇస్తాయి. పెద్ద పరిమితిలోనూ compaction అదే విధంగా పనిచేస్తుంది. Economics మారదు, ఎందుకంటే ప్రతి turn లో పూర్తి prompt మళ్లీ పంపబడుతుంది మరియు దానికి మళ్లీ billing జరుగుతుంది. మీరు ఎప్పుడు చర్య తీసుకోవాల్సి వస్తుందో పెద్ద window నిర్ణయిస్తుంది; hygiene ఖర్చును నిర్ణయిస్తుంది. సమస్య ceiling కాకుండా bill అయితే, మీ పని విధానానికి సరిపోయే Claude plan ఏది అనే విషయం మీరు dollars ఖర్చు చేస్తున్నారా లేదా plan allowance ఉపయోగిస్తున్నారా అనేది నిర్ణయిస్తుంది.

APIలో context editing మరియు compaction వేర్వేరు అంశాలు

మీరు Messages APIపై మీ స్వంత agentను రూపొందిస్తుంటే, slash commands ఉండవు. వీటిని మీరే అమలు చేయాలి. ఈ పనికి మొదటి నుంచే బడ్జెట్ కేటాయించండి. ఎందుకంటే చిన్న signup credit మినహా APIలో ఉచిత tier లేదు. అందువల్ల కుదించని historyలోని ప్రతి turnకు పూర్తి చార్జీ విధించబడుతుంది. Trimming జరగకముందే మీరు ఎంచుకునే provider ఈ లెక్కను నిర్ణయిస్తుంది. ఎంపిక ఇంకా ఖరారు కాకపోతే, ప్రతి tokenకు ప్రకటించిన ధరలను మాత్రమే పోల్చకుండా రెండు APIలలోనూ అదే workload ఖర్చును లెక్కించండి. ఈ పనికి server-sideలో రెండు features ఉన్నాయి. అవి ఒకే feature కావు.

Context editing సంభాషణ 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 చివరి 3 tool usesకు, clear_tool_inputs 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 blockను తొలగిస్తుంది. ఆచరణలో, textను మాత్రమే కాకుండా మొత్తం response.contentను append చేయాలి.

దీర్ఘకాలిక conversationsలో contextను నిర్వహించడానికి server-side compactionను ప్రధాన strategyగా Anthropic documentation పేర్కొంటుంది. తొలగించాల్సిన contentపై మరింత నియంత్రణ అవసరమైనప్పుడు context editingను ఉపయోగించాలి. ముందుగా model supportను తనిఖీ చేయండి. ప్రస్తుత Opus, Sonnet, Fable models compactionకు support ఇస్తాయి. claude-haiku-4-5 support ఇవ్వదు. Compaction pageలో ప్రస్తుత live list ఉంటుంది. ఈ రెండు beta featuresలో ఏదీ Claude Code యొక్క స్వంత /compactను నడపదు. Documentation ప్రకారం అది client పంపే ఒక్కసారి జరిగే summarization request.

FAQ

నా Claude Code session ఎక్కువసేపు కొనసాగిన కొద్దీ ఎందుకు నెమ్మదిగా మారి, ఖర్చు పెరుగుతుంది?

ప్రతి turn సమయంలో మొత్తం conversation ను మళ్లీ పంపడం వల్ల ఇది జరుగుతుంది. అందువల్ల రోజంతా open గా ఉన్న session లోని ఒక వరుస ప్రశ్నతో పాటు ఆ రోజు మొత్తం conversation కూడా వెళ్తుంది. Prompt caching cache warm గా ఉన్నప్పుడు ఈ ఖర్చును తగ్గిస్తుంది. Read కోసం base input rate లో 0.1x మాత్రమే వసూలు అవుతుంది. ఒక turn cache ను miss చేసినప్పుడు అదే prefix 1.25x రేటుతో మళ్లీ రాయబడుతుంది. Window ను ఏది నింపుతోందో చూడటానికి /context నడపండి. ఈ విధానం గురించి Claude Code session కు బిల్లింగ్ ఎలా జరుగుతుంది చదవండి.

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 కోసం సూచనలు కూడా ఇస్తుంది. 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 మళ్లీ పంపబడుతుంది, దానికి మళ్లీ బిల్లింగ్ కూడా జరుగుతుంది. కాబట్టి 400,000-token conversation window లో సరిపోయినా, సరిపోకపోయినా ఖరీదైనదే.

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

Context editing పాత content ను, ముఖ్యంగా tool results ను, ఎంపిక చేసి clear చేస్తుంది. ప్రతి తొలగించిన item స్థానంలో placeholder text ఉంచుతుంది. దాంతో అది తొలగించబడిందని Claude కు తెలుస్తుంది. Compaction ఒక summary ను రూపొందించి, పూర్తి history స్థానంలో దాన్ని ఉంచుతుంది. దీర్ఘకాలం కొనసాగే conversations కోసం compaction ను primary strategy గా Anthropic documentation పేర్కొంటుంది. Context editing ను fine-grained option గా సూచిస్తుంది. రెండూ తమకంటూ ప్రత్యేక headers కలిగిన beta features. రెండూ Claude Code లోని /compact కు వేర్వేరు.