क्या Claude के memory फीचर्स के लिए अलग से शुल्क लगता है?

क्या Claude के memory फीचर्स के लिए अतिरिक्त शुल्क लगता है?

Claude के memory फीचर्स की अपनी कोई अलग कीमत नहीं है। Anthropic की प्रकाशित दरें प्रति मिलियन इनपुट टोकन और प्रति मिलियन आउटपुट टोकन के आधार पर हैं, जिसमें prompt caching के लिए अतिरिक्त दरें शामिल हैं, और इनमें से किसी को भी memory टोकन नहीं कहा जाता है। Claude API (application programming interface) पर memory को स्टोर करने का कोई शुल्क नहीं लगता है, क्योंकि memory टूल client-side पर होता है और फाइल आपके अपने स्टोरेज में रहती है।

Memory का असर आपके बिल पर फिर भी पड़ता है, क्योंकि कोई याद रखा गया तथ्य केवल तभी उत्तर को बदलता है जब वह उस request के भीतर हो जिसे Claude पढ़ता है। याद रखने का अर्थ है उसे फिर से भेजना। वह टेक्स्ट इनपुट टोकन के रूप में पहुँचता है और मॉडल की सामान्य इनपुट दर पर चार्ज किया जाता है। दो संख्याएँ यह तय करती हैं कि कितना शुल्क लगेगा: हर टर्न पर आप कितना याद रखा गया टेक्स्ट फिर से भेजते हैं, और क्या उस रीप्ले किए गए टेक्स्ट को prompt cache से सर्व किया जा सकता है।

Pro या Max सब्सक्रिप्शन पर आपसे प्रति टोकन के हिसाब से बिल नहीं लिया जाता है, इसलिए memory आपके पैसों के बजाय आपके usage allowance का उपयोग करती है। नीचे दी गई प्रक्रिया समान है। केवल इकाई बदलती है। वह allowance सीमित है, इसलिए यह जानना उचित है कि Claude Pro की कीमत क्या है और वह सीमा कहाँ है जहाँ इसके उपयोग पर रोक लग जाती है इससे पहले कि आप यह तय करें कि हर टर्न में कितनी memory होनी चाहिए। Claude Enterprise की स्थिति अलग है, क्योंकि यह सीट की कीमत के अलावा API दरों पर हर टोकन को मापता है, इसलिए एक बहुत बड़ा memory ब्लॉक allowance के बजाय फिर से पैसों में बदल जाता है। यदि memory को कम करने से आपका usage किसी छोटे प्लान की सीमा के भीतर आ जाता है, तो Max से Pro पर स्विच करना एक सार्थक कदम है, और यह बदलाव उस अवधि के अंत में लागू होता है जिसके लिए आप पहले ही भुगतान कर चुके हैं। यदि आप Anthropic के अपने टियर्स के बजाय अलग-अलग प्रोवाइडर्स के बीच तुलना कर रहे हैं, तो मौजूदा कीमतों पर ChatGPT के साथ Claude के प्लान्स की तुलना से शुरुआत करना सही रहेगा।

प्रत्येक Claude surface पर "memory" का क्या अर्थ है

तीन अलग-अलग उत्पाद इस शब्द का उपयोग करते हैं, और उन्हें आपस में मिला देने के कारण ही यह प्रश्न भ्रमित करने वाला लगता है।

Claude API पर memory tool। आप tools array में एक entry जोड़ते हैं और अपने स्वयं के code में file operations को implement करते हैं।

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

अगस्त 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 के निश्चित हिस्से को प्रकाशित करता है। Claude Opus 5 पर auto के tool choice के साथ, tool-use system prompt 286 tokens का है, जैसा कि अगस्त 2026 में प्रलेखित है। जब भी कोई tool मौजूद होता है, चाहे वह memory हो या कोई अन्य, इसका भुगतान प्रति request एक बार किया जाता है।

