Claude memory features ব্যবহার করতে কি অতিরিক্ত খরচ হয়?

Claude-এর memory features-এর জন্য কি অতিরিক্ত খরচ হয়?

Claude-এর memory features-এর নিজস্ব কোনো মূল্য নেই। Anthropic-এর প্রকাশিত rate প্রতি million input token এবং প্রতি million output token অনুযায়ী নির্ধারিত, prompt caching-এর জন্য অতিরিক্ত rate-সহ। এগুলোর কোনোটি memory token নামে পরিচিত নয়। Claude API (application programming interface)-তে memory সংরক্ষণের জন্য আলাদা খরচ নেই, কারণ memory tool client-side এবং file আপনার মালিকানাধীন storage-এ থাকে।

তবু memory আপনার bill-এ প্রভাব ফেলে, কারণ মনে রাখা কোনো তথ্য Claude যে request পড়ে তার ভেতরে থাকলেই শুধু উত্তরে পরিবর্তন আনে। অর্থাৎ মনে রাখা তথ্য আবার পাঠাতে হয়। সেই text input token হিসেবে যায় এবং model-এর সাধারণ input rate অনুযায়ী charged হয়। খরচ নির্ধারণ করে 2টি বিষয়: প্রতিটি turn-এ আপনি কত token-এর remembered text আবার পাঠান, এবং সেই পুনরায় পাঠানো text prompt cache থেকে সরবরাহ করা যায় কি না।

Pro বা Max subscription-এ token অনুযায়ী আলাদা bill করা হয় না। তাই memory আপনার অর্থের বদলে usage allowance ব্যবহার করে। নিচের mechanism একই থাকে। শুধু unit পরিবর্তিত হয়। এই allowance সীমিত। তাই প্রতিটি turn-এ কতটা memory বহন করা উচিত তা নির্ধারণের আগে Claude Pro-এর খরচ কত এবং কোন পর্যায়ে এর limits আপনাকে থামিয়ে দেয় জেনে নেওয়া ভালো। Claude Enterprise-এর হিসাব আবার আলাদা। সেখানে seat price-এর পাশাপাশি প্রতিটি token-এর জন্য API rate অনুযায়ী হিসাব হয়। ফলে memory block অতিরিক্ত বড় হলে allowance নয়, সরাসরি অর্থ খরচ হয়। Memory prune করার পরে আপনার usage যদি ছোট plan-এর ceiling-এর মধ্যে স্বাচ্ছন্দ্যে থাকে, তাহলে Max থেকে Pro-তে নামা পরবর্তী বিবেচনার বিষয় হতে পারে। আপনি যে period-এর জন্য ইতিমধ্যে অর্থ দিয়েছেন, সেই period শেষ হলে পরিবর্তনটি কার্যকর হয়। আপনি যদি Anthropic-এর নিজস্ব tier-এর বদলে বিভিন্ন provider-এর তুলনা করেন, তাহলে বর্তমান মূল্যে ChatGPT-এর পাশে Claude-এর plans তুলনা করা দিয়ে শুরু করুন।

প্রতিটি Claude surface-এ “memory” বলতে যা বোঝায়

তিনটি পৃথক product এই শব্দটি ব্যবহার করে। এগুলো একসঙ্গে মিশে যাওয়াই এই প্রশ্নটি বিভ্রান্তিকর মনে হওয়ার প্রধান কারণ।

Claude API-এর memory tool। আপনি tools array-তে একটি entry যোগ করেন এবং file operation-গুলো আপনার নিজের code-এ বাস্তবায়ন করেন।

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

August 2026 অনুযায়ী, Claude 4 এবং পরবর্তী model-গুলোর Messages API-তে এই tool সাধারণভাবে available এবং এর জন্য কোনো beta header লাগে না। এটি client-side: Claude view /memories-এর মতো কোনো operation-এর অনুরোধ করে, আপনার handler আপনার নিয়ন্ত্রণাধীন storage-এ operation চালায়, এবং আপনি tool_result block-এ ফলাফল ফেরত দেন। Anthropic কখনো file সংরক্ষণ করে না, তাই কোনো storage charge আপনাকে বহন করতে হয় না। এর পরিবর্তে round trip-এর জন্য খরচ হয়। Tool definition প্রতিটি request-এ পাঠানো হয়, এবং যে file content ফেরত আসে, তা সেই মুহূর্ত থেকে conversation-এর অংশ হয়ে থাকে।

