Claude Code سیشن کو سستا اور تیز کیسے بنائیں

Claude Code کے طویل سیشن کو سست اور مہنگا ہونے سے کیسے روکیں

Claude Code کا ایک طویل سیشن سست اور مہنگا ہو جاتا ہے کیونکہ ہر ٹرن (turn) میں پورا سیاق و سباق (context) دوبارہ بھیجا جاتا ہے، اور یہ سیاق و سباق مسلسل بڑھتا رہتا ہے۔ اس کا حل ایک مقررہ ترتیب کے ساتھ صفائی (hygiene) برقرار رکھنا ہے۔ یہ دیکھنے کے لیے کہ ونڈو میں کیا چیزیں جگہ گھیر رہی ہیں /context چلائیں، ان آئٹمز کو کاٹ دیں جن کے لیے آپ کو ہر ریکوئسٹ پر ادائیگی کرنی پڑتی ہے، پھر غیر متعلقہ کاموں کے درمیان /clear استعمال کریں اور ایک طویل کام کے اندر ہدایات کے ساتھ /compact استعمال کریں۔ کام کو مسلسل وقفوں میں کریں، کیونکہ کولڈ پرامپٹ کیش (cold prompt cache) سستے ریڈ (read) کو آپ کی کہی گئی تمام باتوں کے مکمل ری رائٹ (re-write) میں بدل دیتا ہے۔

میٹر کیوں چلتا ہے، اس کا جواب ایجنٹ سیشن کے پیچھے ٹوکن میٹر میں دیا گیا ہے۔

کسی بھی تبدیلی سے پہلے /context پڑھیں

ونڈو میں موجود ڈیٹا کا اندازہ لگانے کی کوشش نہ کریں۔ Claude Code آپ کو خود بتائے گا۔

/context [all] موجودہ context usage کو ایک رنگین grid کے طور پر دکھاتا ہے، جس میں context-heavy tools اور memory bloat کے لیے optimization تجاویز شامل ہوتی ہیں؛ all fullscreen mode میں ہر item کی تفصیلات کو expand کرتا ہے۔ نتائج کو پانچ حصوں (buckets) کے طور پر پڑھیں:

• The system prompt. Claude Code کی اپنی harness instructions۔ یہ session کے دوران مستقل رہتی ہیں۔
• Tool definitions. ہر اس tool کا schema جسے agent call کر سکتا ہے، بشمول تمام connected MCP (Model Context Protocol) servers۔
• Memory files. CLAUDE.md اور auto memory، جو session کے آغاز پر load ہوتی ہیں۔
• Files and tool results. ہر وہ file جو read کی گئی ہو، اور وہ تمام معلومات جو آپ کے commands نے print کی ہوں۔
• Message history. آپ کے messages اور ان کے replies۔

پہلے تین حصے ایک fixed tax ہیں، جو session کے دوران ہر request پر لاگو ہوتے ہیں۔ آخری دو حصے وقت کے ساتھ بڑھتے ہیں۔ شروع میں fixed tax کو ایک بار کم کریں؛ بڑھتے ہوئے حصے کو مسلسل manage کریں۔

دو strings آپ کو بتائیں گی کہ window بھر چکی ہے:

Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.
Context is 94k tokens past the 200k-token compaction window — run /compact to reduce usage.

پہلی ایک hard limit ہے، جس کی صورت میں request refuse کر دی جاتی ہے؛ متعلقہ API (application programming interface) error Prompt is too long ہے۔ دوسری ایک compaction window ہے، جو 1 million token model پر model کے اصل context window سے نیچے ہو سکتی ہے۔ اس حد کے بعد بھی requests کامیاب ہو سکتی ہیں، اس لیے یہ refusal کے بجائے ایک warning ہے۔

Paid plan پر، /usage دوسری معلومات فراہم کرتا ہے، جو long context یا cache misses جیسے behaviors کو flag کرتا ہے اور حالیہ usage کو individual skills، subagents اور MCP servers کے ساتھ منسوب کرتا ہے۔

