Claude memory साठी अतिरिक्त शुल्क आकारले जाते का?

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 असते आणि फाइल तुमच्या मालकीच्या storage वर असते.

तरीही memory मुळे तुमच्या बिलावर परिणाम होतो. Claude ने वाचलेल्या request मध्ये एखादी आठवलेली माहिती समाविष्ट असेल, तेव्हाच ती उत्तर बदलते. आठवण वापरणे म्हणजे ती माहिती पुन्हा पाठवणे. हा मजकूर input tokens म्हणून येतो आणि मॉडेलच्या नेहमीच्या input दराने आकारला जातो. यासाठी दोन गोष्टी महत्त्वाच्या आहेत: प्रत्येक turn वर तुम्ही आठवलेल्या मजकुरातील किती tokens पुन्हा पाठवता आणि तो पुन्हा पाठवलेला मजकूर prompt cache मधून दिला जाऊ शकतो का.

Pro किंवा Max subscription वर प्रत्येक token साठी स्वतंत्र शुल्क आकारले जात नाही. त्यामुळे memory तुमचे पैसे खर्च न करता तुमचा usage allowance वापरते. खालील यंत्रणा तशीच राहते. फक्त मोजमापाचे एकक बदलते. हा allowance मर्यादित असतो. त्यामुळे प्रत्येक turn मध्ये किती memory ठेवायची हे ठरवण्यापूर्वी Claude Pro ची किंमत किती आहे आणि त्याच्या मर्यादा तुम्हाला कधी थांबवतात हे जाणून घेणे उपयुक्त ठरते. Claude Enterprise ची रचना वेगळी आहे. ते seat price व्यतिरिक्त API दरांनुसार प्रत्येक token चे मोजमाप करते, त्यामुळे memory block अतिशय मोठा असल्यास allowance ऐवजी प्रत्यक्ष खर्च वाढतो. Memory कमी केल्याने तुमचा वापर लहान plan च्या मर्यादेखाली सहज येत असेल, तर Max वरून Pro वर जाणे हा पुढील योग्य पर्याय ठरू शकतो. तुम्ही आधीच भरलेल्या कालावधीच्या शेवटी हा बदल लागू होतो. तुम्ही Anthropic च्या tiers मधील नव्हे, तर वेगवेगळ्या providers मधील तुलना करत असाल, तर सध्याच्या किमतींनुसार Claude चे plans ChatGPT च्या plans सोबत पाहणे हा सुरुवातीचा योग्य संदर्भ आहे.

प्रत्येक Claude पृष्ठभागावर “memory” म्हणजे काय

तीन स्वतंत्र उत्पादने हा शब्द वापरतात. ही उत्पादने एकमेकांत गल्लत होणे हेच हा प्रश्न गोंधळात टाकण्याचे मुख्य कारण आहे.

Claude API वरील memory tool. तुम्ही tools array मध्ये एक entry जोडता आणि file operations तुमच्या स्वतःच्या code मध्ये implement करता.

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

August 2026 पर्यंत हा tool Messages API वर beta header शिवाय, Claude 4 आणि त्यानंतरच्या models मध्ये सर्वसाधारणपणे उपलब्ध आहे. हा client-side आहे: Claude view /memories सारख्या operation ची विनंती करते, तुमचा handler ती तुमच्या नियंत्रणातील storage वर चालवतो आणि तुम्ही परिणाम tool_result block मध्ये परत करता. Anthropic कडे file कधीही साठवली जात नाही. त्यामुळे पुढे आकारला जाणारा storage charge नसतो. त्याऐवजी तुम्ही round trip साठी पैसे देता. Tool definition प्रत्येक request मध्ये पाठवली जाते. परत आलेली file content त्या क्षणापासून conversation मध्येच राहते.