Anthropic এই overhead-এর স্থির অংশ প্রকাশ করে। August 2026-এ প্রকাশিত documentation অনুযায়ী, Claude Opus 5-এ auto tool choice ব্যবহার করলে tool-use system prompt 286 tokens-এর হয়। কোনো tool উপস্থিত থাকলেই, memory হোক বা অন্য কিছু, প্রতিটি request-এ এই খরচ একবার দিতে হয়।

Claude Code। প্রতিটি session শুরু হওয়ার সময় দুটি mechanism content load করে। আপনি যে instruction লেখেন, সেগুলো CLAUDE.md file-এ থাকে। Claude নিজের জন্য যে note লেখে, সেগুলো ~/.claude/projects/<project>/memory/-এর অধীনে auto memory-তে থাকে। MEMORY.md-এর প্রথম 200 lines বা 25KB load হয়, যেটি আগে সীমায় পৌঁছায়। এর পাশের topic file-গুলো startup-এর সময় নয়, প্রয়োজন হলে পড়া হয়। Startup-এ load হওয়া সবকিছু সেই session-এর পরবর্তী প্রতিটি request-এ বহন করা prefix-এর অংশ হয়ে যায়। Claude Code কীভাবে session-গুলোর মধ্যে memory পুনরায় ব্যবহার করে file অনুযায়ী loading order ব্যাখ্যা করে।

ওয়েবে Claude। claude.ai-তে memory হলো এমন entry-গুলোর একটি সেট, যেগুলো আপনি chat করার সময় Claude লেখে এবং update করে। প্রতিটি project-এর জন্য আলাদা memory space থাকে। Settings > Memory-তে সংরক্ষিত বিষয়গুলোর তালিকা দেখা যায়। সেখানে থাকা toggle থেকে Pause memory বা Reset memory বেছে নেওয়া যায়। এই surface subscription-এর ভিত্তিতে billed হয়, তাই এখানে memory usage limit ব্যবহার করে।

কেন স্মরণ করা টেক্সট input token হিসেবে বিল করা হয়

Messages API stateless। এটি কলগুলোর মধ্যে কিছু সংরক্ষণ করে না। তাই প্রতিটি 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-এ শুধু সেই token-গুলো গণনা করা হয়, যেগুলো cache থেকে পড়া হয়নি এবং cache তৈরি করতেও ব্যবহৃত হয়নি। বাস্তবে এর অর্থ হলো, শেষ cache breakpoint-এর পরের token-গুলো। Request-এর মোট input হলো cache_read_input_tokens + cache_creation_input_tokens + input_tokens। Claude তিন turn আগে যে memory file খুলেছিল, সেটি এরপরের প্রতিটি turn-এ ওই মোট input-এর অংশ থাকে। Cached prefix কার্যকর থাকলে এটি cache_read_input_tokens-এর অধীনে পড়ে। Cached prefix কার্যকর না থাকলে এটি input_tokens-এর অধীনে পড়ে। একই text, কিন্তু দুটি সম্পূর্ণ ভিন্ন মূল্য। Input ও output token-এর মূল্য আলাদা, এবং memory সবসময় শুধু input দিকেই গণনা হয়।

নিজের ব্যবহারে এই সংখ্যাগুলো কোথায় দেখবেন