CLAUDE.md ایک مستقل ٹیکس ہے، اس لیے اسے مختصر رکھیں

آپ کا CLAUDE.md سیشن کے آغاز پر context میں لوڈ ہو جاتا ہے اور وہیں رہتا ہے۔ اگر اس میں تفصیلی deployment procedure موجود ہے، تو وہ tokens تب بھی موجود رہیں گے جب آپ کسی test file میں typo درست کر رہے ہوں گے۔ Anthropic کی ہدایت ہے کہ صرف ضروری معلومات شامل کریں اور فائل کو 200 lines سے کم رکھیں۔

Procedures کو skills میں منتقل کریں۔ ایک skill صرف تب لوڈ ہوتی ہے جب اسے invoke کیا جائے، اس لیے ہفتے میں دو بار چلایا جانے والا workflow باقی دنوں میں کوئی اضافی costs نہیں رکھتا۔ Compaction کے بعد skills کا اپنا budget ہوتا ہے: bodies کو دوبارہ inject کیا جاتا ہے، جس کی حد فی skill 5,000 tokens اور مجموعی طور پر 25,000 tokens ہے، اور پرانی معلومات پہلے हटائی جاتی ہیں۔ Truncation فائل کا آغاز برقرار رکھتی ہے، اس لیے اہم ترین ہدایات کو SKILL.md کے اوپری حصے میں رکھیں۔

Compaction کے بعد جو معلومات باقی رہتی ہیں، وہی طے کرتی ہیں کہ کوئی instruction کہاں ہونی چاہیے:

• System prompt اور output style تبدیل نہیں ہوتے، کیونکہ وہ message history کا حصہ نہیں ہوتے۔
• Project-root CLAUDE.md، unscoped rules، اور auto memory کو disk سے دوبارہ inject کیا جاتا ہے۔
• paths: frontmatter والی rule تب تک ضائع ہو جاتی ہے جب تک اس سے مماثل فائل دوبارہ نہ پڑھی جائے۔
• Subdirectory میں موجود nested CLAUDE.md تب تک ضائع ہو جاتی ہے جب تک اس subdirectory کی کوئی فائل دوبارہ نہ پڑھی جائے۔
• Hooks پر کوئی اثر نہیں پڑتا، کیونکہ hook code کے طور پر چلتا ہے اور کبھی context میں داخل نہیں ہوتا۔

لہذا، جس rule پر آپ انحصار کرتے ہیں اسے project-root CLAUDE.md میں ہونا چاہیے: Claude Code پہلے پرانے tool outputs کو clear کرتا ہے اور پھر summarize کرتا ہے، اس لیے conversation کے شروع میں دی گئی ہدایات ضائع ہو سکتی ہیں۔ Memory کو /memory کے ذریعے edit کریں۔ Claude Code سیشن کے آغاز پر لوڈ کی گئی copy کو برقرار رکھتا ہے، اس لیے سیشن کے دوران ہونے والی trimming prompt cache کو برقرار رکھتی ہے اور یہ اگلی /clear، /compact، یا restart تک لاگو نہیں ہوتی۔

/clear کاموں کے درمیان، /compact ایک کام کے اندر

یہ دونوں کمانڈز ایک جیسی لگتی ہیں لیکن ان کی قیمت میں بہت فرق ہے۔

/clear [name] خالی context کے ساتھ نیا مکالمہ شروع کرتا ہے۔ یہ کوئی request نہیں بھیجتا، اس لیے اس کی کوئی قیمت نہیں لگتی۔ پچھلے مکالمے کو /resume picker میں نام دینے کے لیے کوئی نام فراہم کریں؛ /reset اور /new اس کے متبادل (aliases) ہیں۔ جب آپ کسی غیر متعلقہ کام پر منتقل ہوں تو فوراً اسے استعمال کریں، ورنہ پرانا کام ہر نئے میسج کے ساتھ دوبارہ بھیجا جائے گا اور اس کا دوبارہ بل بھی آئے گا۔

