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

Claude memory features కోసం అదనపు ఖర్చు ఉంటుందా?

Claude memory features కు ప్రత్యేకంగా ఎలాంటి ధర ఉండదు. 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 లో ఉంటేనే అది సమాధానాన్ని మార్చగలదు. అంటే ఆ సమాచారాన్ని మళ్లీ పంపాలి. ఆ text input tokens గా లెక్కించబడుతుంది. Model యొక్క సాధారణ input rate ప్రకారం దానికి ఛార్జీ పడుతుంది. ఖర్చును రెండు అంశాలు నిర్ణయిస్తాయి: ప్రతి turn లో మళ్లీ పంపే remembered text లోని tokens సంఖ్య, అలాగే ఆ text prompt cache నుంచి అందించగలమా లేదా అన్నది.

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

ప్రతి Claude surface‌లో “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 tool. Claude view /memories వంటి operationను అడుగుతుంది. మీ handler, మీరు నియంత్రించే storageపై దాన్ని అమలు చేసి, ఫలితాన్ని tool_result blockలో తిరిగి పంపుతుంది. Anthropic fileను ఎప్పుడూ నిల్వ చేయదు. అందువల్ల storage chargeను మీకు బదిలీ చేయదు. బదులుగా round trip కోసం మీరు చెల్లిస్తారు. ప్రతి requestలో tool definition పంపబడుతుంది. తిరిగి వచ్చే file content ఆ దశ నుంచి conversationలోనే ఉంటుంది.

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

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

వెబ్‌లో Claude. claude.aiలో, మీరు chat చేస్తుండగా Claude రాసి update చేసే entries సమూహమే memory. ప్రతి projectకు ప్రత్యేక memory space ఉంటుంది. Settings > Memoryలో నిల్వ చేసిన విషయాలను చూడవచ్చు. అక్కడి toggle ద్వారా Pause memory లేదా Reset memory ఎంచుకోవచ్చు. ఈ surfaceకు 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 లో ఈ మొత్తంలోనే ఉంటుంది. Cached prefix అమల్లో ఉన్నప్పుడు అది cache_read_input_tokens కింద లెక్కించబడుతుంది. Cached prefix అమల్లో లేకపోతే అది input_tokens కింద లెక్కించబడుతుంది. Text ఒకటే అయినా ధరలో పెద్ద తేడా ఉంటుంది. Input మరియు output tokens కు వేర్వేరు ధరలు ఉంటాయి, మరియు memory ఎల్లప్పుడూ input వైపే లెక్కించబడుతుంది.

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

బ్లాగ్ పోస్ట్‌లో ఉన్న సంఖ్యను, ఇందులో ఉన్నదాన్ని కూడా, ఆధారంగా తీసుకోకండి. మీ స్వంత memory block ను కొలవండి. Token లెక్కింపు ఉచితం మరియు దానికి ప్రత్యేక 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 లో ఉంచి ఒకసారి run చేయండి. తరువాత memory text లేకుండా మరోసారి run చేయండి. ఈ రెండు ఫలితాల మధ్య తేడానే ప్రతి turn లో ఆ memory కోసం అయ్యే ఖర్చు. రెండు విషయాలు గుర్తుంచుకోండి. ఈ count ఒక estimate మాత్రమే. Anthropic తన system optimizations కోసం జోడించే అదనపు tokens మీకు bill చేయబడవు. మీరు వాస్తవంగా run చేయబోయే model ఆధారంగా కూడా count చేయండి. ఎందుకంటే Claude 4.7 మరియు తరువాతి versions కొత్త tokenizer ను ఉపయోగిస్తాయి. అదే text కు అవి సుమారు 30 percent ఎక్కువ 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 ను నిరంతరం చూపించగలదు. అందువల్ల అది పెరుగుతున్న తీరు వెంటనే కనిపిస్తుంది.

/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 figure అంటే conversation, memory మరియు మిగతా మొత్తం ప్రతి turn లో cache rate కు మళ్లీ పంపబడుతున్నదని అర్థం. 1.2k input figure లో కొత్తగా వచ్చిన భాగం మాత్రమే ఉంటుంది. Claude Code list prices ఆధారంగా ఆ dollar amount ను local గా లెక్కిస్తుంది. అందువల్ల మీరు పొందే ఏ discount ను అది పరిగణనలోకి తీసుకోదు. మీ invoice తో ఈ మొత్తం భిన్నంగా ఉండవచ్చు. Claude Console లోని Usage page అధికారిక సంఖ్యను చూపిస్తుంది.

తరువాత comparison ను నేరుగా run చేయండి. రెండు fresh sessions లో ఒకే opening question అడగండి. ఒక session ను సాధారణంగా run చేయండి. మరొక session లో auto memory ను off చేయండి.

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

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

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

అదే memory block ఒక turn లో మరొక turn కంటే పది రెట్లు ఎక్కువ ఖర్చవడానికి prompt caching కారణం. Anthropic, ప్రతి model యొక్క base input price కు గుణితాలుగా cache rates ను ప్రచురిస్తుంది. అందువల్ల 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 ఖర్చు base input price కంటే 0.1 రెట్లు ఉంటుంది. 5 minute lifetime తో entry రాయడానికి base ధర కంటే 1.25 రెట్లు ఖర్చవుతుంది. 1 hour lifetime కు 2 రెట్లు ఖర్చవుతుంది. Anthropic break-even ను స్పష్టంగా చెబుతుంది: 5 minute వ్యవధిలో ఒక cache read తర్వాత, లేదా 1 hour వ్యవధిలో రెండు cache reads తర్వాత caching ప్రయోజనకరంగా మారుతుంది. prompt caching కు break-even point అనేది memory ను ఎక్కడ ఉంచాలో నిర్ణయించే ముందు చేయాల్సిన లెక్క.

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