Anthropic या overhead चा निश्चित भाग प्रकाशित करते. August 2026 मध्ये दस्तऐवजीकरण केल्याप्रमाणे, Claude Opus 5 वर auto tool choice वापरल्यास tool-use system prompt 286 tokens चा असतो. कोणतेही tool उपस्थित असेल, memory किंवा अन्य कोणतेही, तर प्रत्येक request साठी हा खर्च एकदाच आकारला जातो.

Claude Code. प्रत्येक session च्या सुरुवातीला दोन mechanisms content load करतात. तुम्ही लिहिलेल्या instructions CLAUDE.md files मध्ये असतात. Auto memory मध्ये Claude स्वतःसाठी notes लिहिते; ती ~/.claude/projects/<project>/memory/ अंतर्गत ठेवली जातात. MEMORY.md मधील पहिल्या 200 lines किंवा 25KB पर्यंतचे content यापैकी जे limit आधी येईल तेवढेच load केले जाते. त्याच्या बाजूच्या topic files startup वेळी न वाचता गरजेनुसार read केल्या जातात. Startup वेळी load झालेले सर्व content त्या session मधील प्रत्येक पुढील request मध्ये पाठवल्या जाणाऱ्या prefix चा भाग बनते. Claude Code sessions मधील memory कशी पुन्हा आठवते या विषयात file-by-file loading order स्पष्ट केला आहे.

वेबवरील Claude. claude.ai वर memory म्हणजे chat करताना Claude लिहिते आणि update करते अशा entries चा संच. प्रत्येक 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 मधील मजकुराचा आणखी एक 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 अंतर्गत मोजली जाते. मजकूर तोच असतो, पण किंमत दोन प्रकारे लक्षणीयरीत्या वेगळी असते. 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 शिवाय पुन्हा चालवा. या दोन्ही परिणामांमधील फरक म्हणजे प्रत्येक turn मध्ये त्या memory साठी लागणारा खर्च. दोन गोष्टी लक्षात ठेवा. हा count अंदाजे असतो. Anthropic स्वतःच्या system optimizations साठी जोडणारे अतिरिक्त tokens तुमच्याकडून bill केले जात नाहीत. तसेच तुम्ही प्रत्यक्षात चालवणार असलेल्या model विरुद्ध मोजमाप करा, कारण Claude 4.7 आणि त्यानंतरच्या आवृत्त्या नवीन tokenizer वापरतात. त्यामुळे त्याच text साठी साधारण 30 percent अधिक tokens तयार होतात.

Claude Code मध्ये हेच मोजमाप कोणत्याही curl शिवाय करता येते.

• /context सध्या load असलेली सामग्री दाखवते. यात memory files समाविष्ट असतात. त्यामुळे काहीही type करण्यापूर्वी window मधील त्यांचा वाटा पाहता येतो.
• /memory तुमच्या CLAUDE.md files ची यादी दाखवते आणि auto memory folder उघडते.
• /usage session totals दाखवते. यात cache reads आणि cache writes यांचा समावेश असतो.
• status line context window usage सतत दाखवू शकते. त्यामुळे 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 हा आकडा म्हणजे conversation आणि memory यांसह संपूर्ण सामग्री cache rate वर प्रत्येक turn मध्ये पुन्हा पाठवली जात आहे. 1.2k input हा आकडा फक्त नव्याने जोडलेल्या भागाचा आहे. Claude Code list prices वरून ही dollar amount स्थानिक पातळीवर मोजते. त्यामुळे तुमच्यावर लागू असलेली कोणतीही discount ती विचारात घेत नाही आणि हा आकडा तुमच्या invoice पेक्षा वेगळा असू शकतो. Claude Console मधील Usage page हा अधिकृत आकडा मानावा.

आता तुलना थेट करा. दोन fresh sessions मध्ये समान opening question विचारा. एका session मध्ये नेहमीची configuration वापरा आणि दुसऱ्यामध्ये auto memory बंद करा.

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