/compact [instructions] ایک ہی مکالمے کو جاری رکھتے ہوئے context کو خالی کرتا ہے: یہ اب تک کی تاریخ (history) کا خلاصہ کرتا ہے اور اسے تبدیل کر دیتا ہے۔ اسے ایک طویل کام کے دوران استعمال کریں جہاں آپ کو تسلسل کی ضرورت ہو۔

ہمیشہ /compact کو ایک ہدایت (instruction) دیں۔ ایک سادہ /compact ڈیفالٹ prompt کے مطابق خلاصہ کرتا ہے جسے یہ معلوم نہیں ہوتا کہ آپ کو کام کے کس حصے کی ضرورت ہے۔ ہدایت کے ساتھ استعمال کرنے پر یہ اسے برقرار رکھتا ہے:

/compact focus on the auth bug fix
/compact keep only the plan and the diff

اگر آپ ہر بار ایک ہی وجہ سے compact کرنا چاہتے ہیں، تو اپنے پروجیکٹ کے CLAUDE.md میں # Compact instructions ہیڈنگ کے تحت ایک مستقل ہدایت لکھ دیں۔ ایک نئے session میں /compact Not enough messages to compact. پرنٹ کرتا ہے، جس کا مطلب ہے کہ ابھی کوئی history موجود نہیں ہے۔

یہاں دو قسم کی قیمتوں میں الجھن ہو سکتی ہے۔ summarization request آپ کے prefix کو استعمال کرتی ہے، اس لیے یہ تاریخ کو دوبارہ process کرنے کے بجائے موجودہ cache کو پڑھتی ہے، اور اس کا زیادہ وقت خلاصہ بنانے میں صرف ہوتا ہے۔ بڑے context کو compact کرنا اب بھی ایک بڑی request ہے، کیونکہ جس مکالمے کا خلاصہ کیا جا رہا ہے وہ input کے طور پر استعمال ہوتا ہے۔ compaction کے بعد والا مرحلہ سست نہیں ہوتا: یہ بہت چھوٹے prompt کے لیے cache کو دوبارہ ترتیب دیتا ہے۔

دو سستی کمانڈز دستیاب ہیں۔ /rewind [description] کوڈ اور مکالمے کو ایک checkpoint پر واپس لے جاتا ہے؛ اگر آپ کسی ایسے path کو چھوڑنا چاہتے ہیں جسے مکمل طور پر ختم کرنا ہو، تو یہ compact کرنے سے بہتر ہے، کیونکہ یہ ایک ایسے prefix تک محدود کر دیتا ہے جو پہلے سے cached ہے۔ /recap تاریخ کو تبدیل کرنے کے بجائے خلاصے کو command output کے طور پر شامل کرتا ہے، اس طرح cached prefix برقرار رہتا ہے۔

بار بار خودکار (automatic) compaction ہونے پر یہ پرنٹ ہوتا ہے:

Autocompact is thrashing: the context refilled to the limit...

Compaction کامیاب رہا، لیکن کسی فائل یا tool کے output نے کئی بار ونڈو کو دوبارہ بھر دیا، اس لیے Claude Code نے دوبارہ کوشش کرنا بند کر دی۔ اس مسئلے کو حل کرنے کے لیے oversized فائل کو line ranges میں پڑھیں، یا /compact کو اس focus کے ساتھ چلائیں جو بڑے output کو چھوڑ دے، اس کام کو subagent پر منتقل کریں، یا اگر پچھلا مکالمہ مکمل ہو چکا ہے تو /clear استعمال کریں۔

MCP servers fixed overhead ہیں

ہر منسلک MCP server پورے session کے ہر request پر اضافی بوجھ ڈالتا ہے۔ چاہے آپ اسے call کریں یا نہ کریں، اس کا اثر پڑتا ہے۔