Claude Code। हर session की शुरुआत में दो mechanisms load होते हैं। CLAUDE.md files में वे निर्देश होते हैं जिन्हें आप लिखते हैं। Auto memory में वे notes होते हैं जिन्हें Claude स्वयं ~/.claude/projects/<project>/memory/ के अंतर्गत लिखता है। MEMORY.md की केवल पहली 200 lines या 25KB load की जाती है, जो भी सीमा पहले पूरी हो जाए, और इसके बगल की topic files को startup के बजाय मांग पर (on demand) पढ़ा जाता है। startup पर load की गई हर चीज़ उस prefix का हिस्सा बन जाती है जिसे उस session की हर बाद की request carry करती है। Claude Code sessions के बीच memory को कैसे याद रखता है file-दर-file loading order को कवर करता है।

वेब पर Claude। claude.ai पर, memory उन entries का एक समूह है जिन्हें Claude आपके chat करने के साथ लिखता और update करता है, जिसमें प्रत्येक project के लिए एक अलग memory space होता है। Settings > Memory में वह सूची होती है जो store की गई है, और वहां मौजूद toggle, Pause memory या Reset memory का विकल्प देता है। इस surface के लिए subscription द्वारा billing की जाती है, इसलिए यहाँ memory का उपयोग usage limits को खर्च करता है।

याद रखा गया टेक्स्ट इनपुट टोकन के रूप में क्यों बिल किया जाता है

Messages API स्टेटलेस है। यह कॉल के बीच कुछ भी याद नहीं रखता है, इसलिए आपका क्लाइंट हर बार पूरी बातचीत भेजता है और मॉडल इसे फिर से पढ़ता है। मेमोरी इस नियम का अपवाद नहीं है। यह उसी अनुरोध में टेक्स्ट का एक और ब्लॉक है।

यह विभाजन किसी भी प्रतिक्रिया पर usage ऑब्जेक्ट में दिखाई देता है।

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

input_tokens केवल उन टोकन की गणना करता है जिन्हें न तो कैश से पढ़ा गया था और न ही इसे बनाने के लिए उपयोग किया गया था, जिसका व्यावहारिक अर्थ है अंतिम कैश ब्रेकपॉइंट के बाद के टोकन। अनुरोध के लिए कुल इनपुट cache_read_input_tokens प्लस cache_creation_input_tokens प्लस input_tokens है। Claude द्वारा तीन टर्न पहले खोली गई मेमोरी फाइल उस समय के बाद से हर टर्न पर उस कुल योग के भीतर रहती है। जब तक कैश किया गया प्रीफिक्स बना रहता है, यह cache_read_input_tokens के अंतर्गत आता है, और जब ऐसा नहीं होता है, तो यह input_tokens के अंतर्गत आता है। टेक्स्ट वही है, लेकिन कीमतें बहुत अलग हैं। इनपुट और आउटपुट टोकन की कीमतें अलग-अलग होती हैं, और मेमोरी हमेशा इनपुट साइड पर ही रहती है।

अपने स्वयं के उपयोग में इन संख्याओं को कहाँ देखें

किसी ब्लॉग पोस्ट से कोई आंकड़ा न लें, जिसमें यह पोस्ट भी शामिल है। अपने स्वयं के मेमोरी ब्लॉक को मापें। टोकन की गिनती निःशुल्क है और इसकी अपनी दर सीमा है, इसलिए माप में कोई खर्च नहीं आता है।

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 }। इसे एक बार अपने मेमोरी टेक्स्ट को system फ़ील्ड में पेस्ट करके चलाएं और एक बार बिना उसके, और जो अंतर है वही वह लागत है जो वह मेमोरी हर टर्न पर आपसे लेती है। दो सावधानियां बरतें। यह गिनती एक अनुमान है, और Anthropic द्वारा अपने सिस्टम ऑप्टिमाइज़ेशन के लिए जोड़े गए अतिरिक्त टोकन आपसे चार्ज नहीं किए जाते हैं। साथ ही, उस मॉडल के विरुद्ध गणना करें जिसे आप वास्तव में चलाएंगे, क्योंकि Claude 4.7 और बाद के संस्करण एक नए टोकेनाइज़र का उपयोग करते हैं जो समान टेक्स्ट के लिए लगभग 30 प्रतिशत अधिक टोकन उत्पन्न करता है।

