Claude-এর memory feature কি অতিরিক্ত খরচের?

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

Claude-এর memory feature-এর জন্য আলাদা কোনো মূল্য নেই। Anthropic প্রকাশিত rate input-এর প্রতি million token এবং output-এর প্রতি million 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 অনুযায়ী charge হয়। খরচ কত হবে, তা 2টি বিষয় নির্ধারণ করে: প্রতিটি turn-এ মনে রাখা text-এর কত token আবার পাঠানো হচ্ছে এবং সেই পুনরায় পাঠানো text prompt cache থেকে দেওয়া যাচ্ছে কি না।

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

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

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

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

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

August 2026 অনুযায়ী, এই tool Messages API-তে কোনো beta header ছাড়াই সাধারণভাবে available। এটি Claude 4 এবং পরবর্তী model-এ কাজ করে। এটি 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। Memory হোক বা অন্য কোনো tool, কোনো tool উপস্থিত থাকলে প্রতিটি request-এ এই খরচ একবার হয়।

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

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

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

Messages API stateless। এটি call-এর মধ্যে কিছু সংরক্ষণ করে না। তাই প্রতিটি 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-এ এই মোটের অংশ থাকে। Cached prefix কার্যকর থাকলে সেটি cache_read_input_tokens-এর অধীনে পড়ে, আর cached prefix কার্যকর না থাকলে input_tokens-এর অধীনে পড়ে। একই text, কিন্তু দুই ধরনের দামে বিল হয়। Input ও output token-এর দাম আলাদা, এবং 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 text system field-এ paste করে একবার চালান এবং memory ছাড়া একবার চালান। দুই ফলের পার্থক্য হলো প্রতিটি turn-এ ওই memory-এর জন্য আপনার খরচ হওয়া token। এখানে দুটি বিষয় মনে রাখুন। এই count একটি estimate, এবং Anthropic-এর নিজস্ব system optimization-এর জন্য যোগ করা অতিরিক্ত token আপনার ওপর bill করা হয় না। এছাড়া আপনি যে model সত্যিই চালাবেন, সেই model অনুযায়ী count করুন, কারণ Claude 4.7 এবং পরবর্তী version-গুলো নতুন tokenizer ব্যবহার করে, যা একই text-এর জন্য প্রায় 30 percent বেশি token তৈরি করে।

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

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

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

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

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

প্রতি মিলিয়ন টোকেনে memory পুনরায় পাঠানোর খরচ কত?

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-এর খরচ 0.1 গুণ base input price। 5 minute lifetime-সহ entry লিখতে base-এর 1.25 গুণ এবং 1 hour lifetime-সহ entry লিখতে base-এর 2 গুণ খরচ হয়। Anthropic break-even বিষয়টি স্পষ্টভাবে জানায়: 5 minute duration-এ একটি cache read-এর পর এবং 1 hour duration-এ দুটি cache read-এর পর caching সাশ্রয়ী হয়। 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-এর সমতুল্য সংখ্যা হিসেবে প্রকাশ করা হয়েছে।