Claude Code اس مسئلے کو کم کرتا ہے۔ MCP tool definitions default طور پر deferred ہوتی ہیں، اس لیے جب تک Claude کسی مخصوص tool کا استعمال نہیں کرتا، صرف tool names context میں شامل ہوتے ہیں۔ اپنے servers کی اصل cost دیکھنے کے لیے /context چلائیں، اور اگر آپ کسی server کو آج استعمال نہیں کرنا چاہتے تو اسے drop کرنے کے لیے /mcp disable <name> استعمال کریں۔ اگر آپ your own MCP servers on a VPS چلا رہے ہیں، تو وہی حساب کتاب اس بات کو محدود کرتا ہے کہ ایک server کو کتنے tools expose کرنے چاہئیں۔

یہ کام session کے آغاز میں کریں۔ جب تک definitions deferred رہتی ہیں، server کو connect یا disconnect کرنے سے صرف conversation میں اضافہ ہوتا ہے اور cache برقرار رہتا ہے۔ لیکن اگر definitions prefix میں load ہو جاتی ہیں (کیونکہ tool search off ہے یا server deferral سے مستثنیٰ ہے)، تو اسی تبدیلی کی وجہ سے اگلی request میں سب کچھ دوبارہ read کرنا پڑے گا۔

Context میں داخل ہونے سے پہلے verbose tool output کو filter کریں

Tool کا result input بن جاتا ہے، اور ہر اگلے turn پر input دوبارہ بھیجا جاتا ہے۔ اگر کسی test run کا output 20,000 tokens پر مشتمل ہے، تو یہ صرف ایک بار کا खर्च نہیں ہے: جب تک وہ window سے باہر نہیں نکل جاتا، آپ کو ہر turn پر اس کے لیے دوبارہ ادائیگی کرنی پڑتی ہے۔

Source پر ہی filter کریں۔ ایک ایسا hook جو test run کو Claude کے دیکھنے سے پہلے صرف failures تک محدود کر دے، اس output کی دیوار کو چند سو tokens میں تبدیل کر دیتا ہے، اس turn پر بھی اور اس کے ہر resend پر بھی:

npm test 2>&1 | grep -E "FAIL|Error:" | head -40

Hooks خود کبھی context میں داخل نہیں ہوتے، کیونکہ وہ code کے طور پر چلتے ہیں۔ ایسا ان تمام tools کے لیے کریں جن کا output screen سے تجاوز کر جاتا ہے۔ یہی منطق 3,000-line والی file پر بھی لاگو ہوتی ہے: صرف وہی line range مانگیں جس کی آپ کو ضرورت ہے، کیونکہ ایک بار آنے کے بعد پوری file window میں رہتی ہے۔

Agent کے پڑھنے کے دائرہ کار (Scope) کا تعین کریں، اور زیادہ ڈیٹا والے کاموں کو سپہ سالار (Delegate) کریں

اگر پرامپٹ (Prompt) میں فائل کا نام اور علامت (Symptom) درج ہو، تو ایجنٹ صرف اسی فائل کو پڑھے گا۔ اگر پرامپٹ پروجیکٹ کو ترتیب دینے (Tidy) کے لیے کھلا ہو، تو ایجنٹ اپنی مرضی سے متعلقہ فائلیں پڑھے گا۔ ان تمام فائلوں کا ڈیٹا ونڈو میں موجود رہتا ہے۔

زیادہ تفصیلات والے کاموں کے لیے سب ایجنٹ (Subagent) کا استعمال کریں۔ ٹیسٹ رنز (Test runs) اور لاگ پروسیسنگ (Log processing) دونوں ہی کافی کنٹیکسٹ (Context) استعمال کرتے ہیں۔ سب ایجنٹ اس آؤٹ پٹ کو اپنی ونڈو میں رکھتا ہے اور صرف ایک خلاصہ (Summary) واپس کرتا ہے۔ اس کا نقصان یہ ہے کہ سب ایجنٹ پہلی کال پر اپنا الگ کیش (Cache) بناتا ہے جس میں کوئی ہٹ (Hit) نہیں ہوتا، اور سبسکرپشن کے باوجود یہ 5 منٹ کا کیش لائف ٹائم استعمال کرتا ہے۔ ڈیلگیشن (Delegation) آپ کے مین کنٹیکسٹ (Main context) کو محفوظ رکھتی ہے۔ یہ ضروری نہیں کہ اس سے ٹوٹل ٹاکنز (Total tokens) میں کمی آئے۔