प्रत्येक session मध्ये /context चालवा आणि memory files entry ची तुलना करा. कोणतेही काम सुरू होण्यापूर्वी प्रत्येक session च्या सुरुवातीला तुमच्या साठलेल्या memory साठी लागणारा खर्च या दोन्हीमधील फरकातून कळतो. Claude Code चा token usage कुठे खर्च होतो याचे संपूर्ण विश्लेषण या दोन आकड्यांसोबत वाचणे उपयुक्त ठरेल.

प्रति दशलक्ष tokens memory पुन्हा वाचण्याचा खर्च किती आहे?

Prompt caching मुळे एकाच memory block ची किंमत एका turn मध्ये दुसऱ्या turn पेक्षा दहापट जास्त असू शकते. 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 price च्या 1.25 पट शुल्क आकारले जाते. 1 hour lifetime साठी हे शुल्क base price च्या 2 पट असते. Anthropic break-even स्पष्टपणे सांगते: 5 minute duration मध्ये एक cache read झाल्यानंतर caching फायदेशीर ठरते. 1 hour duration मध्ये दोन cache reads झाल्यानंतर ती फायदेशीर ठरते. Prompt caching साठी break-even point म्हणजे memory कुठे ठेवायची हे ठरवण्यापूर्वी करायची गणना.

हे गुणक replay count चे arithmetic मध्ये रूपांतर करतात. पुढील block ही वरील प्रकाशित गुणकांवर आधारित गणना आहे. ती कोणत्याही live workload चे measurement नाही. 100 turn च्या session मध्ये memory block ची तीन प्रकारे किंमत मोजली आहे. ही किंमत plain base input rate वर आकारल्या जाणाऱ्या equivalent 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 झाल्यास, त्याचे billing 400,000 base-rate tokens इतके होईल. त्याच block साठी एक 5 minute cache write आणि 99 cache reads वापरल्यास billing 44,600 tokens इतके होईल. त्याचा आकार एक चतुर्थांश करून caching कायम ठेवल्यास billing 11,150 tokens इतके होईल. या 3 rows मध्ये feature बदललेले नाही. फक्त replay behaviour बदलले आहे. हे अजूनही token counts आहेत, पैसे नाहीत. token count चे तुमच्या monthly bill मधील रकमेतील रूपांतर करण्यासाठी model च्या per-million rate ने एकदा गुणाकार करावा लागतो. हा rate तुम्ही चालवत असलेल्या model ने ठरतो. त्यामुळे agent Claude Fable 5 वर चालणार असल्यास, त्याचे प्रकाशित per-million rates आणि त्याला योग्य असलेले काम यापासून सुरुवात करा.

दुसऱ्या row मध्ये असे गृहीत धरले आहे की नंतरच्या 99 requests पैकी प्रत्येक request cache entry अजून उपलब्ध असताना येतो. बहुतेक real bills मध्ये चूक याच गृहीतकामुळे होते.

ब्रेकनंतर तोच प्रश्न अधिक महाग का पडतो?

Cache entry ला एक lifetime असते. ती मोजणी entry लिहिणाऱ्या किंवा वाचणाऱ्या request पासून सुरू होते. Default lifetime 5 minutes आहे. 1 hour पर्यायासाठी वर दाखवलेल्या write च्या 2x इतका खर्च होतो. Claude Code मध्ये subscription वापरताना lifetime one hour असते. Usage credits वापरायला सुरुवात केल्यावर ती five minutes वर येते. API key किंवा cloud provider वापरताना default lifetime five minutes असते. Usage credits वापरत असताना one hour lifetime ठेवण्यासाठी ENABLE_PROMPT_CACHING_1H=1 सेट करा.

म्हणून lunch break दरम्यान उघडे ठेवलेल्या session मध्ये टाइप केलेला एक ओळीचा प्रश्न महाग पडतो. तुम्ही दूर असताना cache entry ची मुदत संपलेली असते. Prefix मधील संपूर्ण मजकूर, memory सहित, पुन्हा base input rate वर process केला जातो आणि cache मध्ये पुन्हा लिहिला जातो. या खर्चाची किंमत pause च्या कालावधीने ठरवली.

