Claude memoryకి అదనపు ఖర్చు ఉందా?

Claude memory ఫీచర్లకు అదనపు ఖర్చు ఉంటుందా?

Claude memory ఫీచర్లకు ప్రత్యేక ధర ఉండదు. Anthropic ప్రకటించిన ధరలు input యొక్క ప్రతి million tokens కు, output యొక్క ప్రతి million tokens కు వర్తిస్తాయి. Prompt caching కోసం అదనపు ధరలు ఉంటాయి. వీటిలో ఏదీ memory token గా పిలవబడదు. Claude API (application programming interface) లో memory ను నిల్వ చేయడానికి ఖర్చు ఉండదు, ఎందుకంటే memory tool client-side లో పనిచేస్తుంది, అలాగే ఆ file మీ సొంత storage లో ఉంటుంది.

అయితే memory మీ బిల్లుపై ప్రభావం చూపుతుంది. Claude చదివే request లో remembered fact ఉన్నప్పుడే అది సమాధానాన్ని మార్చగలదు. గుర్తుంచుకోవడం అంటే దాన్ని మళ్లీ పంపడం. ఆ text input tokens గా చేరుతుంది, కాబట్టి model యొక్క సాధారణ input rate ప్రకారం ఛార్జ్ అవుతుంది. ఖర్చును రెండు అంశాలు నిర్ణయిస్తాయి: ప్రతి turn లో మీరు మళ్లీ పంపే remembered text లో ఎన్ని tokens ఉన్నాయి, అలాగే ఆ text ను prompt cache నుంచి అందించగలమా లేదా అన్నది.

Pro లేదా Max subscription లో ఒక్కో token ఆధారంగా బిల్ చేయరు. అందువల్ల memory మీ డబ్బును కాకుండా usage allowance ను వినియోగిస్తుంది. విధానం మాత్రం ఇదే. మారేది యూనిట్ మాత్రమే. ఆ allowance పరిమితమైనది. కాబట్టి ప్రతి turn లో ఎంత memory ఉంచాలో నిర్ణయించే ముందు Claude Pro ఖర్చు ఎంత, దాని పరిమితులు మిమ్మల్ని ఎప్పుడు ఆపుతాయో తెలుసుకోవడం ఉపయోగకరం. Claude Enterprise విధానం మళ్లీ భిన్నంగా ఉంటుంది. seat ధరకు అదనంగా ప్రతి token ను API rates ప్రకారం లెక్కిస్తుంది. అందువల్ల memory block ఎక్కువగా ఉంటే allowance తగ్గడం కాకుండా నేరుగా ఖర్చు పెరుగుతుంది. Memory ను కుదించడం వల్ల చిన్న plan యొక్క పరిమితిలో మీ usage సౌకర్యంగా ఉంటే, Max నుంచి Pro కు మారడం తరువాత పరిశీలించాల్సిన చర్య. మీరు ఇప్పటికే చెల్లించిన period ముగిసినప్పుడు ఆ మార్పు అమలవుతుంది. మీరు పరిశీలిస్తున్న పోలిక Anthropic యొక్క tiers మధ్య కాకుండా providers మధ్య ఉంటే, ప్రస్తుత ధరల ప్రకారం Claude plans ను ChatGPT plans తో పోల్చడం ప్రారంభించడానికి సరైన స్థలం.

ప్రతి Claude ఉపరితలంలో “memory” అనే పదానికి అర్థం

మూడు వేర్వేరు ఉత్పత్తులు ఈ పదాన్ని ఉపయోగిస్తాయి. వాటిని కలిపి చూడటం వల్లే ఈ ప్రశ్న ఎక్కువగా గందరగోళంగా అనిపిస్తుంది.

Claude APIలోని memory tool. మీరు tools arrayకి ఒక entry జోడించి, file operations ను మీ స్వంత codeలో అమలు చేస్తారు.

{"type": "memory_20250818", "name": "memory"}