Claude Code के अंदर यही प्रश्न बिना किसी curl के हल हो जाता है।

• /context दिखाता है कि अभी क्या लोड है, जिसमें मेमोरी फाइलें भी शामिल हैं, ताकि आप कुछ भी टाइप करने से पहले विंडो में उनका हिस्सा देख सकें।
• /memory आपकी CLAUDE.md फाइलों को सूचीबद्ध करता है और ऑटो मेमोरी फोल्डर को खोलता है।
• /usage सत्र के कुल योग को प्रिंट करता है, जिसमें कैश रीड और कैश राइट शामिल हैं।
• स्टेटस लाइन लगातार कॉन्टेक्स्ट विंडो के उपयोग को प्रदर्शित कर सकती है, ताकि वृद्धि होते समय दिखाई दे।

/usage सत्र ब्लॉक इस तरह दिखता है:

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)

अंतिम पंक्ति को ध्यान से पढ़ें। 940.0k कैश रीड का आंकड़ा वह बातचीत है, जिसमें मेमोरी और सब कुछ शामिल है, जिसे हर टर्न पर कैश दर पर फिर से भेजा जा रहा है। 1.2k इनपुट का आंकड़ा केवल वह हिस्सा है जो नया था। Claude Code उस डॉलर राशि की गणना स्थानीय रूप से सूची मूल्यों से करता है, इसलिए यह आपके किसी भी डिस्काउंट को अनदेखा करता है और आपके इनवॉइस से भिन्न हो सकता है। Claude Console में उपयोग (Usage) पृष्ठ आधिकारिक संख्या है।

फिर सीधे तुलना करें। दो नए सत्रों में एक ही शुरुआती प्रश्न पूछें, एक सामान्य और एक ऑटो मेमोरी बंद करके।

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

प्रत्येक में /context चलाएं और मेमोरी फाइल प्रविष्टि की तुलना करें। अंतर वह है जो आपकी संचित मेमोरी हर सत्र की शुरुआत में, किसी भी काम के होने से पहले, खर्च करती है। Claude Code टोकन उपयोग कहाँ जाता है, इसका पूरा विवरण उन दो संख्याओं के साथ पढ़ना सार्थक है।

प्रति मिलियन टोकन मेमोरी को रीप्ले करने की लागत कितनी है?

Prompt caching ही वह कारण है जिससे एक ही मेमोरी ब्लॉक की लागत एक टर्न पर दूसरे टर्न की तुलना में दस गुना अधिक हो सकती है। Anthropic कैश दरों को प्रत्येक मॉडल की बेस इनपुट कीमत के गुणक (multiples) के रूप में प्रकाशित करता है, इसलिए डॉलर की कीमतें बदलने पर भी यह संबंध बना रहता है।

[
  {
    "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
  }
]

कैश रीड की लागत बेस इनपुट कीमत का 0.1 गुना होती है। 5 मिनट की लाइफटाइम वाली एंट्री लिखने की लागत बेस का 1.25 गुना है, और 1 घंटे की लाइफटाइम वाली एंट्री की लागत बेस का 2 गुना है। Anthropic ब्रेक-ईवन (break-even) को स्पष्ट रूप से बताता है: 5 मिनट की अवधि पर एक कैश रीड के बाद, या 1 घंटे की अवधि पर दो कैश रीड के बाद कैशिंग फायदेमंद हो जाती है। प्रॉम्प्ट कैशिंग के लिए ब्रेक-ईवन पॉइंट वह गणना है जिसे आपको यह तय करने से पहले करना चाहिए कि मेमोरी कहाँ रखी जानी चाहिए।