यावर विश्वास ठेवण्याऐवजी तुम्ही ते पडताळू शकता. Pro, Max, Team किंवा Enterprise plan वर /usage breakdown अलीकडील usage पैकी 10 percent किंवा त्याहून अधिक वापरासाठी जबाबदार असलेले behaviour दाखवते. Long context आणि cache misses दोन्ही तेथे नावाने दिसतात. API वर, शांत कालावधीनंतरच्या पहिल्या request मध्ये cache_creation_input_tokens तुमच्या prefix च्या पूर्ण आकारापर्यंत पुन्हा वाढते का ते तपासा.

कॅशे शांतपणे कशामुळे अमान्य होते

कॅश केलेला prefix क्रमबद्ध असतो: आधी tools, त्यानंतर system, आणि शेवटी messages. एखाद्या स्तरात बदल केल्यास तो स्तर आणि त्यानंतरचे सर्व स्तर अमान्य होतात. एखादी tool definition संपादित केल्यास संपूर्ण कॅशे टाकून दिला जातो. system prompt संपादित केल्यास system आणि message cache टाकून दिले जातात.

ज्यांनी system prompt मध्ये memory ठेवली आहे आणि agent शिकत असताना ती पुन्हा लिहिली आहे, त्यांच्यासाठी ही महत्त्वाची अडचण आहे. प्रत्येक पुनर्लेखनामुळे त्यानंतरच्या सर्व सामग्रीची cached copy नष्ट होते. त्यामुळे पुढील request वेळी पुन्हा पूर्ण write करावा लागतो. स्थिर सामग्री सुरुवातीला ठेवा आणि ती स्थिरच ठेवा. बदलणारी सामग्री message list मध्ये शेवटच्या बाजूला ठेवा, जेणेकरून ती अमान्य झाल्यास खर्च कमी राहील.

याशिवाय आणखी एक शांतपणे घडणारे अपयश आहे. प्रत्येक model साठी cache करता येणाऱ्या prefix ची किमान मर्यादा असते: Claude Opus 5 साठी 512 tokens, Claude Sonnet 5 साठी 1,024, आणि Claude Haiku 4.5 साठी 4,096; ही माहिती August 2026 मध्ये प्रकाशित झाली. या मर्यादेपेक्षा कमी token असताना काय होते, हे Anthropic च्या documentation मध्ये स्पष्टपणे नमूद आहे: "या संख्येपेक्षा कमी tokens cache करण्याच्या सर्व requests caching शिवाय process केल्या जातात आणि कोणताही error परत केला जात नाही." त्यामुळे cache_control ने चिन्हांकित केलेली लहान memory file काहीही करत नाही; हे शांतपणे घडते. तुम्हाला दिसणारे लक्षण म्हणजे prompt मध्ये breakpoint स्पष्टपणे असतानाही cache_creation_input_tokens चे मूल्य 0 राहते.

ज्या स्मृतीचा उपयोग उरलेला नाही ती काढून टाका

स्मृतीतील प्रत्येक ओळ ती स्मृती असलेल्या प्रत्येक turn मध्ये tokens खर्च करते. त्यामुळे प्रत्येक ओळीबाबतचा प्रश्न असा असावा की तिने अलीकडे एखादे उत्तर बदलले आहे का. Claude Code या मर्यादा स्पष्टपणे दाखवते. CLAUDE.md ही 200 ओळींपेक्षा कमी ठेवण्याचे लक्ष्य ठेवा, कारण मोठ्या फाइल्स अधिक context वापरतात आणि Claude त्यांचे पालन कमी विश्वासार्हपणे करते. लोड करताना MEMORY.md वरच्या 200 ओळी किंवा 25KB इतकेच घेतले जाते. या मर्यादेपुढील मजकूर पुढील session सुरू झाल्यावर वगळला जातो. त्यामुळे अतिमोठ्या index साठी tokens खर्च होतात, पण त्यातून काहीही शिकवले जात नाही.