August 2026 నాటికి ఈ tool, beta header లేకుండా Messages APIలో మరియు Claude 4, తదుపరి modelsలో సాధారణంగా అందుబాటులో ఉంది. ఇది client-side విధానం. Claude view /memories వంటి operation కోసం అభ్యర్థిస్తుంది. మీ handler మీరు నియంత్రించే storageపై ఆ operationను అమలు చేసి, ఫలితాన్ని tool_result blockలో తిరిగి పంపుతుంది. Anthropic ఆ fileను ఎప్పుడూ నిల్వ చేయదు. అందువల్ల storage charge ను మీపైకి బదిలీ చేయదు. బదులుగా round trip కోసం మీరు చెల్లిస్తారు. Tool definition ప్రతి requestలో పంపబడుతుంది. తిరిగి వచ్చే file content ఆ దశ నుంచి conversationలోనే ఉంటుంది.

ఈ overheadలో స్థిరమైన భాగాన్ని Anthropic ప్రచురిస్తుంది. August 2026లో document చేసిన ప్రకారం, auto tool choiceతో Claude Opus 5లో tool-use system prompt 286 tokens ఉంటుంది. Memory అయినా మరే tool అయినా, ఏదైనా tool ఉన్నప్పుడు ప్రతి requestకు ఇది ఒకసారి చెల్లించాలి.

Claude Code. ప్రతి session ప్రారంభంలో రెండు mechanisms load అవుతాయి. మీరు రాసే instructions ను CLAUDE.md files కలిగి ఉంటాయి. Claude తన కోసం రాసే notesను ~/.claude/projects/<project>/memory/ కింద Auto memoryలో ఉంచుతుంది. MEMORY.md లోని మొదటి 200 lines లేదా 25KB మాత్రమే load అవుతుంది. ఏ పరిమితి ముందుగా చేరితే అదే వర్తిస్తుంది. దాని పక్కన ఉన్న topic files startup సమయంలో కాకుండా అవసరమైనప్పుడు చదవబడతాయి. Startup సమయంలో load అయిన ప్రతిదీ, ఆ sessionలోని ప్రతి తదుపరి requestతో పంపబడే prefixలో భాగమవుతుంది. Claude Code sessions మధ్య memoryని ఎలా తిరిగి పొందుతుంది అనే విభాగంలో file-by-file loading order వివరించబడింది.

వెబ్‌లోని Claude. claude.aiలో, మీరు chat చేస్తున్నప్పుడు Claude రాసి update చేసే entries సమూహమే memory. ప్రతి projectకు ప్రత్యేక memory space ఉంటుంది. Settings > Memoryలో నిల్వ చేసిన అంశాల జాబితా కనిపిస్తుంది. అక్కడి toggle ద్వారా Pause memory లేదా Reset memory ఎంచుకోవచ్చు. ఈ ఉపరితలానికి subscription ఆధారంగా billing జరుగుతుంది. అందువల్ల ఇక్కడ memory usage limitsను ఉపయోగిస్తుంది.

గుర్తుంచుకున్న టెక్స్ట్‌ను input tokens‌గా ఎందుకు బిల్ చేస్తారు

Messages API stateless‌గా ఉంటుంది. Calls మధ్య ఇది ఏ సమాచారాన్నీ నిల్వ చేయదు. అందువల్ల ప్రతి turn‌లో client మొత్తం conversation‌ను పంపుతుంది, model దానిని మళ్లీ పూర్తిగా చదువుతుంది. ఈ నియమానికి memory మినహాయింపు కాదు. అదే request‌లోని మరో text block మాత్రమే.

ఏ response‌లోనైనా usage object‌లో ఈ విభజన కనిపిస్తుంది.

"usage": {
  "input_tokens": 412,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 18240,
  "output_tokens": 236
}

input_tokens అనేది cache నుంచి చదవని లేదా cache సృష్టించడానికి ఉపయోగించని tokens‌ను మాత్రమే లెక్కిస్తుంది. ఆచరణలో, ఇవి చివరి cache breakpoint తర్వాతి tokens. Request‌కు సంబంధించిన మొత్తం input cache_read_input_tokens, cache_creation_input_tokens మరియు input_tokens మొత్తంగా ఉంటుంది. Claude మూడు turns క్రితం తెరిచిన memory file, ఆ తర్వాత ప్రతి turn‌లోనూ ఈ మొత్తం input‌లోనే ఉంటుంది. Cached prefix కొనసాగుతున్నప్పుడు అది cache_read_input_tokens కింద లెక్కించబడుతుంది. Cached prefix లేకపోతే అది input_tokens కింద లెక్కించబడుతుంది. Text ఒకటే అయినా, ధరలో మాత్రం చాలా తేడా ఉంటుంది. Input మరియు output tokens‌కు వేర్వేరు ధరలు ఉంటాయి, మరియు memory ఎల్లప్పుడూ input వైపే లెక్కించబడుతుంది.

