Claude Code کا سست اور مہنگا session کیسے روکیں

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

Claude Code کا طویل session سست اور مہنگا اس لیے ہو جاتا ہے کہ ہر turn میں پورا context دوبارہ بھیجا جاتا ہے، اور یہ context مسلسل بڑھتا رہتا ہے۔ اس کا حل ایک مقررہ ترتیب کے ساتھ hygiene ہے۔ window میں کیا چیزیں جگہ لے رہی ہیں، یہ دیکھنے کے لیے /context چلائیں۔ ہر request پر جن items کی ادائیگی ہوتی ہے، انہیں کم کریں۔ پھر غیر متعلقہ tasks کے درمیان /clear اور ایک ہی طویل task کے اندر کسی instruction کے ساتھ /compact استعمال کریں۔ مسلسل stints میں کام کریں، کیونکہ cold prompt cache سستی read کو آپ کی کہی ہوئی ہر بات کی مکمل re-write میں بدل دیتا ہے۔

یہ meter آخر چلتا کیوں ہے، اس کا جواب agent session کے پیچھے موجود token meter میں ہے۔

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

ونڈو میں کیا بھر رہا ہے، اس کا اندازہ نہ لگائیں۔ Claude Code آپ کو بتائے گا۔

/context [all] موجودہ context usage کو رنگین grid کی صورت میں دکھاتا ہے اور context-heavy tools اور memory bloat کے لیے optimization suggestions فراہم کرتا ہے؛ all fullscreen mode میں ہر item کی تفصیل کو وسیع کرتا ہے۔ نتیجے کو پانچ buckets کے طور پر پڑھیں۔

• System prompt۔ Claude Code کی اپنی harness instructions۔ یہ session کے لیے fixed ہوتی ہیں۔
• Tool definitions۔ ہر اس tool کا schema جسے agent call کر سکتا ہے، بشمول ہر connected MCP (Model Context Protocol) server۔
• Memory files۔ CLAUDE.md اور auto memory، جو session شروع ہونے پر load ہوتی ہیں۔
• Files and tool results۔ ہر پڑھی گئی file، اور ہر وہ output جو آپ کے commands نے واپس print کیا۔
• Message history۔ آپ کی turns اور اس کے 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 reject ہو جاتی ہے؛ اس سے متعلقہ 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 کو انفرادی skills، subagents اور MCP servers سے منسوب کرتا ہے۔ اگر یہ بتائے کہ allowance پہلے ہی خرچ ہو چکا ہے تو آپ کس limit window کے ختم ہونے کا انتظار کر رہے ہیں اس بات کا فیصلہ کرتا ہے کہ context کم کرنے سے ابھی مدد ملے گی یا کام دوبارہ شروع کرنے کے لیے آپ کو کوئی مختلف راستہ درکار ہے۔

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

آپ کی CLAUDE.md سیشن شروع ہوتے وقت context میں load ہوتی ہے اور وہیں رہتی ہے۔ اگر اس میں deployment کا تفصیلی طریقۂ کار موجود ہو تو test file میں معمولی typo درست کرتے وقت بھی وہ tokens موجود رہتے ہیں۔ Anthropic کی ہدایت ہے کہ صرف ضروری معلومات شامل کریں اور file کو 200 lines سے کم رکھیں۔

طریقۂ کار کو skills میں منتقل کریں۔ skill صرف invoke ہونے پر load ہوتی ہے، اس لیے ہفتے میں 2 بار چلایا جانے والا workflow باقی دنوں میں کوئی لاگت نہیں ڈالتا۔ compaction کے بعد skills کا اپنا budget ہوتا ہے: ہر skill کے لیے زیادہ سے زیادہ 5,000 tokens اور مجموعی طور پر 25,000 tokens۔ پرانی skills پہلے خارج ہوتی ہیں۔ truncation file کا ابتدائی حصہ برقرار رکھتی ہے، اس لیے اہم ترین ہدایات SKILL.md کے قریب اوپر رکھیں۔

compaction کے بعد کیا برقرار رہتا ہے، اس سے طے ہوتا ہے کہ instruction کہاں رکھنی چاہیے۔

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

اس لیے جس rule پر آپ انحصار کرتے ہیں، اسے project-root CLAUDE.md میں رکھیں: Claude Code پہلے پرانے tool outputs صاف کرتا ہے اور پھر خلاصہ بناتا ہے، اس لیے گفتگو کے ابتدائی حصے کی instructions ضائع ہو سکتی ہیں۔ memory میں ترمیم /memory سے کریں۔ Claude Code وہ copy سیشن شروع ہوتے وقت load کرتا ہے، اس لیے سیشن کے دوران کیا گیا trim prompt cache کو برقرار رکھتا ہے اور اگلے /clear، /compact یا restart تک نافذ نہیں ہوتا۔ context کا ضائع ہونا rule پر عمل رکنے کی صرف ایک وجہ ہے، اس لیے جب rule واضح طور پر window میں موجود ہو لیکن پھر بھی نظرانداز ہو، تو اسے دوبارہ لکھنے سے پہلے دیگر وجوہات کا جائزہ لیں۔