Cache clock: stints mein kaam karein

Prompt caching ki wajah se resend sasta hota hai: prefix parhne ke liye base input rate ka 0.1x, likhne ke liye 1.25x, ya ek ghante ki lifetime ke liye 2x charge hota hai. Har istemal entry ko baghair kisi izafi maliyat ke refresh kar deta hai, is liye clock aakhri istemal se chalti hai.

Aapko kaunsi lifetime milegi yeh aapke authentication par munhasir hai. Is liye yeh kehna ke "aapka cache panch minute baad expire ho jata hai" ghalat hai.

• Claude subscription par, Claude Code khudkar taur par ek ghante ki lifetime request karta hai.
• Jab aap apne plan ki limit khatam kar lete hain aur usage credits istemal karte hain, to aapko us usage ke liye bill diya jata hai, is liye yeh wapas panch minute par aa jata hai.
• API key ya cloud provider par, yeh panch minute par rehta hai. ENABLE_PROMPT_CACHING_1H=1 ek ghante ki lifetime ka intekhab karta hai, aur FORCE_PROMPT_CACHING_5M=1 ise wapas kam kar deta hai.

Dono suraton mein kaam karne ka mashwara ek hi hai: musalsal stints mein kaam karein, kyunke lifetime ke baad ka koi bhi idle gap aapke agle turn mein poore accumulated prefix ko dobara likhne par majboor kar deta hai. Ek tmux mein detached Claude Code session idle rehte hue kuch kharch nahi karta, aur warm cache wahi hai jo idle time se milta hai.

Kuch actions aapke kaam ke dauran cache ko khatam kar dete hain: models ko switch karna, effort level badalna, fast mode on karna, MCP server ko connect ya disconnect karna, plugin ko enable ya disable karna, kisi tool ko deny karna, compacting, aur Claude Code ko upgrade karna. /model ek aam surprise hai, kyunke har model ka apna cache hota hai, is liye agla request poori history ko parhta hai aur cache hits zero hote hain halanke content bilkul wahi hota hai.

Files ko edit karna, CLAUDE.md ko edit karna, skills aur commands ko invoke karna, /recap chalana, rewinding, aur subagent spawn karna, sab cache ko barqarar rakhte hain. Yeh ek machine aur ek directory tak mehdood hai, is liye mukhtalif directories mein chalne wale do sessions ek dusre ka cache istemal nahi kar sakte.

Yeh dekhne ke liye ke caching kaam kar rahi hai ya nahi, current_usage parhein. cache_creation_input_tokens cache write rate par likha gaya tha; cache_read_input_tokens standard input rate ke taqreeban ek daswan hisse par serve kiya gaya tha. High read-to-creation ratio behtar hai. Agar creation har turn ke baad high rehti hai, to iska matlab hai ke aapke prefix mein kuch badal raha hai.

کیا بڑا context window اس مسئلے کو حل کر دیتا ہے؟

کچھ حد تک۔ کئی موجودہ models 1 million token کے context window کو سپورٹ کرتے ہیں، اور بڑے limit پر بھی compaction اسی طرح کام کرتا ہے۔ اس سے معاشی صورتحال تبدیل نہیں ہوتی، کیونکہ مکمل prompt ہر بار دوبارہ بھیجا جاتا ہے اور ہر turn پر اس کے پیسے کٹتے ہیں۔ بڑا window یہ طے کرتا ہے کہ آپ کو کب کارروائی کرنے پر مجبور کیا جائے گا؛ hygiene یہ طے کرتی ہے کہ قیمت کیا ہوگی۔ اگر مسئلہ limit کے بجائے بل ہے، تو جو Claude plan آپ کے کام کے مطابق ہو یہ طے کرے گا کہ آپ ڈالرز خرچ کر رہے ہیں یا plan allowance۔

