کیا Claude memory کے لیے اضافی قیمت لیتا ہے؟

کیا Claude کی memory خصوصیات کے لیے اضافی قیمت ادا کرنا پڑتی ہے؟

Claude کی memory خصوصیات کی اپنی کوئی الگ قیمت نہیں ہے۔ Anthropic کی شائع کردہ شرحیں input کے ہر million tokens اور output کے ہر million tokens کے حساب سے ہیں۔ prompt caching کے لیے اضافی شرحیں بھی ہیں، لیکن ان میں سے کسی کو memory token نہیں کہا جاتا۔ Claude API (application programming interface) پر memory محفوظ کرنے کی کوئی لاگت نہیں، کیونکہ memory tool client-side ہے اور فائل آپ کی ملکیت والی storage پر رہتی ہے۔

اس کے باوجود memory آپ کے bill پر اثر ڈالتی ہے، کیونکہ یاد رکھی گئی بات کسی جواب کو صرف اسی وقت تبدیل کرتی ہے جب وہ اس request میں شامل ہو جسے Claude پڑھتا ہے۔ کسی بات کو یاد رکھنے کا مطلب ہے اسے دوبارہ بھیجنا۔ یہ متن input tokens کے طور پر پہنچتا ہے اور model کی عام input rate کے مطابق charge ہوتا ہے۔ لاگت کا فیصلہ دو چیزیں کرتی ہیں: ہر turn پر دوبارہ بھیجے جانے والے remembered text کے کتنے tokens ہیں، اور کیا یہ دوبارہ بھیجا گیا متن prompt cache سے فراہم کیا جا سکتا ہے۔

Pro یا Max subscription پر آپ سے tokens کے حساب سے بالکل charge نہیں لیا جاتا۔ اس لیے memory آپ کے پیسوں کے بجائے usage allowance استعمال کرتی ہے۔ طریقۂ کار وہی رہتا ہے۔ صرف unit تبدیل ہوتی ہے۔ یہ allowance محدود ہے، اس لیے یہ فیصلہ کرنے سے پہلے کہ ہر turn میں کتنی memory شامل ہونی چاہیے، یہ جاننا مفید ہے کہ Claude Pro کی قیمت کیا ہے اور اس کی limits کب آپ کو روکنے لگتی ہیں۔ Claude Enterprise کا طریقۂ کار پھر مختلف ہے، کیونکہ یہ seat price کے علاوہ ہر token کو API rates کے مطابق meter کرتا ہے۔ اس لیے memory کا بہت بڑا block allowance کے بجائے دوبارہ حقیقی لاگت میں تبدیل ہو جاتا ہے۔ اگر memory کو مختصر کرنے سے آپ کا usage کسی چھوٹے plan کی ceiling سے آرام سے نیچے آ جائے، تو Max سے Pro پر منتقل ہونا اگلا قابلِ غور قدم ہے۔ یہ تبدیلی اس مدت کے اختتام پر نافذ ہوتی ہے جس کی ادائیگی آپ پہلے ہی کر چکے ہیں۔ اگر آپ دراصل Anthropic کے اپنے tiers کے بجائے مختلف providers کا موازنہ کر رہے ہیں، تو موجودہ قیمتوں پر Claude کے plans کو ChatGPT کے ساتھ رکھ کر دیکھنا شروع کرنے کی درست جگہ ہے۔

ہر Claude surface پر "memory" سے کیا مراد ہے

تین الگ products یہ لفظ استعمال کرتے ہیں، اور ان میں خلط ملط ہونا ہی زیادہ تر اس وجہ کی بنا پر یہ سوال الجھا ہوا محسوس ہوتا ہے۔

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 کے لیے ہوتی ہے۔ tool definition ہر request میں بھیجی جاتی ہے، اور واپس آنے والا file content اسی مقام سے conversation کا حصہ رہتا ہے۔