మీ స్వంత వినియోగంలో ఈ సంఖ్యలను ఎక్కడ చూడాలి

ఈ వ్యాసంతో సహా ఏదైనా blog post లోని సంఖ్యను నేరుగా ఉపయోగించవద్దు. మీ స్వంత memory block ను కొలవండి. Token counting ఉచితం మరియు దీనికి ప్రత్యేక rate limit ఉంటుంది, కాబట్టి ఈ కొలతకు ఎలాంటి ఖర్చు ఉండదు.

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }'

ప్రతిస్పందన { "input_tokens": 14 } వంటి ఒక సంఖ్యగా ఉంటుంది. మీ memory text ను system field లో paste చేసి ఒకసారి అమలు చేయండి. తరువాత దాన్ని memory text లేకుండా మరోసారి అమలు చేయండి. ఈ రెండు ఫలితాల మధ్య తేడానే ప్రతి turn లో ఆ memory వల్ల మీకు అయ్యే ఖర్చు. ఇక్కడ రెండు విషయాలను గుర్తుంచుకోండి. ఈ count ఒక అంచనా మాత్రమే. Anthropic తన system optimizations కోసం అదనంగా జోడించే tokens కు మీపై billing ఉండదు. అలాగే మీరు వాస్తవంగా అమలు చేయబోయే model ఆధారంగా కూడా count చేయండి. ఎందుకంటే Claude 4.7 మరియు తరువాతి versions కొత్త tokenizer ను ఉపయోగిస్తాయి. అదే text కు అవి సుమారు 30 శాతం ఎక్కువ tokens ఉత్పత్తి చేస్తాయి.

Claude Code లో ఇదే ప్రశ్నకు curl అవసరం లేకుండానే సమాధానం పొందవచ్చు.

• /context ప్రస్తుతం load అయిన విషయాలను చూపుతుంది. ఇందులో memory files కూడా ఉంటాయి. మీరు ఏదైనా type చేయకముందే window లో వాటి వాటాను చూడవచ్చు.
• /memory మీ CLAUDE.md files ను జాబితా చేసి, auto memory folder ను తెరుస్తుంది.
• /usage session totals ను print చేస్తుంది. ఇందులో cache reads మరియు cache writes కూడా ఉంటాయి.
• status line context window వినియోగాన్ని నిరంతరం చూపగలదు. అందువల్ల అది పెరుగుతున్న విధానం వెంటనే కనిపిస్తుంది.

/usage session block ఇలా కనిపిస్తుంది:

Total cost:            $0.55
Total duration (API):  6m 20s
Total duration (wall): 6h 33m 10s
Total code changes:    0 lines added, 0 lines removed
Usage by model:
   claude-sonnet-4-6:  1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)

చివరి line ను జాగ్రత్తగా చదవండి. 940.0k cache read సంఖ్యలో ప్రతి turn లో cache rate వద్ద మళ్లీ పంపబడే conversation, memory మరియు మిగతా మొత్తం ఉంటుంది. 1.2k input సంఖ్యలో కొత్తగా జోడించబడిన భాగం మాత్రమే ఉంటుంది. Claude Code list prices ఆధారంగా ఆ dollar amount ను locally లెక్కిస్తుంది. అందువల్ల మీరు పొందిన ఏ discount ను అది పరిగణించదు. ఇది మీ invoice లోని మొత్తానికి భిన్నంగా ఉండవచ్చు. అధికారిక సంఖ్య కోసం Claude Console లోని Usage page ను చూడాలి.

ఇప్పుడు comparison ను నేరుగా అమలు చేయండి. రెండు fresh sessions లో ఒకే opening question అడగండి. ఒక session ను సాధారణంగా, మరొకదాన్ని auto memory ఆపి అమలు చేయండి.

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

ప్రతి session లో /context అమలు చేసి, memory files entry ను compare చేయండి. పని ప్రారంభమయ్యే ముందే ప్రతి session ప్రారంభంలో మీ accumulated memory వల్ల అయ్యే ఖర్చు ఎంత అనేది ఆ తేడా చూపుతుంది. ఆ రెండు సంఖ్యలతో పాటు Claude Code token వినియోగం ఎక్కడికి వెళ్తుందో పూర్తి వివరణ చదవడం ఉపయోగకరం.

