द्वारे Matt Connor 2026-08-13 · अपडेटेड 2026-08-29

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

Anthropic ने memory token साठी स्वतंत्र दर प्रकाशित केलेले नाहीत. लक्षात ठेवलेला मजकूर input tokens म्हणून पुन्हा पाठवल्यास, caching उपलब्ध आहे की नाही यानुसार खर्च ठरतो.

Claude ची memory features अतिरिक्त शुल्क आकारतात का?

Claude च्या memory features साठी स्वतंत्र शुल्क आकारले जात नाही. Anthropic ने प्रकाशित केलेले दर प्रति million input tokens आणि प्रति million output tokens यांवर आधारित आहेत. Prompt caching साठी अतिरिक्त दर आहेत. यापैकी कोणत्याही घटकाला memory token म्हटलेले नाही. Claude API (application programming interface) मध्ये memory साठवण्यासाठी शुल्क लागत नाही, कारण memory tool client-side असते आणि फाइल तुमच्या मालकीच्या storage वर असते.

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

Pro किंवा Max subscription वर प्रति token शुल्क आकारले जात नाही. त्यामुळे memory मुळे तुमच्या पैशांऐवजी usage allowance वापरला जातो. खालील mechanism तसाच राहतो. फक्त मोजमापाचे एकक बदलते. ही allowance मर्यादित असते. त्यामुळे प्रत्येक turn मध्ये किती memory ठेवायची हे ठरवण्यापूर्वी Claude Pro ची किंमत आणि त्याच्या मर्यादा तुम्हाला कधी थांबवतात हे जाणून घेणे उपयुक्त ठरते. Claude Enterprise ची पद्धत वेगळी आहे, कारण seat price व्यतिरिक्त प्रत्येक token चे API दरांनुसार मोजमाप केले जाते. त्यामुळे 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 साठी शुल्क द्यावे लागते. प्रत्येक request मध्ये tool definition पाठवली जाते आणि त्यानंतर परत आलेली file content conversation मध्येच राहते.

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

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

Claude on the web. 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 मधील मजकुराचा आणखी एक 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 बाजूवरच मोजली जाते.

तुमच्या स्वतःच्या वापरातील हे आकडे कुठे पाहावेत

ब्लॉग पोस्टमधील आकडा वापरू नका, ही पोस्टदेखील त्याला अपवाद नाही. तुमच्या स्वतःच्या 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 मजकूर system field मध्ये paste करून एकदा चालवा आणि memory शिवाय पुन्हा एकदा चालवा. या दोन आकड्यांमधील फरक म्हणजे प्रत्येक turn मध्ये त्या memory साठी लागणारा खर्च. दोन गोष्टी लक्षात ठेवा. हा count अंदाजे असतो. Anthropic स्वतःच्या system optimizations साठी जोडत असलेले अतिरिक्त tokens तुमच्याकडून आकारले जात नाहीत. तसेच, तुम्ही प्रत्यक्षात वापरणार असलेल्या model नुसार count करा, कारण Claude 4.7 आणि त्यानंतरच्या आवृत्त्या नवीन tokenizer वापरतात आणि त्याच मजकुरासाठी साधारण 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 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 स्थानिक पातळीवर मोजते. त्यामुळे तुमच्यावर लागू असलेली कोणतीही discount ती विचारात घेत नाही आणि हा आकडा तुमच्या invoice पेक्षा वेगळा असू शकतो. Claude Console मधील Usage page हा अधिकृत आकडा आहे.

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

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

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

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

Prompt caching मुळे तोच memory block एका turn मध्ये दुसऱ्या turn पेक्षा दहापट महाग पडू शकतो. Anthropic cache rates प्रत्येक model च्या base input price च्या गुणक म्हणून प्रकाशित करते. त्यामुळे डॉलरमधील किंमती बदलल्या तरी हा संबंध कायम राहतो.

ChartAnthropic's published prompt caching rates, as a multiple of base input price

label

price_multiple

Base input

5 minute cache write

1.25

1 hour cache write

Cache read

0.1

The data behind this chart

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

हे गुणक replay count चे गणितात रूपांतर करतात. पुढील block हे वर दिलेल्या प्रकाशित गुणकांवर आधारित गणित आहे. ते कोणत्याही प्रत्यक्ष live workload चे मोजमाप नाही. 100 turn च्या session मध्ये memory block ची किंमत तीन प्रकारे मांडली आहे. ती plain base input rate वर आकारल्या जाणाऱ्या tokens च्या समतुल्य संख्येत व्यक्त केली आहे.