Anthropic اس overhead کا مستقل حصہ شائع کرتا ہے۔ Claude Opus 5 پر auto کی tool choice کے ساتھ، August 2026 میں دستاویزی tool-use system prompt 286 tokens کا ہے۔ جب بھی کوئی tool موجود ہو، memory ہو یا کوئی اور، یہ ہر request پر ایک بار charge ہوتا ہے۔

Claude Code۔ ہر session کے آغاز پر دو mechanisms load ہوتے ہیں۔ CLAUDE.md files آپ کی لکھی ہوئی instructions رکھتی ہیں۔ Auto memory ان notes کو رکھتی ہے جو Claude اپنے لیے ~/.claude/projects/<project>/memory/ کے تحت لکھتا ہے۔ MEMORY.md کی صرف پہلی 200 lines یا 25KB load ہوتی ہے، جو بھی limit پہلے آ جائے، اور اس کے ساتھ موجود topic files startup کے بجائے ضرورت کے وقت پڑھی جاتی ہیں۔ Startup پر load ہونے والی ہر چیز اس prefix کا حصہ بن جاتی ہے جسے اس session کی ہر بعد والی request ساتھ لے کر چلتی ہے۔ Claude Code sessions کے درمیان memory کیسے یاد رکھتا ہے میں file بہ file loading order بیان کیا گیا ہے۔

Claude on the web۔ claude.ai پر memory ان entries کا مجموعہ ہے جنہیں Claude آپ کے chat کرنے کے دوران لکھتا اور update کرتا ہے، اور ہر project کے لیے الگ memory space ہوتی ہے۔ Settings > Memory میں محفوظ شدہ چیزوں کی فہرست ہوتی ہے، اور وہاں موجود toggle سے Pause memory یا Reset memory منتخب کیا جا سکتا ہے۔ اس surface پر billing subscription کے ذریعے ہوتی ہے، اس لیے یہاں memory usage limits استعمال کرتی ہے۔

یاد رکھا گیا متن input tokens کے طور پر بل کیوں ہوتا ہے

Messages API stateless ہے۔ یہ calls کے درمیان کچھ محفوظ نہیں رکھتی، اس لیے client ہر turn پر پوری 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 صرف ان tokens کو شمار کرتا ہے جو نہ cache سے پڑھے گئے ہوں اور نہ cache بنانے کے لیے استعمال ہوئے ہوں۔ عملی طور پر اس کا مطلب آخری cache breakpoint کے بعد موجود tokens ہیں۔ request کے لیے کل input cache_read_input_tokens، cache_creation_input_tokens اور input_tokens کا مجموعہ ہے۔ Claude نے جو memory file تین turns پہلے کھولی تھی، وہ اس کے بعد آنے والے ہر turn میں اسی total کا حصہ رہتی ہے۔ جب cached prefix برقرار ہو تو یہ cache_read_input_tokens کے تحت آتی ہے، اور جب cached prefix برقرار نہ رہے تو input_tokens کے تحت آتی ہے۔ متن وہی رہتا ہے، لیکن قیمت میں بہت فرق ہوتا ہے۔ Input اور output tokens کی قیمتیں مختلف ہوتی ہیں، اور memory ہمیشہ input والے حصے میں شمار ہوتی ہے۔

اپنے استعمال میں یہ اعداد کہاں دیکھیں

کسی blog post، حتیٰ کہ اس تحریر، سے بھی کوئی عدد اخذ نہ کریں۔ اپنے 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 کرکے چلائیں، اور ایک بار اس کے بغیر چلائیں۔ دونوں کے فرق سے معلوم ہوگا کہ ہر turn پر وہ memory آپ سے کتنے tokens کی لاگت لیتی ہے۔ دو باتوں کا خیال رکھیں۔ یہ count ایک تخمینہ ہے، اور Anthropic اپنی system optimizations کے لیے جو اضافی tokens شامل کرتا ہے، ان کے charges آپ سے نہیں لیے جاتے۔ اس model کے مطابق بھی count کریں جسے آپ حقیقتاً چلائیں گے، کیونکہ Claude 4.7 اور بعد کے versions نیا tokenizer استعمال کرتے ہیں، جو اسی text کے لیے تقریباً 30 percent زیادہ tokens پیدا کرتا ہے۔