ప్రతి మిలియన్ tokens కు memory ను మళ్లీ చదవడానికి ఎంత ఖర్చవుతుంది?

Prompt caching వల్ల ఒకే memory block ను ఒక turn లో మరో turn కంటే పది రెట్లు ఎక్కువ ఖర్చుతో చదవాల్సి రావచ్చు. Anthropic cache rates ను ప్రతి model యొక్క base input price కు గుణకాలుగా ప్రచురిస్తుంది. అందువల్ల dollar prices మారినా ఈ సంబంధం అలాగే ఉంటుంది.

[
  {
    "label": "Base input",
    "price_multiple": 1
  },
  {
    "label": "5 minute cache write",
    "price_multiple": 1.25
  },
  {
    "label": "1 hour cache write",
    "price_multiple": 2
  },
  {
    "label": "Cache read",
    "price_multiple": 0.1
  }
]

Cache read ఖర్చు 0.1 రెట్లు base input price అవుతుంది. 5 నిమిషాల lifetime ఉన్న entry ను రాయడానికి base price కు 1.25 రెట్లు, 1 గంట lifetime ఉన్న entry కు base price కు 2 రెట్లు ఖర్చవుతుంది. Anthropic break-even ను స్పష్టంగా పేర్కొంటుంది: 5 నిమిషాల duration లో ఒక cache read తర్వాత, లేదా 1 గంట duration లో రెండు cache reads తర్వాత caching ప్రయోజనకరంగా మారుతుంది. Prompt caching లో break-even point అనేది memory ను ఎక్కడ ఉంచాలో నిర్ణయించే ముందు చేయాల్సిన లెక్క.

ఈ గుణకాలు replay count ను అంకగణితంగా మార్చుతాయి. తదుపరి block పై ప్రచురించిన గుణకాల ఆధారంగా చేసిన లెక్క మాత్రమే. ఇది ప్రస్తుతం నడుస్తున్న workload యొక్క కొలత కాదు. 100 turn session లో ఒక memory block కు మూడు విధాలుగా ఖర్చును లెక్కిస్తుంది. ఫలితాన్ని సాధారణ base input rate వద్ద వసూలయ్యే సమాన token count గా చూపిస్తుంది.

[
  {
    "label": "4,000 tokens, never cached",
    "base_rate_equivalent_tokens": "400,000"
  },
  {
    "label": "4,000 tokens, 1 write and 99 reads",
    "base_rate_equivalent_tokens": "44,600"
  },
  {
    "label": "1,000 tokens, 1 write and 99 reads",
    "base_rate_equivalent_tokens": "11,150"
  }
]

4,000 tokens ఉన్న memory block 100 turns లోనూ cache miss అయితే, దానికి 400,000 base-rate tokens కు సమానమైన billing వస్తుంది. అదే block పై ఒక 5 నిమిషాల cache write మరియు 99 cache reads ఉంటే, దానికి 44,600 tokens కు సమానమైన billing వస్తుంది. దాని పరిమాణాన్ని నాలుగో వంతుకు తగ్గించి caching కొనసాగిస్తే, దానికి 11,150 tokens కు సమానమైన billing వస్తుంది. ఈ 3 rows లో feature మారలేదు. మారింది replay behaviour మాత్రమే. ఇవి ఇప్పటికీ money కాదు, token counts మాత్రమే. token count ను మీ నెలవారీ bill లోని మొత్తంగా మార్చడం కోసం model యొక్క per-million rate తో ఒకసారి గుణించాలి. ఆ rate మీరు నడిపే model పై ఆధారపడి ఉంటుంది. కాబట్టి agent Claude Fable 5 పై నడవాల్సి ఉంటే, ముందుగా దాని ప్రచురిత per-million rates మరియు దానికి సరిపోయే పనులు ను పరిశీలించండి.

రెండవ row లోని లెక్క, తరువాత వచ్చే 99 requests లో ప్రతి request cache entry ఇంకా చెల్లుబాటులో ఉన్న సమయంలోనే వస్తుందని భావిస్తుంది. వాస్తవ bills లో ఎక్కువ పొరపాట్లు జరిగేది ఈ assumption వల్లే.