ये गुणक रीप्ले काउंट को अंकगणित में बदल देते हैं। अगला ब्लॉक ऊपर प्रकाशित गुणकों का अंकगणित है, न कि किसी लाइव वर्कलोड का मापन। यह 100 टर्न के सेशन में एक मेमोरी ब्लॉक की कीमत तीन तरीकों से तय करता है, जिसे साधारण बेस इनपुट दर पर चार्ज किए गए टोकन की समतुल्य संख्या के रूप में व्यक्त किया गया है।

[
  {
    "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 टोकन का एक मेमोरी ब्लॉक जो सभी 100 टर्न पर कैश मिस करता है, उसका बिल 400,000 बेस-रेट टोकन की तरह बनता है। वही ब्लॉक एक 5 मिनट के कैश राइट और 99 कैश रीड के बाद 44,600 की तरह बिल होता है। इसे इसके आकार के एक चौथाई तक कम करें और कैशिंग बनाए रखें, तो यह 11,150 की तरह बिल होता है। उन 3 पंक्तियों में फीचर नहीं बदला। केवल रीप्ले व्यवहार बदला। ये अभी भी टोकन की संख्या है न कि पैसा, और टोकन की संख्या को अपने मासिक बिल की राशि में बदलना आपके मॉडल की प्रति-मिलियन दर से एक गुणा (multiplication) है। वह दर आपके द्वारा चलाए जाने वाले मॉडल द्वारा निर्धारित होती है, इसलिए यदि एजेंट Claude Fable 5 पर काम करेगा, तो इसकी प्रकाशित प्रति-मिलियन दरों और इसके अनुकूल कार्यों से शुरुआत करें।

दूसरी पंक्ति यह मानती है कि बाद के 99 अनुरोधों में से प्रत्येक तब आता है जब कैश एंट्री अभी भी सक्रिय (alive) होती है। यही वह धारणा है जहाँ अधिकांश वास्तविक बिल गलत हो जाते हैं।

ब्रेक के बाद एक ही प्रश्न की लागत अधिक क्यों होती है?

कैश एंट्री (cache entry) का एक लाइफटाइम होता है, और यह समय उस रिक्वेस्ट से शुरू होता है जो इसे लिखती या पढ़ती है। डिफ़ॉल्ट समय 5 मिनट है। 1 घंटे का विकल्प ऊपर दिखाए गए 2x राइट (write) की लागत लेता है। Claude Code में सब्सक्रिप्शन होने पर लाइफटाइम एक घंटा होता है, और जब आप यूसेज क्रेडिट्स (usage credits) का उपयोग कर रहे होते हैं तो यह घटकर पांच मिनट हो जाता है; API की या क्लाउड प्रोवाइडर पर यह डिफ़ॉल्ट रूप से पांच मिनट ही रहता है। ENABLE_PROMPT_CACHING_1H=1 सेट करने से यूसेज क्रेडिट्स पर रहने के दौरान भी एक घंटे का लाइफटाइम बना रहता है।

इसलिए, लंच के दौरान खुली छोड़ी गई सेशन में टाइप किया गया एक लाइन का प्रश्न महंगा होता है क्योंकि आपके दूर रहने के दौरान कैश एंट्री समाप्त हो गई थी। पूरा प्रीफिक्स (prefix), जिसमें मेमोरी भी शामिल है, बेस इनपुट रेट पर फिर से प्रोसेस किया जाता है और दोबारा कैश में लिखा जाता है। ब्रेक की अवधि ने उस कीमत को निर्धारित किया।

आप इसे मानने के बजाय स्वयं पुष्टि कर सकते हैं। Pro, Max, Team या Enterprise प्लान पर, /usage ब्रेकडाउन हाल के उपयोग के 10 प्रतिशत या उससे अधिक के लिए जिम्मेदार किसी भी व्यवहार को फ्लैग करता है, और लंबा कॉन्टेक्स्ट (long context) तथा कैश मिस (cache misses) दोनों वहां नाम के साथ दिखाई देते हैं। API पर, शांत अवधि के बाद पहली रिक्वेस्ट पर cache_creation_input_tokens को वापस आपके प्रीफिक्स के पूर्ण आकार तक बढ़ते हुए देखें।

Cache को चुपचाप क्या अमान्य (invalidate) करता है

Cached prefix का क्रम इस प्रकार है: tools, फिर system, और अंत में messages। किसी एक स्तर पर किया गया बदलाव उस स्तर और उसके बाद की हर चीज़ को अमान्य कर देता है। किसी tool definition को edit करने से पूरा cache हट जाता है। System prompt को edit करने से system और message cache दोनों हट जाते हैं।

यह उन लोगों के लिए एक जाल है जो system prompt में memory रखते हैं और agent के सीखने के साथ उसे rewrite करते रहते हैं। प्रत्येक rewrite उसके पीछे की हर चीज़ की cached copy को हटा देता है, इसलिए अगली request में फिर से पूरा write करना पड़ता है। स्थिर सामग्री (stable material) को शुरुआत में रखें और उसे न बदलें, और परिवर्तनशील सामग्री (volatile material) को message list के अंत में रखें जहाँ उसे अमान्य करना सस्ता पड़ता है।

एक दूसरी, अधिक शांत विफलता भी है। प्रत्येक model का एक न्यूनतम cacheable prefix होता है: अगस्त 2026 में प्रकाशित आंकड़ों के अनुसार, Claude Opus 5 पर 512 tokens, Claude Sonnet 5 पर 1,024 tokens, और Claude Haiku 4.5 पर 4,096 tokens। Anthropic का documentation स्पष्ट करता है कि इससे कम होने पर क्या होता है: "इस संख्या से कम tokens को cache करने के किसी भी request को बिना caching के process किया जाएगा, और कोई error return नहीं की जाएगी।" इसलिए cache_control के साथ चिह्नित एक छोटी memory file वास्तव में कुछ नहीं करती है, वह भी चुपचाप। इसका लक्षण यह है कि cache_creation_input_tokens 0 पर ही रहता है, जबकि आपके prompt में स्पष्ट रूप से एक breakpoint मौजूद होता है।

ऐसी मेमोरी को हटाएँ जो अब उपयोगी नहीं है

मेमोरी की हर लाइन हर टर्न पर टोकन खर्च करती है, इसलिए हर लाइन के लिए यह सवाल महत्वपूर्ण है कि क्या उसने हाल ही में किसी उत्तर को बदला है। Claude Code इन सीमाओं को स्पष्ट करता है। CLAUDE.md को 200 लाइनों से कम रखने का लक्ष्य रखें, क्योंकि लंबी फाइलें अधिक कॉन्टेक्स्ट का उपयोग करती हैं और Claude के उनके निर्देशों का पालन करने की विश्वसनीयता को कम करती हैं। MEMORY.md लोड होने के समय पहली 200 लाइनों या 25KB तक सीमित है, और उस सीमा के बाद का कुछ भी अगले सत्र की शुरुआत में हटा दिया जाता है, इसलिए एक बहुत बड़ा इंडेक्स टोकन खर्च करता है और कोई लाभ नहीं देता।

इसे छोटा रखने के लिए दो आदतें अपनाएँ। विवरण को इंडेक्स से हटाकर टॉपिक फाइलों में ले जाएँ, जिन्हें Claude स्टार्टअप के बजाय आवश्यकता पड़ने पर पढ़ता है। वर्कफ़्लो निर्देशों को CLAUDE.md से हटाकर स्किल्स में ले जाएँ, जो केवल बुलाए जाने पर लोड होते हैं। उन मेमोरी फाइलों के लिए जो पहले से ही फ्रंटमैटर से शुरू होती हैं, Claude Code वर्जन 2.1.214 या उसके बाद में modified फील्ड में ISO 8601 टाइमस्टैम्प के रूप में लिखने का समय रिकॉर्ड करता है, और वह टाइमस्टैम्प किसी पुराने हो चुके तथ्य को पहचानने का सबसे तेज़ तरीका है। पुराणी एजेंट मेमोरी की छंटाई समीक्षा प्रक्रिया को अधिक गहराई से समझाती है।

जब सब कुछ context में लोड करने के बजाय retrieval बेहतर होता है

Memory tool का अस्तित्व just-in-time retrieval का समर्थन करने के लिए है। सब कुछ पहले से लोड करने के बजाय, agent जो सीखता है उसे record करता है और किसी file को केवल तब पढ़ता है जब किसी task को उसकी आवश्यकता होती है। यह गणना को बदल देता है, क्योंकि एक file read अपने tokens की लागत एक बार चुकाती है और फिर cached prefix के भीतर रहती है, जबकि स्थायी रूप से लोड किया गया block हर एक turn पर लागत बढ़ाता है।

ऊपर दिए गए दो charts से एक सरल नियम निकलता है। वह text जिसका उपयोग लगभग हर turn में होता है, उसे stable cached prefix में होना चाहिए। वह text जिसका उपयोग बीस में से एक turn में होता है, उसे view call के पीछे होना चाहिए। break-even बिंदु आपके replay count के साथ बदलता है, न कि Anthropic द्वारा लिए जाने वाले किसी शुल्क के साथ।

API पर आप platform को conversation को trim करने की अनुमति भी दे सकते हैं। जब conversation आपके द्वारा निर्धारित 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 में 100,000 input tokens का trigger और 3 tool uses को सुरक्षित रखने का प्रावधान है। इसे enable करने से पहले caching के साथ interaction को पढ़ें: content को clear करने से उस बिंदु पर cached prefix अमान्य हो जाता है, इसलिए अगली request पर आपको cache write की लागत चुकानी पड़ती है। clear_at_least इसी काम के लिए है। यह तब तक clear करने से रोकता है जब तक कि बचत write को उचित ठहराने के लिए पर्याप्त न हो जाए। response में context_management के अंतर्गत ठीक वही जानकारी मिलती है जो हुई है, साथ ही cleared_tool_uses और cleared_input_tokens भी दिए होते हैं, जिससे यह trade सैद्धांतिक होने के बजाय मापने योग्य बन जाता है। Claude Code में context window को manage करना कोडिंग session में भी इसी विचार को लागू करता है।

किसका अपना अलग लाइन आइटम होता है

Memory का अपना कोई शुल्क नहीं है, लेकिन कुछ फीचर्स का वास्तव में शुल्क लगता है, और यह जानना जरूरी है कि वे कौन से हैं। ये अगस्त 2026 तक प्रकाशित Claude API दरें हैं। कुछ ऑपरेशन्स पर बिल्कुल भी खर्च नहीं आता, लेकिन Claude API पर कोई फ्री टियर नहीं है, केवल साइनअप के समय एक छोटा क्रेडिट मिलता है, इसलिए नीचे दी गई हर चीज आपके पहले अनुरोध से ही वास्तविक खर्च है।

• Web search: प्रति 1,000 सर्च पर $10, साथ ही सर्च द्वारा कॉन्टेक्स्ट में डाली गई हर चीज की सामान्य टोकन लागत।
• Code execution: प्रति संगठन हर महीने 1,550 मुफ्त घंटे, उसके बाद प्रति कंटेनर $0.05 प्रति घंटा। जब इसे Web search या Web fetch के साथ उपयोग किया जाता है, तो यह मुफ्त है।
• Claude Managed Agents: सामान्य टोकन शुल्कों के अतिरिक्त, $0.08 प्रति सेशन-घंटे की दर से सेशन रनटाइम।
• Web fetch: कोई अतिरिक्त शुल्क नहीं, केवल फेच की गई सामग्री की टोकन लागत।

Memory इनमें से किसी भी लाइन में नहीं आती है। यह आपके इनपुट टोकन काउंट में दिखाई देती है, जहाँ आप इसे सटीक रूप से माप सकते हैं, और जहाँ प्रूनिंग (pruning) और कैशिंग (caching) इसे कम कर सकते हैं। यदि आप किसी ऐसे एजेंट का बजट बना रहे हैं जो वर्चुअल प्राइवेट सर्वर (VPS) पर बिना निगरानी के चलता है, तो VPS पर AI एजेंट के लिए लागत नियंत्रण लागू करने वाली अगली चीज है, क्योंकि बिना प्रूनिंग वाली बढ़ती हुई मेमोरी फाइल वाला एजेंट हर हफ्ते अधिक महंगा होता जाता है और इसकी कोई रिपोर्टिंग भी नहीं होती।

FAQ

क्या Claude के memory features के लिए अलग से कोई शुल्क है?

नहीं। Anthropic की मूल्य सूची में प्रति मिलियन input tokens, प्रति मिलियन output tokens और prompt caching multiples के लिए दरें दी गई हैं, जिसमें memory के लिए कोई अलग शुल्क नहीं है। Claude API पर memory tool client-side पर काम करता है, इसलिए फाइलें उस storage पर रहती हैं जिसके लिए आप पहले से भुगतान कर रहे हैं। Memory केवल input tokens को बढ़ाती है, जिनका बिल हर उस turn पर model की सामान्य input दर के अनुसार बनता है जिसमें वे शामिल होते हैं।

क्या memory को बंद करने से Claude सस्ता हो जाता है?

यह प्रत्येक request के token count को कम करता है, जिससे प्रत्येक request की लागत कम हो जाती है। क्या इससे कुल मिलाकर पैसे बचेंगे, यह इस बात पर निर्भर करता है कि आगे क्या होता है। यदि Claude को memory में पहले से मौजूद जानकारी को फिर से पाने के लिए तीन फाइलें पढ़नी पड़ें और आपसे दो सवाल पूछने पड़ें, तो उन tokens की लागत memory की लागत से अधिक होगी। अनुमान लगाने के बजाय इसे मापें: auto memory चालू करके एक session में /context चलाएं और एक session CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 के साथ शुरू करें, फिर एक ही कार्य पर खर्च किए गए कुल tokens की तुलना करें।

बिना कुछ बदले मेरा usage क्यों बढ़ गया?

इसका सबसे सामान्य कारण ब्रेक के बाद cache miss होना है। Cache entries डिफ़ॉल्ट रूप से 5 मिनट तक, या extended setting पर एक घंटे तक रहती हैं, इसलिए ब्रेक के बाद पहली request आपके पूरे prefix को base input दर पर फिर से process करती है और उसे दोबारा लिखती है। दूसरा सामान्य कारण prefix में बदलाव है: tool definition को बदलने से पूरा cache अमान्य हो जाता है, और system prompt को बदलने से system और message cache अमान्य हो जाते हैं। Subscription plan पर, जब /usage breakdown हाल के usage का 10 प्रतिशत या उससे अधिक होता है, तो यह उस व्यवहार को दर्शाता है।

क्या memory को system prompt में रखना चाहिए या tool call के पीछे?

इसे system prompt में तब रखें जब लगभग हर turn में इसकी आवश्यकता हो, क्योंकि तब यह cached prefix में रहता है और cache read दर पर खर्च होता है। इसे view call के पीछे तब रखें जब केवल कुछ कार्यों के लिए इसकी आवश्यकता हो, क्योंकि एक बार पढ़ी गई फाइल के tokens केवल एक बार खर्च होते हैं, न कि हर turn पर। निर्णय लेने के लिए महत्वपूर्ण संख्या आपका replay count है, और usage object आपको वह संख्या सीधे प्रदान करता है।

क्या memory features subscription usage limits के अंतर्गत आते हैं?

हाँ, अप्रत्यक्ष रूप से, क्योंकि subscription limits उन tokens द्वारा खर्च होती हैं जो प्रत्येक request में होते हैं। Anthropic का help documentation बताता है कि लंबी बातचीत जो automatic context management को trigger करती है, आपके usage limit का अधिक हिस्सा खर्च करती है। Memory प्रत्येक request को थोड़ा लंबा बना देती है, और एक लंबा session हर turn पर उस लंबाई को फिर से दोहराता है। Claude की usage limits वास्तव में कैसे काम करती हैं इस विषय पर जानकारी देता है कि क्या और कब reset होता है।