Claude Code کے اندر یہی سوال کسی curl کے بغیر حل ہو جاتا ہے۔

• /context اس وقت loaded تمام چیزیں دکھاتا ہے، جن میں memory files بھی شامل ہیں، اس لیے آپ کچھ type کرنے سے پہلے window میں ان کا حصہ دیکھ سکتے ہیں۔
• /memory آپ کی CLAUDE.md files کی فہرست دکھاتا ہے اور auto memory folder کھولتا ہے۔
• /usage session totals دکھاتا ہے، جن میں cache reads اور cache writes بھی شامل ہیں۔
• 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 سمیت، کو ظاہر کرتی ہے جو ہر turn پر cache rate کے مطابق دوبارہ بھیجی جا رہی ہے۔ 1.2k input figure صرف وہ حصہ ہے جو نیا تھا۔ Claude Code اس dollar amount کو list prices کی بنیاد پر مقامی طور پر calculate کرتا ہے، اس لیے یہ آپ کو حاصل discount کو نظرانداز کرتا ہے اور آپ کے invoice سے مختلف ہو سکتا ہے۔ Claude Console کا Usage page authoritative number فراہم کرتا ہے۔

اب comparison براہِ راست چلائیں۔ دو نئی sessions میں ایک ہی opening question پوچھیں۔ ایک session معمول کے مطابق ہو، اور دوسری میں auto memory بند ہو۔

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

ہر session میں /context چلائیں اور memory files entry کا موازنہ کریں۔ یہ فرق اس accumulated memory کی لاگت ہے جو ہر session کے آغاز پر، کوئی work شروع ہونے سے پہلے، آپ سے لی جاتی ہے۔ Claude Code کے token usage کی مکمل تفصیل کہاں خرچ ہوتی ہے ان دونوں اعداد کے ساتھ پڑھنا مفید ہوگا۔

فی ملین tokens کے حساب سے memory کو دوبارہ چلانے کی لاگت کتنی ہے؟

Prompt caching کی وجہ سے ایک ہی memory block کی لاگت ایک turn میں دوسرے turn کے مقابلے میں دس گنا زیادہ ہو سکتی ہے۔ Anthropic cache rates کو ہر model کی base input price کے مضرب کے طور پر شائع کرتا ہے، اس لیے dollar prices تبدیل ہونے کے باوجود یہ تعلق برقرار رہتا ہے۔