విరామం తర్వాత అదే ప్రశ్నకు ఎక్కువ ఖర్చు ఎందుకు అవుతుంది?

ఒక cache entry కి lifetime ఉంటుంది. దాన్ని వ్రాసే లేదా చదివే request వచ్చినప్పుడు clock ప్రారంభమవుతుంది. Default 5 minutes. 1 hour option కు పైన చూపిన 2x write ఖర్చు అవుతుంది. Claude Code లో subscription ఉన్నప్పుడు lifetime one hour ఉంటుంది. Usage credits వినియోగిస్తున్నప్పుడు అది five minutes కు తగ్గుతుంది. API key లేదా cloud provider ఉపయోగిస్తున్నప్పుడు default గా five minutes ఉంటుంది. Usage credits వినియోగిస్తున్నప్పటికీ one hour lifetime కొనసాగించడానికి ENABLE_PROMPT_CACHING_1H=1 సెట్ చేయండి.

కాబట్టి lunch సమయంలో open గా వదిలిన session లో ఒక line question టైప్ చేసినా అది ఖరీదైనదిగా మారుతుంది. మీరు దూరంగా ఉన్న సమయంలో cache entry expire అవుతుంది. Memory తో సహా మొత్తం prefix ను base input rate వద్ద మళ్లీ process చేసి, cache లోకి మళ్లీ వ్రాస్తుంది. ఆ pause ఎంతసేపు ఉందో అదే ధరను నిర్ణయించింది.

దీన్ని నమ్మడమే కాకుండా మీరు నిర్ధారించవచ్చు. Pro, Max, Team లేదా Enterprise plan లో /usage breakdown, ఇటీవలి usage లో 10 percent లేదా అంతకంటే ఎక్కువకు కారణమైన ప్రతి behaviour ను గుర్తిస్తుంది. Long context మరియు cache misses రెండూ అక్కడ పేరుతో కనిపిస్తాయి. API లో quiet period తర్వాత వచ్చే మొదటి request సమయంలో cache_creation_input_tokens మీ prefix యొక్క పూర్తి పరిమాణానికి మళ్లీ పెరగడాన్ని గమనించండి.

క్యాష్‌ను నిశ్శబ్దంగా చెల్లనిదిగా చేసేది

క్యాష్ చేసిన prefix క్రమబద్ధంగా ఉంటుంది: ముందుగా tools, తరువాత system, ఆపై messages. ఒక స్థాయిలో మార్పు చేస్తే ఆ స్థాయి మరియు దాని తరువాతి మొత్తం భాగం చెల్లదు. tool definition ను సవరించడం వల్ల మొత్తం క్యాష్ తొలగిపోతుంది. system prompt ను సవరించడం వల్ల system మరియు message క్యాష్ తొలగిపోతాయి.

system prompt లో memory ఉంచి, agent నేర్చుకున్నకొద్దీ దాన్ని తిరిగి రాసే వారికి ఇదే ప్రధాన సమస్య. ప్రతి సవరణ దాని తరువాత ఉన్న మొత్తం భాగం యొక్క cached copy ని తొలగిస్తుంది. అందువల్ల తదుపరి request లో మొత్తం భాగాన్ని మళ్లీ రాయడానికి పూర్తి ఖర్చు అవుతుంది. స్థిరమైన విషయాలను ప్రారంభంలో ఉంచి, వాటిని స్థిరంగానే ఉంచండి. మారే విషయాలను message list చివరలో ఉంచండి. అప్పుడు వాటిని invalidating చేయడం తక్కువ ఖర్చుతో జరుగుతుంది.

ఇంకో నిశ్శబ్ద వైఫల్యం కూడా ఉంది. ప్రతి model కు cache చేయదగిన prefix కోసం కనిష్ఠ పరిమాణం ఉంటుంది: Claude Opus 5 లో 512 tokens, Claude Sonnet 5 లో 1,024, Claude Haiku 4.5 లో 4,096. ఈ వివరాలు August 2026 లో ప్రచురించబడ్డాయి. దాని కంటే తక్కువ పరిమాణం ఉన్నప్పుడు ఏమి జరుగుతుందో Anthropic documentation స్పష్టంగా చెబుతుంది: "ఈ సంఖ్య కంటే తక్కువ tokens ను cache చేయడానికి చేసే ఏ request అయినా caching లేకుండా process చేయబడుతుంది; ఎలాంటి error కూడా తిరిగి ఇవ్వబడదు." కాబట్టి cache_control తో గుర్తించిన చిన్న memory file అసలు ఎలాంటి ప్రభావం చూపదు. ఇది నిశ్శబ్దంగా జరుగుతుంది. మీరు చూడగల లక్షణం ఏమిటంటే, మీ prompt లో breakpoint స్పష్టంగా ఉన్నప్పటికీ cache_creation_input_tokens విలువ 0 గానే ఉంటుంది.