কোনো blog post থেকে, এমনকি এই লেখাটি থেকেও, কোনো পরিসংখ্যান গ্রহণ করবেন না। নিজের 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-এ পেস্ট করে একবার চালান এবং memory text ছাড়া আরেকবার চালান। দুই ফলাফলের পার্থক্যই প্রতিটি turn-এ ওই memory-এর খরচ। দুটি সতর্কতা প্রযোজ্য। এই count একটি আনুমানিক হিসাব, এবং Anthropic-এর নিজস্ব system optimization-এর জন্য যোগ করা অতিরিক্ত token-এর জন্য আপনাকে বিল করা হয় না। আপনি যে model বাস্তবে চালাবেন, সেই model অনুযায়ীও গণনা করুন, কারণ Claude 4.7 এবং পরবর্তী সংস্করণে নতুন tokenizer ব্যবহৃত হয়, যা একই text-এর জন্য প্রায় 30 শতাংশ বেশি token তৈরি করে।

Claude Code-এর ভিতরে কোনো curl ছাড়াই একই প্রশ্নের উত্তর পাওয়া যায়।

• /context বর্তমানে কী loaded আছে তা দেখায়, memory file-সহ। ফলে কিছু type করার আগেই window-এর কতটা অংশ memory ব্যবহার করছে তা দেখতে পারেন।
• /memory আপনার CLAUDE.md file-গুলোর তালিকা দেখায় এবং auto memory folder খোলে।
• /usage session-এর মোট হিসাব print করে, যার মধ্যে cache read এবং cache write-ও থাকে।
• 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 figure হলো conversation এবং memory-সহ সম্পূর্ণ content, যা প্রতিটি turn-এ cache rate-এ আবার পাঠানো হচ্ছে। 1.2k input figure-টি শুধু নতুন অংশের জন্য। Claude Code list price থেকে স্থানীয়ভাবে এই dollar amount হিসাব করে। তাই এতে আপনার পাওয়া কোনো discount ধরা হয় না এবং এটি আপনার invoice-এর সঙ্গে ভিন্ন হতে পারে। Claude Console-এর Usage page-ই authoritative number।

এরপর সরাসরি comparison চালান। দুটি নতুন session-এ একই opening question জিজ্ঞাসা করুন। একটিতে স্বাভাবিকভাবে চালান এবং অন্যটিতে auto memory বন্ধ রাখুন।

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

প্রতিটিতে /context চালান এবং memory files entry তুলনা করুন। কোনো কাজ শুরু হওয়ার আগেই প্রতিটি session-এর শুরুতে আপনার accumulated memory-এর খরচ কত, সেই ব্যবধান তা দেখায়। Claude Code-এর token usage কোথায় যায় তার পূর্ণ বিশ্লেষণ এই দুটি সংখ্যার পাশাপাশি পড়া উপযোগী।

প্রতি এক মিলিয়ন token-এ memory replay করার খরচ কত?

Prompt caching-এর কারণে একই memory block এক turn-এ অন্য turn-এর তুলনায় দশ গুণ বেশি খরচ হতে পারে। Anthropic প্রতিটি model-এর base input price-এর গুণিতক হিসেবে cache rate প্রকাশ করে। তাই dollar price পরিবর্তিত হলেও এই সম্পর্ক একই থাকে।

