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

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

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

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

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

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

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

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 کو کبھی store نہیں کرتا، اس لیے کوئی storage charge منتقل نہیں ہوتا۔ ادائیگی round trip کے عوض ہوتی ہے۔ Tool definition ہر request میں بھیجی جاتی ہے، اور واپس آنے والا file content اسی مقام سے conversation کا حصہ رہتا ہے۔

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

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

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

یاد رکھی گئی عبارت کو input tokens کے طور پر کیوں بل کیا جاتا ہے

Messages API بے حالت ہوتی ہے۔ یہ calls کے درمیان کچھ محفوظ نہیں رکھتی، اس لیے آپ کا client ہر turn پر پوری گفتگو بھیجتا ہے اور 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 breakpoint کے بعد موجود tokens ہیں۔ Request کے لیے input کا کل حجم cache_read_input_tokens، cache_creation_input_tokens اور input_tokens کا مجموعہ ہے۔ تین turns پہلے Claude کی کھولی ہوئی memory file اس کے بعد آنے والے ہر turn میں اسی مجموعے کا حصہ رہتی ہے۔ 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 متن کو system field میں paste کر کے چلائیں، اور ایک بار اس کے بغیر چلائیں۔ دونوں نتائج کا فرق وہ لاگت ہے جو ہر turn پر اس memory کی وجہ سے آپ کو برداشت کرنی پڑتی ہے۔ دو احتیاطیں ضروری ہیں۔ یہ count ایک تخمینہ ہے، اور Anthropic اپنی system optimizations کے لیے جو اضافی tokens شامل کرتا ہے، ان کی billing آپ سے نہیں ہوتی۔ اس model کے حساب سے بھی count کریں جسے آپ حقیقت میں چلائیں گے، کیونکہ Claude 4.7 اور بعد کے versions نیا tokenizer استعمال کرتے ہیں، جو اسی متن کے لیے تقریباً 30 فیصد زیادہ tokens بناتا ہے۔

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

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

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

CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 claude

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

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

Prompt caching کی وجہ سے ایک ہی memory block کی لاگت ایک turn میں دوسرے turn کے مقابلے میں دس گنا زیادہ ہو سکتی ہے۔ Anthropic ہر model کی base input price کے مضارب کے طور پر cache rates شائع کرتا ہے، اس لیے 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 minute lifetime کے ساتھ entry لکھنے کی لاگت base price کے 1.25 گنا ہے، جبکہ 1 hour lifetime کے ساتھ لاگت base price کے 2 گنا ہے۔ Anthropic break-even point واضح طور پر بیان کرتا ہے: 5 minute duration پر ایک cache read کے بعد، یا 1 hour duration پر دو cache reads کے بعد caching فائدہ مند ہو جاتی ہے۔ 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 tokens کا memory block تمام 100 turns میں cache سے miss ہو، تو اس کی billing 400,000 base-rate tokens کے برابر ہوگی۔ اگر یہی block ایک 5 minute cache write اور 99 cache reads کے پیچھے ہو، تو billing 44,600 tokens کے برابر ہوگی۔ اسے اس کے ایک چوتھائی حجم تک مختصر کریں اور caching برقرار رکھیں، تو billing 11,150 tokens کے برابر ہوگی۔ ان 3 rows میں feature تبدیل نہیں ہوا۔ صرف replay behaviour تبدیل ہوا۔ یہ اب بھی tokens کی تعداد ہے، رقم نہیں، اور token count کو ماہانہ bill کی رقم میں تبدیل کرنا آپ کے model کے per-million rate سے ایک ضرب کا عمل ہے۔ یہ rate آپ کے چلائے گئے model سے طے ہوتا ہے۔ اس لیے اگر agent Claude Fable 5 پر چلے گا، تو اس کے شائع شدہ per-million rates اور اس کے موزوں کام سے آغاز کریں۔ اگر provider کا انتخاب ابھی صرف model تک محدود نہ ہو اور کھلا سوال ہو، تو Claude کی API اور ChatGPT پر انہی jobs کی لاگت دکھاتی ہے کہ یہ ضرب دونوں صورتوں میں مختلف نتیجہ کہاں دیتی ہے، اور memory-heavy agent اس کے input حصے پر خاصا انحصار کرتا ہے۔

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

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

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

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

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

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

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

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

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

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

memory کی ہر سطر ہر اس turn میں 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 version 2.1.214 یا بعد کے versions میں write time کو modified field میں ISO 8601 timestamp کے طور پر درج کرتا ہے۔ یہ timestamp کسی پرانی ہو چکی حقیقت کی نشاندہی کرنے کا تیز ترین طریقہ ہے۔ پرانی agent memory کو حذف کرنا review process کی مزید تفصیل بیان کرتا ہے۔

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

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

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

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 settings میں 100,000 input tokens کا trigger اور 3 محفوظ tool uses شامل ہیں۔ اسے enable کرنے سے پہلے caching کے ساتھ interaction کا جائزہ لیں: content صاف کرنے سے clear کے مقام پر cached prefix invalid ہو جاتا ہے، اس لیے اگلی request پر cache write کی لاگت آتی ہے۔ clear_at_least اسی مقصد کے لیے ہے۔ یہ clearing کو اس وقت تک مؤخر رکھتا ہے جب تک بچت اتنی نہ ہو جائے کہ 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 میں شامل کیے جانے والے تمام content کی معمول کی token cost۔
• Code execution: ہر organization کے لیے ماہانہ 1,550 free hours، اس کے بعد ہر container کے لیے $0.05 فی hour۔ Web search یا web fetch کے ساتھ استعمال کرنے پر یہ free ہے۔
• Claude Managed Agents: ہر session-hour کے لیے $0.08 کی session runtime لاگت، معمول کی token charges کے علاوہ۔
• Web fetch: کوئی اضافی charge نہیں؛ صرف حاصل کیے گئے content کی token cost لاگو ہوتی ہے۔

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

FAQ

کیا Claude کی memory features کے لیے الگ سے چارج لیا جاتا ہے؟

نہیں۔ Anthropic کی price list میں rates فی million input tokens، فی million output tokens اور prompt caching multiples کے حساب سے دیے گئے ہیں؛ memory کے لیے کوئی الگ line item نہیں ہے۔ 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 کی لاگت سے زیادہ ہو سکتی ہے۔ اندازہ لگانے کے بجائے اسے measure کریں: 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 کرتی ہے اور اسے دوبارہ لکھتی ہے۔ دوسری عام وجہ 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 features subscription usage limits میں شمار ہوتی ہیں؟

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