తదుపరి ఉపయోగం లేని మెమరీని తొలగించండి

ప్రతి turnలో మెమరీలోని ప్రతి లైన్ tokens ను వినియోగిస్తుంది. అందువల్ల ప్రతి లైన్ గురించి, అది ఇటీవల ఏదైనా సమాధానాన్ని మార్చిందా అని పరిశీలించాలి. Claude Code ఈ పరిమితులను స్పష్టంగా చూపిస్తుంది. CLAUDE.md ని 200 lines కంటే తక్కువగా ఉంచాలని లక్ష్యంగా పెట్టుకోండి. పొడవైన files ఎక్కువ context ను వినియోగిస్తాయి. దాంతో Claude వాటిని విశ్వసనీయంగా అనుసరించే సామర్థ్యం తగ్గుతుంది. MEMORY.md ను load సమయంలో మొదటి 200 lines లేదా 25KB వరకు మాత్రమే పరిమితం చేస్తుంది. ఆ పరిమితిని మించిన కంటెంట్ తదుపరి session ప్రారంభంలో తొలగించబడుతుంది. అందువల్ల అధిక పరిమాణం ఉన్న index tokens ను వినియోగించినా, ఉపయోగకరమైన సమాచారాన్ని అందించదు.

దీన్ని చిన్నగా ఉంచడానికి రెండు అలవాట్లు సహాయపడతాయి. index లోని వివరాలను topic files కు తరలించండి. Claude వాటిని startup సమయంలో కాకుండా అవసరమైనప్పుడు చదువుతుంది. workflow instructions ను CLAUDE.md నుండి skills కు తరలించండి. అవి invoke చేసినప్పుడు మాత్రమే load అవుతాయి. ఇప్పటికే frontmatter తో ప్రారంభమయ్యే memory files కోసం, version 2.1.214 లేదా ఆ తర్వాతి version లో Claude Code write time ను modified field లో ISO 8601 timestamp గా నమోదు చేస్తుంది. పాతబడిన fact ను గుర్తించడానికి ఆ timestamp అత్యంత వేగవంతమైన మార్గం. పాతబడిన agent memory ను తొలగించడం review ప్రక్రియను మరింత వివరంగా వివరిస్తుంది.

ప్రతిసారి మొత్తం సమాచారాన్ని context లోకి లోడ్ చేయడం కంటే అవసరమైనప్పుడు తిరిగి పొందడం

Memory tool ను just-in-time retrieval కు ఉపయోగిస్తారు. మొదట్లో మొత్తం సమాచారాన్ని లోడ్ చేయడానికి బదులుగా, agent తాను తెలుసుకున్న విషయాలను నమోదు చేసి, task కు అవసరమైనప్పుడు మాత్రమే file ను తిరిగి చదువుతుంది. దీనివల్ల లెక్కింపు మారుతుంది. File ను చదవడానికి అయ్యే tokens ఖర్చు ఒక్కసారి మాత్రమే జరుగుతుంది. ఆ తర్వాత అది cached prefix లోనే ఉంటుంది. కానీ ఎల్లప్పుడూ లోడ్ చేసి ఉంచిన block ప్రతి turn లోనూ ఖర్చవుతుంది.

పై రెండు charts ఆధారంగా ఒక సరళమైన నియమం వర్తిస్తుంది. దాదాపు ప్రతి turn ఉపయోగించే text ను స్థిరమైన cached prefix లో ఉంచండి. ఇరవై turns లో ఒక turn మాత్రమే ఉపయోగించే text ను view call వెనుక ఉంచండి. Break-even మీ replay count తో మారుతుంది; Anthropic వసూలు చేసే రుసుముతో కాదు.