[
  {
    "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 token memory block అన్ని 100 turns లో cache miss అయితే, దానికి 400,000 base-rate tokens కు సమానంగా bill అవుతుంది. అదే block కు ఒక 5 minute cache write మరియు 99 cache reads ఉంటే, అది 44,600 tokens కు సమానంగా bill అవుతుంది. దాని పరిమాణాన్ని నాలుగో వంతుకు తగ్గించి caching కొనసాగిస్తే, అది 11,150 tokens కు సమానంగా bill అవుతుంది. ఈ 3 rows లో feature మారలేదు. Replay behaviour మాత్రమే మారింది. ఇవి ఇంకా money కాకుండా token counts మాత్రమే. token count ను మీ నెలవారీ bill లోని మొత్తంగా మార్చడం అంటే మీ model యొక్క per-million rate తో ఒకసారి గుణించడం. మీరు నడిపే model ఆ rate ను నిర్ణయిస్తుంది. కాబట్టి agent Claude Fable 5 పై నడవబోతే, దాని ప్రచురించిన per-million rates మరియు దానికి సరిపోయే పనులు నుంచి ప్రారంభించండి. Provider ఇంకా ఖరారు కాలేదా, లేక model ఒక్కటే ప్రశ్న కాదా? అప్పుడు Claude API మరియు ChatGPT పై అదే పనుల ఖర్చు ఆ గుణకం ఎక్కడ ఎలా మారుతుందో చూపిస్తుంది. Memory ఎక్కువగా ఉపయోగించే agent input భాగంపై గణనీయంగా ఆధారపడుతుంది.

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

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

Cache entryకి ఒక lifetime ఉంటుంది. దాన్ని రాసే లేదా చదివే request వద్ద ఈ సమయం లెక్కించడం ప్రారంభమవుతుంది. Default lifetime 5 minutes. 1 hour option కోసం పైన చూపిన write కంటే 2x ఖర్చు అవుతుంది. 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 ప్రశ్నను టైప్ చేసినా ఖర్చు ఎక్కువగా ఉంటుంది. మీరు దూరంగా ఉన్న సమయంలో cache entry expired అయింది. Memoryతో సహా మొత్తం prefixను base input rate వద్ద మళ్లీ process చేసి, cacheలో మళ్లీ రాస్తుంది. ఆ విరామం ఎంతసేపు ఉందో ఖర్చును నిర్ణయించింది.

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

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

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

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

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

స్థానం నిలబెట్టుకోలేని memory ని తొలగించండి

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

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

అన్నింటినీ context లోకి లోడ్ చేయడం కంటే అవసరమైనప్పుడు retrieve చేయడం మెరుగైనప్పుడు

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

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

APIలో platform conversation ను స్వయంగా trim చేయడానికి కూడా అనుమతిస్తుంది. మీరు నిర్ణయించిన threshold దాటిన తర్వాత 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 settings లో trigger 100,000 input tokens గా, ఉంచే tool uses సంఖ్య 3 గా ఉంటాయి. దీన్ని enable చేయడానికి ముందు caching తో interaction ను చదవండి. Content ను clear చేస్తే, 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 కు స్వంతంగా ఎటువంటి అదనపు ఛార్జీ ఉండదు. అయితే కొన్ని features కు నిజంగా ప్రత్యేక ఛార్జీలు ఉంటాయి. ఏవికి ఉంటాయో తెలుసుకోవడం ఉపయోగకరం. ఇవి August 2026 నాటికి ప్రచురించబడిన Claude API rates. కొన్ని operations పూర్తిగా ఉచితం. అయితే Claude APIలో free tier లేదు. Signup సమయంలో లభించే చిన్న credit మాత్రమే ఉంటుంది. కాబట్టి కింది ఖర్చులన్నీ మీ మొదటి request నుంచే నిజమైన ఖర్చులుగా నమోదవుతాయి.

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

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

FAQ

Claude యొక్క memory features కు ప్రత్యేక రుసుము ఉందా?

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

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

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

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

విరామం తర్వాత cache miss కావడం అత్యంత సాధారణ కారణం. Cache entries డిఫాల్ట్‌గా 5 minutes పాటు ఉంటాయి. Extended setting లో అవి one hour పాటు ఉంటాయి. అందువల్ల విరామం తర్వాత వచ్చే మొదటి request మీ మొత్తం prefix ను base input rate వద్ద మళ్లీ process చేసి, దాన్ని తిరిగి రాస్తుంది. రెండవ సాధారణ కారణం prefix edit. Tool definition మార్చితే మొత్తం cache invalid అవుతుంది. System prompt మార్చితే system cache మరియు message cache invalid అవుతాయి. 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 ను ప్రారంభించే పొడవైన conversations మీ usage limit లో ఎక్కువ భాగాన్ని వినియోగిస్తాయని Anthropic సహాయ documentation పేర్కొంటుంది. Memory ప్రతి request ను కొద్దిగా పొడవుగా చేస్తుంది. Long session లో ఆ పొడవు ప్రతి turn లో మళ్లీ పంపబడుతుంది. Claude usage limits వాస్తవంగా ఎలా పనిచేస్తాయో ఏది ఎప్పుడు reset అవుతుందో వివరిస్తుంది.