[
  {
    "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 کے ساتھ یہ لاگت base price سے 2 گنا ہے۔ Anthropic break-even point واضح طور پر بیان کرتا ہے: 5 منٹ کی مدت میں ایک cache read کے بعد caching فائدہ مند ہو جاتی ہے، جبکہ 1 گھنٹے کی مدت میں دو cache reads کے بعد۔ Prompt caching کا break-even point وہ حساب ہے جو memory کی جگہ طے کرنے سے پہلے کرنا چاہیے۔

یہ مضارب replay count کو حساب میں بدل دیتے ہیں۔ اگلا block اوپر شائع کیے گئے مضارب کی بنیاد پر حساب ہے، کسی live workload کی پیمائش نہیں۔ اس میں 100 turn کے session کے دوران memory block کی لاگت تین طریقوں سے دکھائی گئی ہے۔ اسے plain base input rate پر charged tokens کی مساوی تعداد میں بیان کیا گیا ہے۔

[
  {
    "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 کے برابر bill بنتا ہے۔ یہی block ایک 5 منٹ کی cache write اور 99 cache reads کے پیچھے ہو تو اس کا bill 44,600 کے برابر بنتا ہے۔ اسے اصل سائز کے ایک چوتھائی تک کم کر کے caching برقرار رکھی جائے تو bill 11,150 کے برابر بنتا ہے۔ ان 3 rows میں feature تبدیل نہیں ہوا۔ صرف replay behaviour تبدیل ہوا۔ یہ اب بھی tokens کی تعداد ہے، رقم نہیں، اور token count کو ماہانہ bill کی رقم میں تبدیل کرنا آپ کے model کے per-million rate سے ایک ضرب کا معاملہ ہے۔ یہ rate اس model سے طے ہوتا ہے جسے آپ چلاتے ہیں۔ اس لیے اگر agent Claude Fable 5 پر چلے گا تو اس کے شائع شدہ per-million rates اور موزوں کام سے آغاز کریں۔

دوسری row یہ فرض کرتی ہے کہ بعد کی 99 requests میں سے ہر ایک اس وقت آتی ہے جب cache entry اب بھی فعال ہو۔ زیادہ تر حقیقی bills میں غلطی اسی مفروضے کی وجہ سے ہوتی ہے۔

وقفے کے بعد وہی سوال زیادہ مہنگا کیوں ہو جاتا ہے؟

ایک cache entry کی ایک مدتِ حیات ہوتی ہے، اور clock اس request سے شروع ہوتی ہے جو اسے لکھتی یا پڑھتی ہے۔ ڈیفالٹ مدت 5 منٹ ہے۔ 1 hour کا option اوپر دکھائی گئی write لاگت سے 2x مہنگا ہے۔ Claude Code میں subscription کے دوران یہ مدت ایک گھنٹہ ہوتی ہے، لیکن usage credits استعمال ہونے لگیں تو کم ہو کر 5 منٹ رہ جاتی ہے؛ API key یا cloud provider پر یہ ڈیفالٹ طور پر 5 منٹ ہے۔ ENABLE_PROMPT_CACHING_1H=1 سیٹ کرنے سے usage credits استعمال کرتے وقت بھی ایک گھنٹے کی مدت برقرار رہتی ہے۔

اس لیے lunch کے دوران کھلے چھوڑے گئے session میں ٹائپ کیا گیا ایک سطری سوال مہنگا ہوتا ہے، کیونکہ آپ کی غیر موجودگی میں cache entry expire ہو جاتی ہے۔ مکمل prefix، memory سمیت، base input rate پر دوبارہ process کیا جاتا ہے اور دوبارہ cache میں لکھا جاتا ہے۔ وقفے کی مدت نے اس لاگت کا تعین کیا۔

آپ اس بات کو صرف یقین کرنے کے بجائے خود verify کر سکتے ہیں۔ Pro، Max، Team یا Enterprise plan پر /usage breakdown حالیہ usage کے 10 فیصد یا اس سے زیادہ کے ذمہ دار ہر behavior کو نمایاں کرتا ہے، اور long context اور cache misses وہاں اپنے نام سے دکھائی دیتے ہیں۔ API پر cache_creation_input_tokens کو خاموش وقفے کے بعد پہلی request میں دوبارہ اپنے prefix کے مکمل سائز تک بڑھتے دیکھیں۔

کیا چیز خاموشی سے cache کو غیر مؤثر بنا دیتی ہے

cache میں شامل prefix ترتیب وار ہوتا ہے: پہلے tools، پھر system، اور آخر میں messages۔ کسی سطح پر تبدیلی اس سطح اور اس کے بعد آنے والی ہر چیز کا cache invalid کر دیتی ہے۔ کسی tool definition میں ترمیم کرنے سے پورا cache ضائع ہو جاتا ہے۔ system prompt میں ترمیم کرنے سے system اور message cache ضائع ہو جاتا ہے۔

یہ اس شخص کے لیے اہم مسئلہ ہے جو system prompt میں memory رکھتا ہے اور agent کے سیکھنے کے ساتھ اسے دوبارہ لکھتا رہتا ہے۔ ہر بار کی گئی ترمیم اس کے بعد موجود ہر چیز کی cached copy ضائع کر دیتی ہے، اس لیے اگلی request میں دوبارہ مکمل write کی لاگت آتی ہے۔ مستحکم مواد کو شروع میں رکھیں اور اسے تبدیل نہ کریں۔ متغیر مواد کو message list کے آخر میں رکھیں، جہاں اسے invalid کرنے کی لاگت کم ہو۔

ایک دوسری، زیادہ خاموش ناکامی بھی ہوتی ہے۔ ہر model کے لیے cacheable prefix کی کم از کم حد مقرر ہے: August 2026 میں شائع کردہ معلومات کے مطابق Claude Opus 5 کے لیے 512 tokens، Claude Sonnet 5 کے لیے 1,024، اور Claude Haiku 4.5 کے لیے 4,096۔ Anthropic کی documentation اس حد سے کم مقدار کے بارے میں واضح ہے: "اس تعداد سے کم tokens کو cache کرنے کی تمام requests بغیر caching کے process کی جائیں گی، اور کوئی error واپس نہیں کیا جائے گا۔" اس لیے cache_control کے ذریعے نشان زدہ ایک چھوٹی memory file خاموشی سے بالکل کوئی اثر نہیں ڈالتی۔ نظر آنے والی علامت یہ ہے کہ cache_creation_input_tokens کی قدر 0 پر رہتی ہے، حالانکہ آپ کے prompt میں واضح طور پر breakpoint موجود ہوتا ہے۔

ایسی memory کو حذف کریں جو اب اپنی جگہ ثابت نہیں کرتی

ہر turn میں شامل memory کی ہر سطر tokens استعمال کرتی ہے۔ اس لیے ہر سطر کے بارے میں یہ دیکھیں کہ آیا اس نے حالیہ جوابات میں کوئی تبدیلی پیدا کی ہے۔ Claude Code ان حدود کو واضح بناتا ہے۔ CLAUDE.md کو 200 سطروں سے کم رکھنے کی کوشش کریں، کیونکہ طویل files زیادہ context استعمال کرتی ہیں اور Claude کی ہدایات پر قابلِ اعتماد عمل درآمد کم ہو جاتا ہے۔ لوڈ کے وقت MEMORY.md پہلی 200 سطروں یا 25KB تک محدود ہوتا ہے۔ اس حد کے بعد کا تمام مواد اگلا session شروع ہونے پر حذف کر دیا جاتا ہے۔ اس لیے بہت بڑا index tokens خرچ کرتا ہے، مگر کوئی مفید معلومات فراہم نہیں کرتا۔

اسے مختصر رکھنے کے لیے دو عادات اپنائیں۔ تفصیلات index سے نکال کر topic files میں منتقل کریں۔ Claude انہیں startup کے بجائے ضرورت کے وقت پڑھتا ہے۔ Workflow instructions کو CLAUDE.md سے نکال کر skills میں منتقل کریں۔ یہ صرف invoke ہونے پر load ہوتی ہیں۔ جن memory files کے آغاز میں پہلے سے frontmatter موجود ہو، ان کے لیے Claude Code write time کو modified field میں ISO 8601 timestamp کے طور پر درج کرتا ہے، بشرطیکہ version 2.1.214 یا اس کے بعد کا ہو۔ یہ timestamp اس fact کی فوری شناخت کا بہترین طریقہ ہے جو stale ہو چکا ہو۔ stale agent memory کی pruning میں review process کی مزید تفصیل دی گئی ہے۔

جب ہر چیز context میں لوڈ کرنے کے بجائے retrieval بہتر ہو

memory tool کو just-in-time retrieval کے لیے استعمال کیا جاتا ہے۔ ہر چیز پہلے سے لوڈ کرنے کے بجائے agent سیکھی ہوئی معلومات ریکارڈ کرتا ہے اور صرف اسی وقت file دوبارہ پڑھتا ہے جب task کو اس کی ضرورت ہو۔ اس سے حساب بدل جاتا ہے، کیونکہ file read کے tokens صرف ایک بار خرچ ہوتے ہیں اور پھر cached prefix میں رہتے ہیں، جبکہ مستقل طور پر لوڈ کیا گیا block ہر turn پر لاگت پیدا کرتا ہے۔

اوپر دیے گئے دونوں charts سے ایک سادہ اصول اخذ ہوتا ہے۔ جو متن تقریباً ہر turn میں استعمال ہوتا ہے، اسے stable cached prefix میں رکھیں۔ جو متن ہر 20 turns میں صرف ایک بار استعمال ہوتا ہے، اسے view call کے پیچھے رکھیں۔ break-even آپ کے replay count کے ساتھ بدلتا ہے، Anthropic کے عائد کردہ کسی charge کے ساتھ نہیں۔

API پر آپ platform کو conversation کو مختصر کرنے کی اجازت بھی دے سکتے ہیں۔ Context editing اس وقت پرانے tool results صاف کر دیتی ہے جب conversation آپ کے مقرر کردہ threshold سے تجاوز کر جائے۔

{
  "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 uses ہوتے ہیں۔ اسے enable کرنے سے پہلے caching کے ساتھ interaction پڑھیں: content صاف کرنے سے clear کے مقام پر cached prefix invalid ہو جاتا ہے، اس لیے اگلی request پر cache write کی لاگت آتی ہے۔ clear_at_least اسی مقصد کے لیے ہے۔ یہ clearing کو اس وقت تک مؤخر رکھتا ہے جب تک بچت cache write کو جواز دینے کے لیے کافی نہ ہو جائے۔ Response context_management کے تحت عین وہی صورتِ حال بیان کرتا ہے جو پیش آئی، اور اس میں cleared_tool_uses اور cleared_input_tokens شامل ہوتے ہیں، اس لیے یہ trade نظری نہیں رہتا بلکہ قابلِ پیمائش ہوتا ہے۔ Claude Code میں context window کا انتظام coding session پر بھی یہی اصول لاگو کرتا ہے۔

اپنی الگ لاگت

Memory کی اپنی کوئی لاگت نہیں، لیکن کچھ features کی واقعی الگ فیس ہوتی ہے، اور یہ جاننا مفید ہے کہ کون سی features اس میں شامل ہیں۔ یہ August 2026 تک Claude API کے شائع شدہ rates ہیں۔ چند operations کی کوئی لاگت نہیں ہوتی، لیکن Claude API پر کوئی free tier نہیں ہے؛ signup پر صرف ایک چھوٹا credit ملتا ہے۔ اس لیے نیچے دی گئی تمام لاگت آپ کی پہلی request سے ہی حقیقی خرچ شمار ہوتی ہے۔

• Web search: ہر 1,000 searches کے لیے $10، اس کے علاوہ search کے context میں شامل کیے گئے تمام مواد کی معمول کی token cost۔
• Code execution: ہر organization کے لیے ماہانہ 1,550 free hours، اس کے بعد ہر container کے لیے $0.05 فی hour۔ Web search یا web fetch کے ساتھ استعمال کرنے پر یہ free ہے۔
• Claude Managed Agents: session runtime کے لیے $0.08 فی session-hour، معمول کی token charges کے علاوہ۔
• Web fetch: کوئی اضافی charge نہیں؛ صرف fetch کیے گئے content کی token cost لاگو ہوتی ہے۔

Memory ان میں سے کسی line item میں شامل نہیں۔ یہ آپ کے input token count میں ظاہر ہوتی ہے۔ اسی مقام پر آپ اسے measure کر سکتے ہیں، اور pruning اور caching کے ذریعے اسی لاگت کو کم کیا جا سکتا ہے۔ اگر آپ virtual private server (VPS) پر unattended چلنے والے agent کا budget بنا رہے ہیں تو VPS پر AI agent کے لیے cost controls اگلا انتظام ہے جسے نافذ کرنا چاہیے، کیونکہ بڑھتی ہوئی memory file اور pruning کے بغیر agent ہر ہفتے زیادہ مہنگا ہوتا جاتا ہے، جبکہ کوئی system اس کی اطلاع نہیں دیتا۔

FAQ

کیا Claude کی memory خصوصیات کے لیے الگ فیس ہے؟

نہیں۔ Anthropic کی price list میں فی million input tokens، فی million output tokens اور prompt caching multiples کے حساب سے rates درج ہیں، memory کے لیے الگ لائن نہیں ہے۔ Claude API میں memory tool client-side ہوتا ہے، اس لیے files اسی storage پر رہتی ہیں جس کے لیے آپ پہلے ہی ادائیگی کر رہے ہیں۔ Memory کی وجہ سے input tokens شامل ہوتے ہیں، اور جن turns میں یہ tokens شامل ہوں ان میں انہیں model کے معمول کے input rate پر bill کیا جاتا ہے۔

کیا memory بند کرنے سے Claude سستا ہو جاتا ہے؟

اس سے ہر request میں tokens کی تعداد کم ہو جاتی ہے، جس سے ہر request کی لاگت کم ہوتی ہے۔ مجموعی بچت کا انحصار اگلے مرحلے پر ہے۔ اگر Claude کو memory میں موجود معلومات دوبارہ حاصل کرنے کے لیے تین files دوبارہ پڑھنی پڑیں اور آپ سے دو سوال پوچھنے پڑیں، تو ان tokens کی لاگت memory کی لاگت سے زیادہ ہو سکتی ہے۔ اندازہ لگانے کے بجائے پیمائش کریں: auto memory فعال session میں /context چلائیں اور CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 کے ساتھ شروع کیے گئے session میں بھی چلائیں، پھر اسی task پر خرچ ہونے والے total tokens کا موازنہ کریں۔

جب میں نے کچھ تبدیل نہیں کیا تو میرا usage کیوں بڑھ گیا؟

سب سے عام وجہ وقفے کے بعد cache miss ہے۔ Cache entries default طور پر 5 minutes تک رہتی ہیں، یا extended setting میں one hour تک، اس لیے وقفے کے بعد پہلی request پورے prefix کو base input rate پر دوبارہ process کرتی ہے اور اسے دوبارہ cache میں لکھتی ہے۔ دوسری عام وجہ prefix edit ہے: tool definition تبدیل کرنے سے پورا cache invalid ہو جاتا ہے، جبکہ system prompt تبدیل کرنے سے system اور message cache invalid ہو جاتا ہے۔ Subscription plan میں /usage breakdown اس صورتِ حال کو نام دیتا ہے جب یہ حالیہ usage کے 10 percent یا اس سے زیادہ کا سبب بنے۔

کیا memory کو system prompt میں رکھنا چاہیے یا tool call کے پیچھے؟

جب تقریباً ہر turn میں memory استعمال ہوتی ہو تو اسے system prompt میں رکھیں، کیونکہ اس صورت میں وہ cached prefix میں شامل رہتی ہے اور cache read rate پر اس کی لاگت آتی ہے۔ جب صرف کچھ tasks کو memory درکار ہو تو اسے view call کے پیچھے رکھیں، کیونکہ ایک بار پڑھی جانے والی file کے tokens ہر turn کے بجائے صرف ایک بار کی لاگت بنتے ہیں۔ فیصلہ کن عدد آپ کا replay count ہے، اور usage object یہ عدد براہِ راست فراہم کرتا ہے۔

کیا memory خصوصیات subscription usage limits میں شمار ہوتی ہیں؟

ہاں، بالواسطہ طور پر، کیونکہ subscription limits ہر request میں شامل tokens سے استعمال ہوتی ہیں۔ Anthropic کی help documentation کے مطابق، وہ طویل conversations جو automatic context management کو فعال کرتی ہیں، آپ کی usage limit کا زیادہ حصہ استعمال کرتی ہیں۔ Memory ہر request کو کچھ طویل بنا دیتی ہے، اور ایک long session ہر turn میں اس اضافی length کو دوبارہ شامل کرتا ہے۔ Claude کی usage limits حقیقت میں کیسے کام کرتی ہیں میں بتایا گیا ہے کہ کیا چیز کب reset ہوتی ہے۔