ChartA memory block over 100 turns, expressed as base-rate input tokens

label

base_rate_equivalent_tokens

4,000 tokens, never cached

400,000

4,000 tokens, 1 write and 99 reads

44,600

1,000 tokens, 1 write and 99 reads

11,150

The data behind this chart

[
  {
    "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 इतके येते. तोच block एका 5 minute cache write आणि 99 cache reads मागे ठेवल्यास त्याचे बिल 44,600 इतके येते. त्याचा आकार एक चतुर्थांश करून caching कायम ठेवल्यास त्याचे बिल 11,150 इतके येते. या 3 rows मध्ये feature बदललेले नाही. फक्त replay behaviour बदलले आहे. हे अजूनही पैशांऐवजी token counts आहेत. token count चे तुमच्या मासिक बिलातील रकमेतील रूपांतर करण्यासाठी model च्या per-million rate ने एकदा गुणाकार करावा लागतो. हा rate तुम्ही वापरत असलेल्या model ने ठरतो. त्यामुळे agent Claude Fable 5 वर चालणार असल्यास त्याचे प्रकाशित per-million rates आणि त्याला योग्य असलेले काम यापासून सुरुवात करा. Provider अजून निश्चित नसेल आणि केवळ model निवडण्याचा प्रश्न नसेल, तर Claude च्या API वर आणि ChatGPT वर समान jobs ची किंमत हा गुणाकार कुठे वेगळा परिणाम देतो ते दाखवते. Memory-heavy agent input बाजूवर याचा मोठा परिणाम घेतो.

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

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

Cache entry ला एक lifetime असतो. ही वेळ ती entry लिहिणाऱ्या किंवा वाचणाऱ्या 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 lifetime five minutes असतो. ENABLE_PROMPT_CACHING_1H=1 सेट केल्यास usage credits वापरत असतानाही one hour lifetime कायम राहतो.

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

यावर विश्वास ठेवण्याऐवजी तुम्ही स्वतः पडताळणी करू शकता. Pro, Max, Team किंवा Enterprise plan वर /usage breakdown अलीकडील usage पैकी 10 percent किंवा अधिक usage साठी जबाबदार असलेले 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 शिकत असताना ते पुन्हा लिहिणाऱ्या प्रत्येकासाठी हा महत्त्वाचा सापळा आहे. प्रत्येक पुनर्लेखनामुळे त्यानंतरच्या सर्व मजकुराची कॅश केलेली प्रत टाकून दिली जाते. त्यामुळे पुढील request साठी पुन्हा संपूर्ण write करावा लागतो. स्थिर सामग्री सुरुवातीला ठेवा आणि ती स्थिरच ठेवा. बदलणारी सामग्री message list मध्ये शेवटी ठेवा. त्यामुळे ती अमान्य झाल्यास खर्च कमी राहतो.

याशिवाय आणखी एक शांतपणे होणारे अपयश आहे. प्रत्येक model साठी कॅश करता येणाऱ्या prefix ची किमान लांबी वेगळी असते: August 2026 मध्ये प्रकाशित माहितीनुसार Claude Opus 5 साठी 512 tokens, Claude Sonnet 5 साठी 1,024 आणि Claude Haiku 4.5 साठी 4,096. त्यापेक्षा कमी लांबीच्या prefix बाबत काय होते हे Anthropic च्या documentation मध्ये स्पष्ट सांगितले आहे: "Any requests to cache fewer than this number of tokens will be processed without caching, and no error is returned." त्यामुळे cache_control ने चिन्हांकित केलेली छोटी memory file प्रत्यक्षात काहीही करत नाही; हे शांतपणे घडते. तुमच्या prompt मध्ये breakpoint स्पष्टपणे असतानाही cache_creation_input_tokens चे मूल्य 0 वरच राहणे हे दिसणारे लक्षण आहे.

ज्या memory चे महत्त्व उरलेले नाही ते काढून टाका

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

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

संपूर्ण मजकूर context मध्ये लोड करण्यापेक्षा retrieval अधिक उपयुक्त ठरते

memory tool हे just-in-time retrieval साठी आहे. सुरुवातीलाच सर्व मजकूर लोड करण्याऐवजी agent त्याला जे समजते ते नोंदवतो आणि एखाद्या task साठी गरज असेल तेव्हाच file पुन्हा वाचतो. त्यामुळे गणित बदलते. File read साठीचे tokens एकदाच खर्च होतात आणि त्यानंतर ते cached prefix मध्ये राहतात. याउलट, कायम लोड केलेल्या block साठी प्रत्येक turn वर खर्च होतो.

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

API वर तुम्ही platform ला conversation trim करण्याची अनुमतीही देऊ शकता. तुम्ही निश्चित केलेला 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 settings मध्ये 100,000 input tokens चा trigger आणि ठेवलेले 3 tool uses असतात. ते enable करण्यापूर्वी caching सह interaction वाचा. Clear केल्याच्या ठिकाणी content साफ केल्यामुळे cached prefix invalid होतो. त्यामुळे पुढील request वर cache write साठी शुल्क आकारले जाते. यासाठीच clear_at_least आहे. Saving इतकी मोठी होईपर्यंत ते clearing थांबवते की cache write योग्य ठरते. context_management अंतर्गत नेमके काय झाले याचा response अहवाल मिळतो. त्यात cleared_tool_uses आणि cleared_input_tokens असतात. त्यामुळे हा trade सैद्धांतिक न राहता मोजता येतो. Claude Code मध्ये context window व्यवस्थापित करणे हीच कल्पना coding session वर लागू करते.

स्वतंत्र शुल्क कशासाठी आकारला जातो

Memory साठी स्वतंत्र शुल्क आकारले जात नाही. मात्र काही वैशिष्ट्यांसाठी खरोखर स्वतंत्र शुल्क आकारले जाते. कोणत्या वैशिष्ट्यांसाठी ते लागू होते हे जाणून घेणे उपयुक्त आहे. ऑगस्ट 2026 पर्यंतचे प्रकाशित Claude API दर पुढीलप्रमाणे आहेत. काही क्रियांना अजिबात शुल्क लागत नाही. मात्र Claude API वर विनामूल्य स्तर उपलब्ध नाही, नोंदणीवेळी मिळणाऱ्या अल्प 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 charges व्यतिरिक्त, session runtime साठी प्रत्येक session-hour ला $0.08.
Web fetch: कोणतेही अतिरिक्त शुल्क नाही. फक्त fetch केलेल्या content चा token खर्च लागू होतो.

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

FAQ

Claude च्या memory वैशिष्ट्यांसाठी स्वतंत्र शुल्क आकारले जाते का?

नाही. Anthropic च्या price list मध्ये प्रति दशलक्ष input tokens, प्रति दशलक्ष output tokens आणि prompt caching multiples यांचे दर दिलेले आहेत; memory साठी स्वतंत्र नोंद नाही. Claude API मध्ये memory tool client-side असते, त्यामुळे files तुम्ही आधीच पैसे देत असलेल्या storage वरच राहतात. memory मुळे वाढणारी गोष्ट म्हणजे input tokens. ते ज्या प्रत्येक turn मध्ये पाठवले जातात, त्या प्रत्येक turn साठी model च्या नेहमीच्या input rate नुसार billing होते.

memory बंद केल्याने Claude स्वस्त होते का?

प्रत्येक request मधील token count कमी होतो, त्यामुळे प्रत्येक request ची किंमत कमी होते. मात्र एकूण खर्चात बचत होईल का, हे पुढे काय घडते यावर अवलंबून असते. memory मध्ये आधीच असलेली माहिती पुन्हा तयार करण्यासाठी Claude ला तीन files पुन्हा वाचाव्या लागल्या आणि तुम्हाला दोन प्रश्न विचारावे लागले, तर त्या tokens ची किंमत memory पेक्षा जास्त असू शकते. अंदाज बांधण्याऐवजी मोजमाप करा: auto memory सुरू असलेल्या session मध्ये /context चालवा आणि CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 ने सुरू केलेल्या session मध्येही ते चालवा. त्यानंतर त्याच task वर खर्च झालेले एकूण tokens तुलना करा.

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

याचे सर्वात सामान्य कारण म्हणजे pause नंतर cache miss होणे. Cache entries default ने 5 minutes टिकतात; extended setting मध्ये त्या one hour टिकतात. त्यामुळे खंडानंतरची पहिली request संपूर्ण prefix पुन्हा base input rate नुसार process करते आणि तो prefix पुन्हा लिहिते. दुसरे सामान्य कारण म्हणजे prefix edit. Tool definition बदलल्यास संपूर्ण cache invalid होतो. System prompt बदलल्यास system आणि 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 हा count थेट देतो.

memory वैशिष्ट्ये subscription usage limits मध्ये मोजली जातात का?

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

#claude #memory #tokens #pricing #prompt-caching