दोन सवयींमुळे ती लहान ठेवता येते. तपशील index मधून काढून topic files मध्ये ठेवा. Claude त्या files startup वेळी नव्हे, तर गरजेनुसार वाचते. Workflow instructions CLAUDE.md मधून काढून skills मध्ये ठेवा. ती skills invoke केल्यावरच load होतात. Frontmatter ने सुरू होणाऱ्या memory files साठी version 2.1.214 किंवा त्यानंतरच्या आवृत्तीत Claude Code लेखनाची वेळ modified field मध्ये ISO 8601 timestamp म्हणून नोंदवते. कालबाह्य झालेली माहिती ओळखण्याचा हा सर्वात जलद मार्ग आहे. कालबाह्य agent memory काढण्याची प्रक्रिया या review process चे अधिक सविस्तर वर्णन करते.

कॉन्टेक्स्टमध्ये सर्व काही लोड करण्यापेक्षा आवश्यकतेनुसार पुनर्प्राप्ती अधिक उपयुक्त ठरते

Memory tool चा उपयोग आवश्यकतेनुसार माहिती पुनर्प्राप्त करण्यासाठी होतो. सुरुवातीलाच सर्व माहिती लोड करण्याऐवजी agent त्याला मिळालेली माहिती नोंदवतो आणि एखाद्या कामासाठी गरज भासल्यावरच फाइल पुन्हा वाचतो. त्यामुळे गणना बदलते. फाइल वाचण्याचा token खर्च एकदाच होतो आणि त्यानंतर ती cached prefix मध्ये राहते. याउलट, कायम लोड ठेवलेल्या block साठी प्रत्येक turn ला खर्च होतो.

वरील दोन charts वरून एक साधा नियम लागू होतो. जवळजवळ प्रत्येक turn मध्ये वापरला जाणारा मजकूर stable cached prefix मध्ये ठेवावा. वीसपैकी एका turn मध्ये वापरला जाणारा मजकूर view call मागे ठेवावा. तुमच्या replay count नुसार break-even point बदलतो; Anthropic आकारत असलेल्या कोणत्याही शुल्कानुसार तो बदलत नाही.

API वर platform ला conversation स्वतः trim करण्याची परवानगीही देता येते. Context editing मध्ये conversation तुम्ही निश्चित केलेला threshold ओलांडल्यावर जुने 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}
    }
  ]
}

मूलभूत settings मध्ये trigger 100,000 input tokens आणि ठेवलेले 3 tool uses असतात. ते enable करण्यापूर्वी caching सह interaction वाचा. Content clear केल्यावर clear केलेल्या ठिकाणी cached prefix invalid होतो. त्यामुळे पुढील request साठी cache write चा खर्च होतो. यासाठी clear_at_least वापरले जाते. Cache write चा खर्च समायोजित करण्याइतकी saving होईपर्यंत ते clearing पुढे ढकलते. context_management अंतर्गत response मध्ये नेमके काय घडले ते cleared_tool_uses आणि cleared_input_tokens सह कळवले जाते. त्यामुळे हा trade सैद्धांतिक न राहता मोजता येतो. Claude Code मध्ये context window व्यवस्थापित करणे हीच कल्पना coding session ला लागू करते.

स्वतंत्र शुल्क म्हणून कोणत्या गोष्टींचा समावेश आहे

Memory साठी स्वतंत्र शुल्क नाही. मात्र काही features साठी खरोखर स्वतंत्र शुल्क आकारले जाते, आणि कोणत्या features साठी ते लागू होते हे जाणून घेणे उपयुक्त आहे. खाली August 2026 पर्यंतचे प्रकाशित Claude API rates दिले आहेत. काही operations पूर्णपणे विनाशुल्क आहेत. मात्र Claude API वर free tier उपलब्ध नाही, signup वेळी मिळणारे लहान credit वगळता. त्यामुळे खालील सर्व खर्च तुमच्या पहिल्या request पासून प्रत्यक्ष आकारला जातो.