API లో conversation ను platform స్వయంగా కుదించే విధానాన్ని కూడా ఉపయోగించవచ్చు. మీరు నిర్ణయించిన threshold ను conversation దాటినప్పుడు, Context editing పాత tool results ను తొలగిస్తుంది.

{
  "edits": [
    {
      "type": "clear_tool_uses_20250919",
      "trigger": {"type": "input_tokens", "value": 30000},
      "keep": {"type": "tool_uses", "value": 3},
      "clear_at_least": {"type": "input_tokens", "value": 5000}
    }
  ]
}

Default గా trigger 100,000 input tokens వద్ద ఉంటుంది, అలాగే 3 tool uses ఉంచబడతాయి. దీన్ని enable చేయడానికి ముందు caching తో interaction ను చదవండి. Content ను clear చేసిన సమయంలో cached prefix చెల్లదు. అందువల్ల తదుపరి request లో cache write కోసం చెల్లించాలి. దీని కోసం clear_at_least ఉపయోగిస్తారు. Write ఖర్చును సమర్థించేంత saving వచ్చే వరకు ఇది clearing ను నిలిపివేస్తుంది. context_management కింద response లో నిజంగా ఏమి జరిగిందో ఖచ్చితంగా చూపిస్తుంది. ఇందులో cleared_tool_uses మరియు cleared_input_tokens కూడా ఉంటాయి. అందువల్ల ఈ trade సైద్ధాంతికంగా కాకుండా కొలవగలిగేదిగా ఉంటుంది. Claude Code లో context window నిర్వహణ coding session కు ఇదే ఆలోచనను వర్తింపజేస్తుంది.

దేనికి ప్రత్యేక ఛార్జీ ఉంటుంది

Memoryకు ప్రత్యేకంగా ఎలాంటి ఛార్జీ ఉండదు. అయితే కొన్ని ఫీచర్‌లకు నిజంగానే ప్రత్యేక ఛార్జీలు ఉంటాయి. ఏ ఫీచర్‌కు ఎంత ఛార్జీ ఉంటుందో తెలుసుకోవడం అవసరం. ఇవి August 2026 నాటికి ప్రచురించబడిన Claude API రేట్లు. కొన్ని ఆపరేషన్‌లకు అసలు ఎలాంటి ఛార్జీ ఉండదు. అయితే Claude APIలో ఉచిత tier లేదు. Signup సమయంలో లభించే చిన్న credit మాత్రమే ఉంటుంది. కాబట్టి క్రింద పేర్కొన్నవి మీ మొదటి request నుంచే వాస్తవ ఖర్చులుగా పరిగణించాలి.

• Web search: ప్రతి 1,000 searchesకు $10. Search contextలోకి చేర్చే మొత్తం కంటెంట్‌కు సాధారణ token ఛార్జీ అదనంగా ఉంటుంది.
• Code execution: ప్రతి organizationకు నెలకు 1,550 ఉచిత గంటలు. ఆ తర్వాత ప్రతి containerకు గంటకు $0.05. Web search లేదా web fetchతో కలిపి ఉపయోగించినప్పుడు దీనికి ఛార్జీ ఉండదు.
• Claude Managed Agents: సాధారణ token ఛార్జీలకు అదనంగా, session runtimeకు session-hourకు $0.08.
• Web fetch: అదనపు ఛార్జీ లేదు. Fetch చేసిన contentకు సంబంధించిన token ఖర్చు మాత్రమే ఉంటుంది.

ఈ జాబితాలో Memory ఎక్కడా ప్రత్యేక itemగా కనిపించదు. అది మీ input token countలో భాగంగా లెక్కించబడుతుంది. అందువల్ల దాని పరిమాణాన్ని ఖచ్చితంగా కొలవవచ్చు. Pruning మరియు caching ద్వారా ఆ ఖర్చును తగ్గించవచ్చు. Virtual private server (VPS)పై unattendedగా నడిచే agent కోసం బడ్జెట్ రూపొందిస్తున్నట్లయితే, VPSపై AI agentకు ఖర్చు నియంత్రణలు తదుపరి అమలు చేయాల్సినవి. ఎందుకంటే పెరుగుతున్న memory fileకు pruning లేకపోతే, దాన్ని ఎవరూ report చేయకుండానే agent ఖర్చు ప్రతి వారం పెరుగుతుంది.