کاموں کے درمیان /clear [name]، ایک کام کے اندر /compact [instructions]

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

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

/compact [instructions] اسی گفتگو کو جاری رکھتے ہوئے context خالی کرتا ہے: یہ اب تک کی history کا خلاصہ بناتا ہے اور اسے summary سے replace کر دیتا ہے۔ اسے ایک ہی طویل کام کے اندر استعمال کریں، جہاں تسلسل برقرار رکھنا ضروری ہو۔

/compact کو ہمیشہ instruction دیں۔ صرف /compact چلانے سے ایک default prompt کے خلاف خلاصہ بنتا ہے، جسے معلوم نہیں ہوتا کہ کام کے کس حصے کی آپ کو اب بھی ضرورت ہے۔ Instruction کے ساتھ چلایا گیا /compact یہ context برقرار رکھتا ہے:

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

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

یہاں دو لاگتیں آپس میں خلط ملط ہو جاتی ہیں۔ Summarization request آپ کے prefix کو share کرتی ہے، اس لیے یہ history کو دوبارہ process کرنے کے بجائے موجودہ cache پڑھتی ہے، اور اس کا زیادہ وقت summary generate کرنے میں صرف ہوتا ہے۔ بڑے context کو compact کرنا پھر بھی بڑی request ہے، کیونکہ جس conversation کا خلاصہ بنایا جا رہا ہے وہی input ہے۔ Compaction کے بعد والا turn سست حصہ نہیں ہوتا: یہ بہت مختصر prompt کے لیے cache دوبارہ بناتا ہے۔

دو کم لاگت commands بھی موجود ہیں۔ /rewind [description] code اور conversation کو checkpoint تک واپس لے جاتا ہے؛ جس path کو آپ مکمل طور پر ترک کرنا چاہتے ہوں، اس کے لیے یہ compact کرنے سے بہتر ہے، کیونکہ یہ ایسے prefix تک واپس truncate کرتا ہے جو پہلے ہی cached ہوتا ہے۔ /recap history کو replace کرنے کے بجائے summary کو command output کے طور پر append کرتا ہے، اس لیے cached prefix برقرار رہتا ہے۔

Automatic compaction بار بار چلنے پر یہ output دکھائی دیتا ہے:

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

Compaction کامیاب ہو گئی، لیکن کسی file یا tool output نے window کو مسلسل کئی بار دوبارہ بھر دیا، اس لیے Claude Code نے دوبارہ کوشش کرنا روک دیا۔ Recovery کے لیے بڑی file کو line ranges میں پڑھیں، /compact کو ایسے focus کے ساتھ چلائیں جو بڑے output کو خارج کر دے، اس کام کو subagent میں منتقل کریں، یا /clear استعمال کریں اگر پچھلی conversation اب ضروری نہیں رہی۔

MCP servers مستقل اضافی لاگت رکھتے ہیں

آپ جس ہر MCP server سے connect کرتے ہیں، وہ پورے session کی ہر request میں شامل ہوتا ہے۔ اس کی لاگت آپ کو تب بھی ادا کرنی پڑتی ہے جب آپ اسے استعمال نہ کریں۔

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

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

ٹول کے تفصیلی output کو context میں داخل ہونے سے پہلے filter کریں

ٹول کا result ایک input ہوتا ہے، اور ہر اگلی turn پر یہ input دوبارہ send کیا جاتا ہے۔ ایسا test run جو 20,000 tokens کا output dump کرے، صرف ایک بار کی لاگت نہیں ہوتا؛ جب تک وہ window سے خارج نہ ہو، ہر turn پر اس کی دوبارہ لاگت آتی ہے۔

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

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

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

ایجنٹ کے پڑھنے کے دائرہ کار کو محدود کریں، اور زیادہ آؤٹ پٹ والا کام تفویض کریں

جس prompt میں file اور symptom کا نام دیا گیا ہو، وہ اسی file کو پڑھتا ہے۔ project کو صاف کرنے کی کھلی درخواست میں ایجنٹ اپنی صوابدید سے متعلقہ files پڑھتا ہے، اور ان تمام reads کا متن window میں برقرار رہتا ہے۔