[
  {
    "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 মিনিটের lifetime-সহ একটি entry লিখতে base price-এর 1.25 গুণ এবং 1 ঘণ্টার lifetime-সহ entry লিখতে base price-এর 2 গুণ খরচ হয়। Anthropic break-even বিষয়টি স্পষ্টভাবে জানায়: 5 মিনিটের duration-এ একবার cache read হলেই caching সাশ্রয়ী হয়, আর 1 ঘণ্টার duration-এ দুইবার cache read-এর পর সাশ্রয়ী হয়। Prompt caching-এর break-even point হিসাব করে দেখুন, তারপর memory কোথায় রাখবেন তা নির্ধারণ করুন।

এই গুণিতকগুলো replay count-কে সরাসরি arithmetic-এ রূপ দেয়। পরের block-টি উপরে প্রকাশিত গুণিতক থেকে করা arithmetic; এটি কোনো live workload-এর measurement নয়। এতে 100 turn-এর একটি session-এ memory block-এর খরচ তিনভাবে দেখানো হয়েছে। হিসাবটি plain base input rate-এ charged token-এর equivalent number হিসেবে প্রকাশ করা হয়েছে।

[
  {
    "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 turn-এই cache miss করে, তাহলে এর bill হবে 400,000 base-rate token-এর সমান। একই block-এর ক্ষেত্রে একটি 5 মিনিটের cache write এবং 99টি cache read থাকলে bill হবে 44,600 token-এর সমান। Block-টির আকার এক-চতুর্থাংশে কমিয়ে caching চালু রাখলে bill হবে 11,150 token-এর সমান। এই 3টি row জুড়ে feature-এ কোনো পরিবর্তন হয়নি। শুধু replay behaviour পরিবর্তিত হয়েছে। এগুলো এখনও অর্থের পরিমাণ নয়, token count। token count-কে মাসিক bill-এর অর্থমূল্যে রূপান্তর করা মানে আপনার model-এর প্রতি এক মিলিয়ন token-এর rate দিয়ে একবার গুণ করা। এই rate আপনি যে model চালান সেটি নির্ধারণ করে। তাই agent যদি Claude Fable 5-এ চলবে, তাহলে প্রকাশিত প্রতি এক মিলিয়ন token-এর rate এবং উপযোগী কাজগুলো দিয়ে হিসাব শুরু করুন। Provider এখনও নির্ধারিত না থাকলে, শুধু model নয়, Claude-এর API এবং ChatGPT-তে একই কাজের খরচের তুলনা দেখুন। এতে বোঝা যায় গুণের ফল কোথায় কীভাবে আলাদা হয়। Memory-heavy agent-এর ক্ষেত্রে input side-এই এর বড় প্রভাব পড়ে।

দ্বিতীয় row ধরে নেয় যে পরের 99টি request আসার সময় প্রতিবারই cache entry সক্রিয় থাকে। বাস্তব bill-এ বেশিরভাগ ভুল হিসাবের কারণ এই assumption।

বিরতির পরে একই প্রশ্নের খরচ বেশি হয় কেন?

একটি cache entry-এর নির্দিষ্ট lifetime থাকে, এবং যে request এটি লেখে বা পড়ে, সেই সময় থেকে clock গণনা শুরু হয়। ডিফল্ট হলো 5 মিনিট। 1 hour option-এর খরচ উপরে দেখানো 2x write। Claude Code-এ subscription ব্যবহার করলে lifetime 1 hour থাকে। Usage credits ব্যবহার শুরু করলে এটি 5 মিনিটে নেমে আসে। API key বা cloud provider ব্যবহার করলে ডিফল্ট lifetime 5 মিনিট। ENABLE_PROMPT_CACHING_1H=1 সেট করলে usage credits ব্যবহার করার সময়ও 1 hour lifetime বজায় থাকে।

তাই দুপুরের খাবারের বিরতির সময় খোলা রাখা session-এ এক লাইনের প্রশ্নও ব্যয়বহুল হতে পারে। আপনি অনুপস্থিত থাকাকালে cache entry-এর মেয়াদ শেষ হয়ে যায়। ফলে memory-সহ পুরো prefix আবার base input rate-এ process করা হয় এবং আবার cache-এ লেখা হয়। বিরতির দৈর্ঘ্যই সেই খরচ নির্ধারণ করে।

এটি শুধু অনুমান না করে নিশ্চিত করতে পারেন। Pro, Max, Team বা Enterprise plan-এ /usage breakdown সাম্প্রতিক usage-এর 10 percent বা তার বেশি ব্যবহারের জন্য দায়ী আচরণগুলো চিহ্নিত করে। সেখানে long context এবং cache miss—দুটিই নামসহ দেখা যায়। API-তে কোনো quiet period-এর পর প্রথম request-এ cache_creation_input_tokens আবার আপনার prefix-এর সম্পূর্ণ আকারে বেড়ে যায় কি না দেখুন।

ক্যাশকে নীরবে অকার্যকর করে যা

ক্যাশ করা prefix-এর ক্রম হলো: tools, তারপর system, তারপর messages। কোনো স্তরে পরিবর্তন হলে সেই স্তর এবং তার পরের সবকিছু invalid হয়ে যায়। কোনো tool definition সম্পাদনা করলে সম্পূর্ণ cache বাতিল হয়ে যায়। system prompt সম্পাদনা করলে system এবং message cache বাতিল হয়ে যায়।

যারা system prompt-এ memory রাখেন এবং agent শেখার সঙ্গে সঙ্গে সেটি পুনর্লিখেন, তাদের জন্য এটাই মূল ফাঁদ। প্রতিটি rewrite তার পরের সবকিছুর cached copy বাতিল করে। ফলে পরবর্তী request-এ আবার সম্পূর্ণ write-এর খরচ হয়। স্থিতিশীল বিষয়বস্তু শুরুতে রাখুন এবং সেটি অপরিবর্তিত রাখুন। পরিবর্তনশীল বিষয়বস্তু message list-এর শেষের দিকে রাখুন, যাতে তা invalid হওয়ার খরচ কম হয়।

আরও একটি নীরব সমস্যা আছে। প্রতিটি model-এর minimum cacheable prefix রয়েছে: Claude Opus 5-এ 512 tokens, Claude Sonnet 5-এ 1,024, এবং Claude Haiku 4.5-এ 4,096; এই তথ্য August 2026-এ প্রকাশিত হয়েছে। এর নিচে কী ঘটে, Anthropic-এর documentation-এ তা স্পষ্টভাবে বলা আছে: "এই সংখ্যার চেয়ে কম token cache করার সব request caching ছাড়াই process করা হবে, এবং কোনো error ফেরত দেওয়া হবে না।" তাই cache_control দিয়ে চিহ্নিত একটি ছোট memory file একেবারেই কোনো কাজ করে না, তবে কোনো error-ও দেখা যায় না। আপনি যে লক্ষণটি দেখতে পারেন তা হলো, prompt-এ breakpoint স্পষ্টভাবে থাকা সত্ত্বেও cache_creation_input_tokens 0-তেই থেকে যাচ্ছে।

আর প্রয়োজন নেই এমন memory বাদ দিন

যে memory-এর প্রতিটি লাইন বর্তমান থাকে, সেই লাইন বহন করা প্রতিটি turn-এ token খরচ করে। তাই প্রতিটি লাইনের ক্ষেত্রে দেখুন, সেটি সম্প্রতি কোনো উত্তরে পরিবর্তন এনেছে কি না। Claude Code এই সীমাগুলো স্পষ্ট করে। CLAUDE.md 200 লাইনের মধ্যে রাখার লক্ষ্য নির্ধারণ করুন, কারণ বড় file বেশি context ব্যবহার করে এবং Claude-এর পক্ষে নির্দেশনা নির্ভরযোগ্যভাবে অনুসরণ করা কঠিন করে। লোড করার সময় MEMORY.md-এর সীমা প্রথম 200 লাইন বা 25KB পর্যন্ত। এই সীমার পরের সবকিছু পরবর্তী session শুরু হলে বাদ পড়ে। তাই অতিরিক্ত বড় index token খরচ করে, কিন্তু কোনো শিক্ষা দেয় না।

দুটি অভ্যাস এটি ছোট রাখতে সাহায্য করে। বিস্তারিত তথ্য index থেকে topic file-এ সরিয়ে নিন। Claude startup-এর সময় নয়, প্রয়োজন অনুযায়ী এসব file পড়ে। Workflow নির্দেশনা CLAUDE.md থেকে skills-এ সরিয়ে নিন। এগুলো শুধু invoke করা হলে load হয়। যেসব memory file ইতিমধ্যে frontmatter দিয়ে শুরু হয়, সেগুলোর write time Claude Code একটি modified field-এ ISO 8601 timestamp হিসেবে সংরক্ষণ করে, version 2.1.214 বা পরবর্তী সংস্করণে। পুরোনো হয়ে যাওয়া তথ্য শনাক্ত করার দ্রুততম উপায় হলো এই timestamp দেখা। পুরোনো agent memory ছাঁটাই review process আরও বিস্তারিতভাবে ব্যাখ্যা করে।

সবকিছু context-এ লোড করার চেয়ে কখন retrieval বেশি কার্যকর

Memory tool-টি just-in-time retrieval সমর্থন করার জন্য রয়েছে। শুরুতেই সবকিছু লোড করার বদলে agent যা শেখে তা নথিবদ্ধ করে এবং কোনো কাজের জন্য প্রয়োজন হলেই file পড়ে। এতে হিসাব বদলে যায়, কারণ file পড়ার খরচ একবার tokens হিসেবে দিতে হয় এবং এরপর সেটি cached prefix-এর মধ্যে থাকে। অন্যদিকে, স্থায়ীভাবে লোড করা block-এর জন্য প্রতিটি turn-এ খরচ হয়।

উপরের দুটি chart থেকে একটি সহজ নিয়ম পাওয়া যায়। যে text প্রায় প্রতিটি turn-এ ব্যবহৃত হয়, সেটি stable cached prefix-এ রাখা উচিত। যে text প্রতি বিশটি turn-এর মধ্যে একবার ব্যবহৃত হয়, সেটি একটি view call-এর পেছনে রাখা উচিত। Break-even আপনার replay count-এর সঙ্গে বদলায়, Anthropic কী charge করে তার সঙ্গে নয়।

API-তে platform-কে conversation trim করতেও দিতে পারেন। Context editing conversation আপনার নির্ধারিত threshold অতিক্রম করলে পুরনো tool result মুছে দেয়।

{
  "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 হিসেবে trigger হলো 100,000 input tokens এবং 3টি tool use রাখা হয়। এটি enable করার আগে caching-এর সঙ্গে interaction পড়ুন: content clear করলে clear হওয়ার বিন্দুতে cached prefix invalid হয়ে যায়। ফলে পরের request-এ cache write-এর জন্য খরচ হয়। clear_at_least এই কাজের জন্যই ব্যবহৃত হয়। Cache clear করার আগে এটি অপেক্ষা করে, যতক্ষণ না সাশ্রয় cache write-এর খরচ ন্যায্যতা দেওয়ার মতো বড় হয়। context_management-এর অধীনে response-এ ঠিক কী ঘটেছে তা জানানো হয়, এবং সেখানে cleared_tool_uses ও cleared_input_tokens থাকে। ফলে এই trade পরিমাপ করা যায়, শুধু তাত্ত্বিক থাকে না। Claude Code-এ context window পরিচালনা একই ধারণা coding session-এ প্রয়োগ করে।

কোন বিষয়ের আলাদা খরচের হিসাব আছে

Memory-এর জন্য আলাদা কোনো charge নেই। তবে কিছু feature-এর জন্য সত্যিই আলাদা charge আছে, এবং কোনগুলোর আছে তা জানা গুরুত্বপূর্ণ। এগুলো August 2026 অনুযায়ী প্রকাশিত Claude API rate। কয়েকটি operation-এর জন্য কোনো খরচই নেই। তবে Claude API-তে কোনো free tier নেই, signup-এর সময় শুধু অল্প credit পাওয়া যায়। তাই নিচের প্রতিটি খরচ আপনার প্রথম request থেকেই বাস্তব ব্যয়।

• Web search: প্রতি 1,000 search-এর জন্য $10, এর সঙ্গে search context-এ যোগ করা সব content-এর সাধারণ token cost।
• Code execution: প্রতি organization-এ প্রতি মাসে 1,550 free hour, এরপর প্রতি container-hour $0.05। Web search বা web fetch-এর সঙ্গে ব্যবহার করলে এটি free।
• Claude Managed Agents: সাধারণ token charge-এর অতিরিক্ত, প্রতি session-hour $0.08 হারে session runtime।
• Web fetch: অতিরিক্ত কোনো charge নেই; শুধু fetch করা content-এর token cost প্রযোজ্য।

এই তালিকার কোনো line-এ Memory নেই। এটি আপনার input token count-এর মধ্যে গণনা হয়। সেখানেই এর পরিমাণ মাপা যায়। pruning এবং caching ব্যবহার করে সেখানেই খরচ কমানো যায়। আপনি যদি একটি virtual private server (VPS)-এ unattended agent চালানোর বাজেট নির্ধারণ করেন, তাহলে VPS-এ AI agent-এর cost control পরবর্তী পদক্ষেপ হওয়া উচিত। কারণ memory file বড় হতে থাকলে এবং pruning না থাকলে, কোনো monitoring ছাড়াই agent-এর খরচ প্রতি সপ্তাহে বাড়তে থাকবে।

FAQ

Claude-এর memory feature-এর জন্য কি আলাদা charge আছে?

না। Anthropic-এর price list-এ প্রতি million input token, প্রতি million output token এবং prompt caching-এর multiple অনুযায়ী rate দেওয়া আছে; memory-এর জন্য আলাদা কোনো line নেই। Claude API-তে memory tool client-side, তাই file-গুলো আপনার আগেই পরিশোধ করা storage-এ থাকে। Memory যে অতিরিক্ত খরচ যোগ করে, তা হলো input token। যে প্রতিটি turn-এ memory বহন করা হয়, সেখানে এই token model-এর স্বাভাবিক input rate অনুযায়ী bill হয়।

Memory বন্ধ করলে কি Claude সস্তা হয়?

এতে প্রতিটি request-এর token count কমে, তাই প্রতিটি request-এর খরচও কমে। তবে মোট খরচ কমবে কি না, তা পরবর্তী কাজের ওপর নির্ভর করে। Memory-তে থাকা তথ্য পুনর্গঠন করতে Claude-কে যদি তিনটি file আবার পড়তে হয় এবং আপনাকে দুটি প্রশ্ন করতে হয়, তাহলে সেই token-এর খরচ memory-এর খরচের চেয়ে বেশি হতে পারে। অনুমান না করে পরিমাপ করুন: auto memory চালু থাকা একটি session-এ এবং CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 দিয়ে শুরু করা একটি session-এ /context চালান। এরপর একই কাজের জন্য ব্যবহৃত মোট token তুলনা করুন।

আমি কিছু পরিবর্তন না করলেও usage কেন বেড়ে গেল?

সবচেয়ে সাধারণ কারণ হলো বিরতির পরে cache miss হওয়া। Cache entry ডিফল্টভাবে 5 মিনিট, অথবা extended setting-এ এক ঘণ্টা থাকে। তাই বিরতির পরের প্রথম 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 সেই আচরণের নাম দেখায়।

Memory কি system prompt-এ রাখা উচিত, নাকি tool call-এর মাধ্যমে ব্যবহার করা উচিত?

প্রায় প্রতিটি turn-এ ব্যবহার হলে memory system prompt-এ রাখুন। এতে এটি cached prefix-এর অংশ থাকে এবং cache read rate অনুযায়ী খরচ হয়। কেবল কিছু task-এ প্রয়োজন হলে memory-কে view call-এর পেছনে রাখুন। কারণ একবার পড়া একটি file-এর token একবারই খরচ হয়, প্রতিটি turn-এ নয়। সিদ্ধান্ত নেওয়ার জন্য গুরুত্বপূর্ণ সংখ্যা হলো replay count। usage object সরাসরি এই সংখ্যা দেয়।

Memory feature কি subscription usage limit-এর মধ্যে গণনা হয়?

হ্যাঁ, পরোক্ষভাবে। কারণ প্রতিটি request-এ বহন করা token-এর মাধ্যমে subscription limit খরচ হয়। Anthropic-এর help documentation-এ বলা হয়েছে, automatic context management সক্রিয় করে এমন দীর্ঘ conversation আপনার usage limit-এর বেশি অংশ ব্যবহার করে। Memory প্রতিটি request সামান্য দীর্ঘ করে। দীর্ঘ session-এ প্রতিটি turn-এ সেই দৈর্ঘ্য আবার বহন করা হয়। Claude-এর usage limit বাস্তবে কীভাবে কাজ করে কোনটি কখন reset হয়, তা ব্যাখ্যা করে।