FAQ

Claude యొక్క memory features కోసం ప్రత్యేక ఛార్జీ ఉందా?

లేదు. Anthropic ధరల జాబితాలో ప్రతి million input tokens, ప్రతి million output tokens మరియు prompt caching multiples కోసం రేట్లు ఉన్నాయి; memory కోసం ప్రత్యేక పంక్తి లేదు. Claude APIలో memory tool client-sideగా పనిచేస్తుంది, కాబట్టి files మీరు ఇప్పటికే చెల్లిస్తున్న storageపైనే ఉంటాయి. Memory జోడించేది input tokens మాత్రమే. అవి memoryని కలిగి ఉన్న ప్రతి turnలో model యొక్క సాధారణ input rate ప్రకారం బిల్ అవుతాయి.

Memoryని ఆపితే Claude చౌకగా మారుతుందా?

ప్రతి requestలోని token count తగ్గుతుంది. దాంతో ప్రతి request ఖర్చు కూడా తగ్గుతుంది. మొత్తం మీద ఎంత ఆదా అవుతుందో తరువాత ఏమి జరుగుతుందనే దానిపై ఆధారపడి ఉంటుంది. Memoryలో ఇప్పటికే ఉన్న విషయాలను Claude మళ్లీ నిర్మించడానికి మూడు files చదివి, మీకు రెండు ప్రశ్నలు అడగాల్సి వస్తే, ఆ tokens memory కంటే ఎక్కువ ఖర్చవుతాయి. ఊహించకుండా కొలవండి: auto memory ఆన్ ఉన్న sessionలో, అలాగే CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 తో ప్రారంభించిన sessionలో /context అమలు చేసి, అదే task కోసం ఖర్చైన మొత్తం tokensను పోల్చండి.

నేను ఏదీ మార్చకపోయినా నా usage ఎందుకు పెరిగింది?

విరామం తర్వాత cache miss కావడం అత్యంత సాధారణ కారణం. Cache entries డిఫాల్ట్‌గా 5 minutes, లేదా extended settingలో one hour పాటు ఉంటాయి. అందువల్ల విరామం తర్వాతి మొదటి request మొత్తం prefixను base input rate వద్ద మళ్లీ process చేసి, దాన్ని మళ్లీ cacheలో రాస్తుంది. రెండవ సాధారణ కారణం prefix edit. Tool definitionను మార్చితే మొత్తం cache చెల్లదు. System promptను మార్చితే system cache మరియు message cache చెల్లవు. Subscription planలో, ఇటీవలి usageలో 10 percent లేదా అంతకంటే ఎక్కువగా ఉన్నప్పుడు /usage breakdown ఈ ప్రవర్తనకు పేరు చూపిస్తుంది.

Memory system promptలో ఉండాలా, లేదా tool call వెనుక ఉండాలా?

దాదాపు ప్రతి turnలో memory ఉపయోగిస్తే దాన్ని system promptలో ఉంచండి. అప్పుడు అది cached prefixలో ఉంటుంది, కాబట్టి cache read rate ప్రకారం ఖర్చవుతుంది. కొన్ని tasksకు మాత్రమే అవసరమైతే దాన్ని view call వెనుక ఉంచండి. ఒక్కసారి చదివిన fileలోని tokens ప్రతి turnలో కాకుండా ఒక్కసారే ఖర్చవుతాయి. నిర్ణయాత్మక సంఖ్య replay count. usage object ఆ సంఖ్యను నేరుగా ఇస్తుంది.

Memory features subscription usage limitsలో లెక్కించబడతాయా?

అవును, పరోక్షంగా. ప్రతి requestలో ఉండే tokens ఆధారంగా subscription limits వినియోగించబడతాయి. Automatic context managementను ప్రారంభించే longer conversations మీ usage limitలో ఎక్కువ భాగాన్ని వినియోగిస్తాయని Anthropic సహాయ documentation పేర్కొంటుంది. Memory ప్రతి requestను కొద్దిగా పొడవుగా చేస్తుంది. Long sessionలో ఆ పొడవు ప్రతి turnలో మళ్లీ పంపబడుతుంది. Claude usage limits వాస్తవంగా ఎలా పనిచేస్తాయో reset అయ్యే విషయాలను వివరిస్తుంది.