زیادہ آؤٹ پٹ والا کام subagent کو تفویض کریں۔ Test runs اور log processing دونوں حقیقی context استعمال کرتے ہیں؛ subagent یہ output اپنی window میں رکھتا ہے اور صرف summary واپس کرتا ہے۔ اس کا تقاضا یہ ہے کہ subagent اپنا cache بناتا ہے، جس میں پہلی call پر کوئی cache hit نہیں ہوتا، اور subscription کے باوجود پانچ منٹ کی cache lifetime استعمال ہوتی ہے۔ Delegation آپ کے main context کو قابل اعتماد طریقے سے محفوظ رکھتی ہے۔ تاہم، اس سے total tokens ہمیشہ کم نہیں ہوتے۔

کیش کی گھڑی: مسلسل ادوار میں کام کریں

Prompt caching ہی resend کو کم خرچ بناتی ہے: prefix پڑھنے کے لیے base input rate کا 0.1x، اسے لکھنے کے لیے 1.25x، اور one-hour lifetime پر لکھنے کے لیے 2x۔ ہر استعمال پر entry بغیر اضافی لاگت کے تازہ ہو جاتی ہے، اس لیے گھڑی آخری استعمال سے دوبارہ چلتی ہے۔ یہ multipliers بل کی نوعیت بتاتے ہیں، مگر اس کا حجم نہیں؛ اس لیے انہیں ایک million tokens کی اصل لاگت کے ساتھ ملا کر پورے context window کو dollars کی رقم میں تبدیل کریں۔

آپ کو کون سی lifetime ملتی ہے، اس کا انحصار authentication کے طریقے پر ہے۔ اسی لیے یہ عمومی بیان غلط ہے کہ "آپ کا cache پانچ منٹ بعد expire ہو جاتا ہے"۔

• Claude subscription پر Claude Code خودکار طور پر one-hour lifetime کی درخواست کرتا ہے۔
• جب آپ اپنے plan کی limit سے آگے بڑھ کر usage credits استعمال کرتے ہیں تو اس استعمال کی billing ہوتی ہے، اس لیے lifetime دوبارہ پانچ منٹ ہو جاتی ہے۔
• API key یا cloud provider پر lifetime پانچ منٹ رہتی ہے۔ ENABLE_PROMPT_CACHING_1H=1 one-hour lifetime فعال کرتا ہے، جبکہ FORCE_PROMPT_CACHING_5M=1 اسے دوبارہ پانچ منٹ کر دیتا ہے۔

دونوں صورتوں میں کام کرنے کا اصول ایک ہی ہے: مسلسل ادوار میں کام کریں، کیونکہ lifetime سے زیادہ طویل idle gap کے بعد اگلی turn پورے جمع شدہ prefix کو دوبارہ لکھتی ہے۔ ایک tmux میں detached Claude Code session idle حالت میں کوئی لاگت نہیں رکھتا، جبکہ warm cache ہی وہ چیز ہے جس سے idle وقت دست بردار ہو جاتا ہے۔

کچھ actions آپ کے کام جاری رہنے کے دوران بھی cache ختم کر دیتے ہیں: models تبدیل کرنا، effort level بدلنا، fast mode فعال کرنا، MCP server سے connect یا disconnect کرنا، plugin فعال یا غیر فعال کرنا، پورے tool کو deny کرنا، compacting، اور Claude Code کو upgrade کرنا۔ /model عموماً غیر متوقع سبب بنتا ہے، کیونکہ ہر model کا اپنا cache ہوتا ہے۔ اس لیے اگلی request پوری history کو cache hits کے بغیر پڑھتی ہے، حالانکہ content یکساں ہوتا ہے۔ اس دوبارہ reading کی billing destination model کے rates پر ہوتی ہے، لہٰذا session کے درمیان Fable پر switch کرنے سے آپ کی پوری جمع شدہ history کی billing Fable 5 کے شائع شدہ input rate پر ہوتی ہے۔

Files میں editing، CLAUDE.md میں editing، skills اور commands چلانا، /recap چلانا، rewinding، اور subagent شروع کرنا cache برقرار رکھتے ہیں۔ یہ ایک machine اور ایک directory تک محدود ہوتا ہے، اس لیے مختلف directories میں چلنے والی دو sessions ایک دوسرے کا cache استعمال نہیں کرتیں۔ یہ scope آپ کے account کے بجائے CLI کے ساتھ منسلک ہوتا ہے، اس لیے اس کا کوئی حصہ Claude desktop app میں منتقل نہیں ہوتا؛ Linux پر یہ CLI کے ساتھ ایک الگ beta install ہے۔

یہ جانچنے کے لیے کہ caching کام کر رہی ہے، current_usage پڑھیں۔ cache_creation_input_tokens کو cache write rate پر لکھا گیا تھا؛ cache_read_input_tokens کو تقریباً standard input rate کے دسویں حصے پر serve کیا گیا۔ read-to-creation ratio کا زیادہ ہونا صحت مند علامت ہے۔ اگر creation ہر turn میں زیادہ رہتی ہے تو آپ کے prefix میں کوئی چیز مسلسل تبدیل ہو رہی ہے۔

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

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

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