API میں Context editing اور compaction دو الگ چیزیں ہیں

اگر آپ Messages API پر اپنا agent بنا رہے ہیں، تو اس میں کوئی slash commands موجود نہیں ہوتیں اور آپ کو یہ خود نافذ کرنا ہوگا۔ دو server-side فیچرز یہ کام انجام دیتے ہیں، اور یہ دونوں ایک ہی فیچر نہیں ہیں۔

Context editing گفتگو کی ہسٹری بڑھنے کے ساتھ ساتھ مخصوص مواد کو منتخب طریقے سے صاف کرتی ہے۔ یہ ہر صاف کیے گئے نتیجے کی جگہ placeholder text استعمال کرتی ہے تاکہ Claude کو معلوم ہو سکے کہ کچھ ہٹا دیا گیا ہے۔ یہ ایک beta فیچر ہے: anthropic-beta: context-management-2025-06-27 بھیجیں اور context_management.edits کے تحت strategies کنفیگر کریں۔ clear_tool_uses_20250919 tool results کو صاف کرتا ہے، اور clear_thinking_20251015 thinking blocks کو مینیج کرتا ہے۔ اس کا trigger 100,000 input tokens پر default ہے، keep آخری 3 tool uses پر، اور clear_tool_inputs false پر، تاکہ inputs برقرار رہیں اور صرف results ہٹ جائیں۔

Compaction ایک خلاصہ (summary) تیار کرتا ہے اور پوری گفتگو کی ہسٹری کو اس سے بدل دیتا ہے۔ یہ بھی ایک beta فیچر ہے: anthropic-beta: compact-2026-01-12 بھیجیں اور compact_20260112 edit type استعمال کریں۔ اس کا trigger {"type": "input_tokens", "value": 150000} پر default ہے، اور اس کی value کم از کم 50,000 ہونی چاہیے۔

Compaction کا ایک handoff rule ہے جو agents کو خاموشی سے خراب کر دیتا ہے۔ response کا آغاز ایک compaction content block سے ہوتا ہے جس میں summary ہوتی ہے، جس کے بعد عام text block آتا ہے۔ آپ کو بعد کی requests میں وہ block واپس بھیجنا ہوگا، جس کے بعد API اس سے پہلے کے تمام content blocks کو हटा دیتا ہے۔ عملی طور پر: صرف text نہیں، بلکہ مکمل response.content شامل کریں۔

Anthropic کی documentation میں server-side compaction کو طویل گفتگو میں context مینیج کرنے کے لیے بنیادی حکمت عملی قرار دیا گیا ہے، جبکہ context editing کو اس چیز پر باریک کنٹرول حاصل کرنے کا آپشن کہا گیا ہے کہ کیا صاف کیا جائے۔ پہلے model support چیک کریں۔ موجودہ Opus، Sonnet اور Fable models compaction کو سپورٹ کرتے ہیں؛ claude-haiku-4-5 نہیں کرتا، اور compaction page پر لائیو لسٹ موجود ہے۔ ان دونوں beta فیچرز سے Claude Code کا اپنا /compact نہیں چلتا، جسے اس کی documentation میں client کی طرف سے بھیجی گئی ایک one-off summarization request کے طور پر بیان کیا گیا ہے۔

FAQ

Claude Code کا سیشن جتنا طویل ہوتا ہے، وہ اتنا ہی سست اور مہنگا کیوں ہوتا ہے؟

