क्या 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 को कम करने से आपका उपयोग किसी छोटे प्लान की सीमा के भीतर आ जाता है, तो Max से Pro पर जाना एक सार्थक कदम है, और यह बदलाव उस अवधि के अंत में लागू होता है जिसके लिए आप पहले ही भुगतान कर चुके हैं। यदि आप Anthropic के अपने टियर्स के बजाय अलग-अलग प्रोवाइडर्स के बीच तुलना कर रहे हैं, तो वर्तमान कीमतों पर ChatGPT के साथ Claude के प्लान्स की तुलना से शुरुआत करना सही रहेगा।

Claude के प्रत्येक इंटरफेस पर "memory" का क्या अर्थ है

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

Claude API पर memory टूल। आप tools ऐरे में एक प्रविष्टि (entry) जोड़ते हैं और अपने कोड में फाइल ऑपरेशंस को लागू करते हैं।

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

अगस्त 2026 तक, यह टूल Claude 4 और बाद के मॉडल्स पर बिना किसी बीटा हेडर के Messages API पर सामान्य रूप से उपलब्ध है। यह क्लाइंट-साइड है: Claude view /memories जैसे ऑपरेशन के लिए अनुरोध करता है, आपका हैंडलर इसे आपके द्वारा नियंत्रित स्टोरेज पर चलाता है, और आप परिणाम को tool_result ब्लॉक में लौटाते हैं। Anthropic के पास फाइल कभी नहीं रहती, इसलिए कोई स्टोरेज शुल्क नहीं लगता। इसके बजाय, आप राउंड ट्रिप के लिए भुगतान करते हैं। टूल की परिभाषा हर अनुरोध में भेजी जाती है, और जो फाइल कंटेंट वापस आता है, वह उस बिंदु से बातचीत में बना रहता है।

Anthropic उस ओवरहेड के निश्चित हिस्से को प्रकाशित करता है। Claude Opus 5 पर auto के टूल विकल्प के साथ, टूल-यूज़ सिस्टम प्रॉम्प्ट 286 टोकन का है, जैसा कि अगस्त 2026 में प्रलेखित है। इसका भुगतान प्रति अनुरोध एक बार किया जाता है, जब भी कोई टूल मौजूद होता है, चाहे वह memory हो या कोई अन्य।

Claude Code. प्रत्येक सत्र (session) की शुरुआत में दो तंत्र लोड होते हैं। CLAUDE.md फाइलें आपके द्वारा लिखे गए निर्देशों को रखती हैं। ऑटो मेमोरी उन नोट्स को रखती है जिन्हें Claude स्वयं ~/.claude/projects/<project>/memory/ के तहत लिखता है। MEMORY.md की केवल पहली 200 लाइनें या 25KB लोड की जाती हैं, जो भी सीमा पहले पूरी हो जाए, और इसके बगल वाली टॉपिक फाइलें स्टार्टअप के बजाय मांग पर पढ़ी जाती हैं। स्टार्टअप पर लोड की गई हर चीज उस प्रीफिक्स का हिस्सा बन जाती है जिसे उस सत्र के हर बाद के अनुरोध में शामिल किया जाता है। Claude Code सत्रों के बीच memory को कैसे याद रखता है फाइल-दर-फाइल लोडिंग क्रम को कवर करता है।

वेब पर Claude. claude.ai पर, memory उन प्रविष्टियों का एक सेट है जिन्हें Claude आपके चैट करने के साथ लिखता और अपडेट करता है, जिसमें प्रत्येक प्रोजेक्ट के लिए एक अलग memory स्पेस होता है। Settings > Memory में वह सूची होती है जो स्टोर की गई है, और वहां मौजूद टॉगल Pause memory या Reset memory का विकल्प प्रदान करता है। इस इंटरफेस के लिए सब्सक्रिप्शन द्वारा बिलिंग की जाती है, इसलिए यहाँ 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 में उपयोग पृष्ठ आधिकारिक संख्या है।

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

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 घंटे की अवधि पर दो बार कैश रीड करने के बाद कैशिंग फायदेमंद हो जाती है। Prompt caching के लिए ब्रेक-ईवन पॉइंट वह गणना है जिसे आपको यह तय करने से पहले करना चाहिए कि मेमोरी कहाँ रखनी है।