[
  {
    "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 করলে এর billing হবে 400,000 base-rate token-এর সমান। একই block-এর জন্য একটি 5 minute cache write এবং 99টি cache read থাকলে billing হবে 44,600 token-এর সমান। এটিকে আকারের এক-চতুর্থাংশে prune করে caching চালু রাখলে billing হবে 11,150 token-এর সমান। এই 3টি row-তে feature-এ কোনো পরিবর্তন হয়নি। শুধু replay behaviour পরিবর্তিত হয়েছে। এগুলো এখনও money নয়, token count। token count-কে আপনার monthly bill-এর পরিমাণে রূপান্তর করা মানে আপনার model-এর প্রতি-মিলিয়ন rate দিয়ে একবার গুণ করা। সেই rate আপনি যে model চালান সেটি নির্ধারণ করে। তাই agent যদি Claude Fable 5-এ চলে, এর প্রকাশিত প্রতি-মিলিয়ন rate এবং যে কাজের জন্য এটি উপযুক্ত থেকে হিসাব শুরু করুন।

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

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

একটি cache entry-এর নির্দিষ্ট lifetime থাকে। যে request এটি লেখে বা পড়ে, সেই request-এর সময় থেকে clock গণনা শুরু হয়। ডিফল্ট lifetime হলো 5 minutes। 1 hour option-এর খরচ উপরে দেখানো 2x write rate অনুযায়ী নির্ধারিত হয়। Claude Code-এ subscription ব্যবহার করলে lifetime হলো one hour। Usage credits ব্যবহার শুরু করলে এটি কমে five minutes হয়। API key বা cloud provider ব্যবহার করলে ডিফল্ট lifetime হলো five minutes। ENABLE_PROMPT_CACHING_1H=1 সেট করলে usage credits ব্যবহার করার সময়ও one 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-তে কোনো নীরব সময়ের পরে প্রথম 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-এর খরচ হয়। স্থিতিশীল উপাদান শুরুতে রাখুন এবং সেগুলো অপরিবর্তিত রাখুন। পরিবর্তনশীল উপাদান messages তালিকার শেষের দিকে রাখুন, যাতে সেগুলো invalid হলে খরচ কম হয়।

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

আর যেসব memory আর প্রয়োজনীয় নয়, সেগুলো বাদ দিন

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

দুটি অভ্যাস file-টি ছোট রাখে। index থেকে বিস্তারিত তথ্য সরিয়ে topic file-এ রাখুন। Claude startup-এর সময় না পড়ে প্রয়োজন অনুযায়ী এগুলো পড়বে। 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-এ load করার চেয়ে retrieval বেশি কার্যকর

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

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

API-তে platform-কে conversation trim করতেও দিতে পারেন। আপনার নির্ধারিত threshold অতিক্রম করলে Context editing পুরনো 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}
    }
  ]
}

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

কোন বৈশিষ্ট্যের জন্য আলাদা খরচের লাইন আছে

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

• Web search: প্রতি 1,000 search-এর জন্য $10, এর সঙ্গে search context-এ যোগ করা সবকিছুর সাধারণ 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।

Memory এই তালিকার কোনো line-এ নেই। এটি আপনার input token count-এর মধ্যে অন্তর্ভুক্ত হয়। সেখানেই আপনি এর পরিমাণ মাপতে পারেন। Pruning এবং caching ব্যবহার করে সেখানেই খরচ কমানো যায়। আপনি যদি একটি virtual private server (VPS)-এ unattended অবস্থায় চলা agent-এর budget নির্ধারণ করেন, তাহলে VPS-এ চলা AI agent-এর cost control পরবর্তী ধাপে স্থাপন করুন। কারণ, memory file বড় হতে থাকলে এবং pruning না থাকলে, কোনো reporting ছাড়াই 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-এ ওই token থাকে, প্রতিবার model-এর স্বাভাবিক input rate অনুযায়ী billing হয়।

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

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

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

সবচেয়ে সাধারণ কারণ হলো বিরতির পরে cache miss হওয়া। Cache entry ডিফল্টভাবে 5 মিনিট থাকে, আর extended setting-এ এক ঘণ্টা থাকে। তাই বিরতির পর প্রথম request-এ পুরো prefix base input rate-এ আবার process হয় এবং পুনরায় লেখা হয়। দ্বিতীয় সাধারণ কারণ হলো prefix edit। কোনো tool definition পরিবর্তন করলে পুরো cache invalid হয়। System prompt পরিবর্তন করলে system cache এবং message cache invalid হয়। Subscription plan-এ সাম্প্রতিক usage-এর 10 percent বা তার বেশি এই কারণে হলে /usage breakdown-এ এই আচরণের নাম দেখানো হয়।

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

প্রায় প্রতিটি turn-এ memory ব্যবহার হলে সেটি system prompt-এ রাখুন। এতে memory 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 হয়, তা ব্যাখ্যা করে।