• Web search: प्रत्येक 1,000 searches साठी $10, तसेच search ने context मध्ये समाविष्ट केलेल्या सर्व मजकुराचा नेहमीचा token cost.
• Code execution: प्रत्येक organization साठी दरमहा 1,550 free hours. त्यानंतर प्रत्येक container साठी प्रति तास $0.05. Web search किंवा web fetch सोबत वापरल्यास यासाठी शुल्क आकारले जात नाही.
• Claude Managed Agents: नेहमीच्या token charges व्यतिरिक्त, प्रत्येक session-hour साठी $0.08 session runtime शुल्क.
• Web fetch: अतिरिक्त शुल्क नाही. फक्त fetched content चा token cost लागू होतो.

यापैकी कोणत्याही line item मध्ये Memory दिसत नाही. ते तुमच्या input token count मध्ये समाविष्ट होते. त्यामुळे त्याचे मोजमाप करता येते आणि pruning व caching द्वारे त्याचा खर्च कमी करता येतो. Virtual private server (VPS) वर unattended चालणाऱ्या agent साठी अंदाजपत्रक तयार करत असल्यास, VPS वरील AI agent साठी cost controls पुढीलप्रमाणे लागू करा. वाढणारी memory file आणि pruning नसलेला agent कोणतीही माहिती नोंदवली जात नसताना दर आठवड्याला अधिक महाग होत जातो.

FAQ

Claude च्या memory features साठी स्वतंत्र शुल्क आहे का?

नाही. Anthropic च्या price list मध्ये प्रति million input tokens, प्रति million 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 मध्ये आणि CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 ने सुरू केलेल्या session मध्ये /context चालवा. त्यानंतर त्याच task साठी खर्च झालेल्या एकूण tokens ची तुलना करा.

मी काहीही बदलले नसताना माझा usage का वाढला?

Pause नंतर cache miss होणे हे सर्वात सामान्य कारण आहे. Cache entries default ने 5 minutes पर्यंत किंवा extended setting मध्ये one hour पर्यंत उपलब्ध असतात. त्यामुळे break नंतरची पहिली request संपूर्ण prefix पुन्हा base input rate ने process करते आणि तो पुन्हा लिहिते. दुसरे सामान्य कारण म्हणजे prefix edit. Tool definition बदलल्यास संपूर्ण cache invalid होतो. System prompt बदलल्यास system आणि message cache invalid होतो. Subscription plan मध्ये अलीकडील usage पैकी 10 percent किंवा अधिक भाग यामुळे झाल्यास /usage breakdown मध्ये त्या behaviour चे नाव दिसते.

Memory system prompt मध्ये ठेवावे की tool call मागे?

जवळपास प्रत्येक turn मध्ये memory वापरली जात असेल, तर ती system prompt मध्ये ठेवा. त्यामुळे ती cached prefix मध्ये राहते आणि cache read rate नुसार तिची किंमत आकारली जाते. फक्त काही tasks साठी memory आवश्यक असेल, तर ती view call मागे ठेवा. एकदाच वाचलेल्या file च्या tokens साठी प्रत्येक turn ला पुन्हा शुल्क आकारले जाण्याऐवजी एकदाच शुल्क आकारले जाते. निर्णायक संख्या म्हणजे तुमचा replay count. usage object ही संख्या थेट देतो.

Memory features subscription usage limits मध्ये मोजली जातात का?

होय, अप्रत्यक्षपणे. प्रत्येक request मध्ये वाहून नेल्या जाणाऱ्या tokens मुळे subscription limits वापरल्या जातात. Anthropic च्या help documentation नुसार automatic context management सुरू करणाऱ्या लांब conversations मुळे usage limit मधील अधिक भाग वापरला जातो. Memory मुळे प्रत्येक request थोडी लांब होते. Long session मध्ये ही लांबी प्रत्येक turn ला पुन्हा पाठवली जाते. Claude च्या usage limits प्रत्यक्षात कशा कार्य करतात यामध्ये reset कधी होते हे स्पष्ट केले आहे.