ये गुणक रीप्ले काउंट को अंकगणित में बदल देते हैं। अगला ब्लॉक ऊपर दिए गए प्रकाशित गुणकों का अंकगणित है, न कि किसी लाइव वर्कलोड का मापन। यह 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 पर आधारित होगा, तो इसकी प्रकाशित प्रति-मिलियन दरों और यह जिस कार्य के लिए उपयुक्त है से शुरुआत करें। यदि प्रदाता अभी भी केवल मॉडल के बजाय एक खुला प्रश्न है, तो Claude API और ChatGPT पर समान कार्यों की लागत यह दिखाती है कि वह गुणा अलग-अलग कहाँ पहुँचता है, और एक मेमोरी-हैवी एजेंट इसके इनपुट पक्ष पर बहुत अधिक निर्भर करता है।

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

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

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

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

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

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

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

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

एक दूसरी, अधिक शांत विफलता भी है। प्रत्येक model का एक न्यूनतम cacheable प्रीफिक्स होता है: अगस्त 2026 में प्रकाशित आंकड़ों के अनुसार, Claude Opus 5 पर 512 tokens, Claude Sonnet 5 पर 1,024, और Claude Haiku 4.5 पर 4,096। Anthropic का documentation स्पष्ट रूप से बताता है कि इससे कम होने पर क्या होता है: "इस संख्या से कम tokens को कैश करने के किसी भी अनुरोध को बिना कैशिंग के प्रोसेस किया जाएगा, और कोई error वापस नहीं आएगा।" इसलिए, 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 एजेंट के लिए लागत नियंत्रण अगला कदम है जिसे लागू करना चाहिए, क्योंकि बिना pruning वाली बढ़ती हुई memory फाइल वाला एजेंट हर हफ्ते अधिक महंगा होता जाता है और इसकी कोई रिपोर्टिंग भी नहीं होती है।

FAQ

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

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

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

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

जब मैंने कुछ भी नहीं बदला तो मेरा usage क्यों बढ़ गया?

सबसे आम कारण ब्रेक के बाद cache miss होना है। cache प्रविष्टियां डिफ़ॉल्ट रूप से 5 मिनट तक, या extended सेटिंग पर एक घंटे तक रहती हैं, इसलिए ब्रेक के बाद पहला अनुरोध आपके पूरे प्रीफिक्स को बेस इनपुट दर पर फिर से प्रोसेस करता है और उसे दोबारा लिखता है। दूसरा आम कारण प्रीफिक्स में बदलाव है: टूल परिभाषा को बदलने से पूरा cache अमान्य हो जाता है, और सिस्टम प्रॉम्प्ट को बदलने से सिस्टम और मैसेज cache अमान्य हो जाते हैं। सब्सक्रिप्शन प्लान पर, /usage ब्रेकडाउन उस व्यवहार का नाम बताता है जब यह हाल के उपयोग के 10 प्रतिशत या उससे अधिक के लिए जिम्मेदार होता है।

क्या memory को सिस्टम प्रॉम्प्ट में होना चाहिए या टूल कॉल के पीछे?

इसे सिस्टम प्रॉम्प्ट में तब रखें जब लगभग हर टर्न इसका उपयोग करता हो, क्योंकि तब यह cached प्रीफिक्स में रहता है और cache रीड दर पर खर्च होता है। इसे view कॉल के पीछे तब रखें जब केवल कुछ कार्यों को इसकी आवश्यकता हो, क्योंकि एक फाइल जिसे एक बार पढ़ा जाता है, उसके टोकन एक बार ही खर्च होते हैं, न कि हर टर्न पर। निर्णय लेने वाली संख्या आपका रिप्ले काउंट है, और usage ऑब्जेक्ट आपको वह संख्या सीधे देता है।

क्या memory फीचर्स सब्सक्रिप्शन usage लिमिट में गिने जाते हैं?

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