اگر آپ Messages API پر اپنا agent بنا رہے ہیں تو slash commands موجود نہیں ہوتیں، اور یہ کام آپ کو خود implement کرنا ہوگا۔ اس کام کا بجٹ شروع ہی سے رکھیں، کیونکہ چھوٹے signup credit کے علاوہ API میں کوئی free tier نہیں ہے؛ اس لیے غیر مختصر history کا ہر turn مکمل طور پر bill ہوتا ہے۔ آپ جس provider پر build کرتے ہیں، وہ trimming سے پہلے ہی اس حساب کو متعین کر دیتا ہے۔ اگر انتخاب ابھی باقی ہے تو دونوں APIs پر اسی workload کی لاگت معلوم کریں، صرف نمایاں per-token rates کا موازنہ نہ کریں۔ یہ کام server-side کی 2 features کرتی ہیں، اور یہ ایک ہی feature نہیں ہیں۔

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

Compaction ایک summary بناتا ہے اور مکمل conversation history کو اس summary سے replace کر دیتا ہے۔ یہ بھی beta ہے: anthropic-beta: compact-2026-01-12 بھیجیں اور compact_20260112 edit type استعمال کریں۔ trigger کی default قدر {"type": "input_tokens", "value": 150000} ہے، اور value کم از کم 50,000 ہونی چاہیے۔

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

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

FAQ

میری Claude Code session جوں جوں چلتی رہتی ہے، سست اور زیادہ مہنگی کیوں ہو جاتی ہے؟

کیونکہ ہر turn پر پوری conversation دوبارہ بھیجی جاتی ہے۔ اس لیے اگر session سارا دن کھلی رہی ہو تو ایک سطری سوال کے ساتھ پورے دن کی conversation بھی شامل ہوتی ہے۔ Prompt caching اس وقت لاگت کم رکھتی ہے جب cache گرم ہو؛ read کے لیے base input rate کا 0.1x لاگو ہوتا ہے۔ جب کسی turn میں cache miss ہو جائے تو یہی prefix 1.25x rate پر دوبارہ لکھا جاتا ہے۔ window میں کیا شامل ہے، یہ دیکھنے کے لیے /context چلائیں، اور طریقۂ کار کے لیے Claude Code session کی billing کی تفصیل پڑھیں۔

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

/clear خالی context کے ساتھ نئی conversation شروع کرتا ہے۔ یہ کوئی request نہیں بھیجتا، اس لیے اس کی کوئی لاگت نہیں ہوتی، اور غیر متعلقہ tasks کے درمیان یہی درست انتخاب ہے۔ /compact وہی conversation برقرار رکھتا ہے اور history کو ایک summary سے بدل دیتا ہے، اس لیے ایک ہی طویل task کے اندر یہ درست انتخاب ہے۔ اسے focus دیں، جیسا کہ /compact keep only the plan and the diff میں ہے، کیونکہ instruction طے کرتی ہے کہ کیا برقرار رہے گا۔

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

/context چلائیں، یا ہر item کی مکمل تفصیل کے لیے /context all چلائیں۔ یہ system prompt، tool definitions، MCP servers، memory files اور history کو رنگین grid میں دکھاتا ہے، ساتھ ہی context-heavy tools اور memory bloat کے لیے تجاویز بھی دیتا ہے۔ paid plan پر /usage حالیہ usage کو انفرادی skills، subagents اور MCP servers سے بھی منسوب کرتا ہے۔

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

بڑا window مسئلے کو حل کرنے کے بجائے مؤخر کرتا ہے۔ کئی موجودہ models، جن میں Opus 4.8 اور Sonnet 5 بھی شامل ہیں، 1 million token کا context window چلاتے ہیں، اور وہاں بھی compaction اسی طرح کام کرتی ہے۔ ہر turn پر مکمل prompt دوبارہ بھیجا جاتا ہے اور اس کی billing بھی جاری رہتی ہے۔ اس لیے 400,000-token conversation مہنگی رہتی ہے، چاہے وہ window میں فٹ ہو یا نہ ہو۔

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

Context editing پرانا content، بالخصوص tool results، منتخب کر کے صاف کرتی ہے اور ہر item کی جگہ placeholder text چھوڑتی ہے تاکہ Claude کو معلوم رہے کہ اسے ہٹا دیا گیا ہے۔ Compaction ایک summary بناتی ہے اور مکمل history کو اس summary سے بدل دیتی ہے۔ Anthropic کی documentation compaction کو طویل عرصے تک چلنے والی conversations کے لیے بنیادی strategy قرار دیتی ہے اور context editing کو باریک سطح پر کنٹرول دینے والا option بتاتی ہے۔ دونوں beta features ہیں اور دونوں کے اپنے headers ہیں۔ دونوں Claude Code کے /compact سے الگ ہیں۔