کیونکہ ہر نئے موڑ پر پوری گفتگو دوبارہ بھیجی جاتی ہے۔ اس طرح، اگر سیشن پورا دن کھلا رہا ہے، تو ایک لائن کا سوال بھی پورے دن کی گفتگو کے ساتھ جائے گا۔ Prompt caching اس عمل کو سستا رکھتی ہے جب تک cache گرم (warm) رہتا ہے، کیونکہ ریڈ (read) کے لیے یہ base input rate کے 0.1x کے برابر ہوتا ہے۔ ایک بار جب کوئی موڑ cache کو مس کر دیتا ہے، تو وہی prefix 1.25x کی شرح سے دوبارہ لکھا جاتا ہے۔ یہ دیکھنے کے لیے کہ ونڈو میں کیا بھر رہا ہے /context چلائیں، اور طریقہ کار جاننے کے لیے Claude Code سیشن آپ سے کس چیز کے پیسے لیتا ہے پڑھیں۔

Claude Code میں /clear اور /compact کے درمیان کیا فرق ہے؟

/clear خالی context کے ساتھ ایک نئی گفتگو شروع کرتا ہے۔ یہ کوئی درخواست (request) نہیں بھیجتا، اس لیے اس کی کوئی قیمت نہیں ہوتی، اور غیر متعلقہ کاموں کے درمیان یہ بہترین انتخاب ہے۔ /compact اسی گفتگو کو برقرار رکھتا ہے اور ہسٹری کو خلاصے (summary) سے بدل دیتا ہے، اس لیے یہ ایک طویل کام کے دوران استعمال کے لیے موزوں ہے۔ اسے ایک مقصد دیں، جیسا کہ /compact keep only the plan and the diff میں ہے، کیونکہ ہدایات ہی یہ فیصلہ کرتی ہیں کہ کیا محفوظ رہے گا۔

میں کیسے دیکھ سکتا ہوں کہ میرا Claude Code context window کیا استعمال کر رہا ہے؟

/context چلائیں، یا ہر آئٹم کی مکمل تفصیل کے لیے /context all استعمال کریں۔ یہ سسٹم پرامپٹ، tool definitions، MCP servers، memory files، اور ہسٹری کو رنگین گرڈ کے طور پر دکھاتا ہے، اور context-heavy tools اور memory bloat کے لیے تجاویز بھی دیتا ہے۔ پیڈ پلان پر، /usage حالیہ استعمال کو انفرادی skills، subagents اور MCP servers کے ساتھ بھی منسوب کرتا ہے۔

کیا مجھے compaction کے بجائے 1 million token context window استعمال کرنی چاہیے؟

بڑا ونڈو مسئلے کو حل کرنے کے بجائے اسے دیر سے ظاہر کرتا ہے۔ کئی موجودہ ماڈلز 1 million token context window کے ساتھ چلتے ہیں، جن میں Opus 4.8 اور Sonnet 5 شامل ہیں، اور وہاں بھی compaction اسی طرح کام کرتا ہے۔ ہر موڑ پر اب بھی پورا پرامپٹ دوبارہ بھیجا جاتا ہے اور اس کے پیسے بھی لیے جاتے ہیں، اس لیے 400,000-token والی گفتگو مہنگی ہوتی ہے چاہے وہ ونڈو میں فٹ آئے یا نہ آئے۔

Claude API میں context editing اور compaction کے درمیان کیا فرق ہے؟

Context editing پرانے مواد کو، زیادہ تر tool results کو، منتخب طور پر صاف کرتا ہے، اور جہاں وہ تھا وہاں placeholder text چھوڑ دیتا ہے تاکہ Claude کو معلوم ہو کہ اسے ہٹا دیا گیا ہے۔ Compaction ایک خلاصہ تیار کرتا ہے اور پوری ہسٹری کو اس سے بدل دیتا ہے۔ Anthropic کی دستاویزات compaction کو طویل گفتگو کے لیے بنیادی حکمت عملی قرار دیتی ہیں، اور context editing کو ایک باریک بینی (fine-grained) والا آپشن قرار دیتی ہیں۔ یہ دونوں بيٹا ورژن ہیں اور ان کے اپنے ہی headers ہیں، اور دونوں Claude Code کے /compact سے الگ ہیں۔