Claude Code session ধীর ও ব্যয়বহুল হওয়া বন্ধ করুন

দীর্ঘ Claude Code session ধীর ও ব্যয়বহুল হওয়া কীভাবে বন্ধ করবেন

দীর্ঘ Claude Code session ধীর ও ব্যয়বহুল হয়, কারণ প্রতিটি turn-এ সম্পূর্ণ context আবার পাঠানো হয় এবং সেই context ক্রমেই বড় হতে থাকে। এর সমাধান হলো নির্দিষ্ট ক্রমে context hygiene বজায় রাখা। কোন বিষয়গুলো window পূরণ করছে তা দেখতে /context চালান। প্রতিটি request-এ যেসব বিষয়ের জন্য অর্থ দিতে হয়, সেগুলো কমান। এরপর সম্পর্কহীন task-এর মাঝখানে /clear ব্যবহার করুন এবং একই দীর্ঘ task-এর মধ্যে নির্দেশনা দিতে /compact ব্যবহার করুন। কাজ একটানা stint-এ করুন, কারণ cold prompt cache থাকলে সস্তা একটি read আপনার বলা সবকিছু সম্পূর্ণভাবে আবার লিখতে বাধ্য করে।

কেন meter গণনা করে, তার উত্তর আছে agent session-এর পেছনের token meter-এ।

পরিবর্তনের আগে /context পড়ুন

উইন্ডোতে কী আছে তা অনুমান করবেন না। Claude Code আপনাকে তা জানাবে।

/context [all] বর্তমান context usage একটি রঙিন grid হিসেবে দেখায়। এটি context-heavy tool ও memory bloat কমানোর পরামর্শও দেয়। all fullscreen mode-এ প্রতিটি item-এর বিস্তারিত breakdown দেখায়। ফলাফলটি পাঁচটি bucket হিসেবে পড়ুন।

• System prompt। Claude Code-এর নিজস্ব harness instruction। এটি session জুড়ে অপরিবর্তিত থাকে।
• Tool definitions। Agent যে প্রতিটি tool call করতে পারে, সেগুলোর schema। এতে সংযুক্ত প্রতিটি MCP (Model Context Protocol) server-ও অন্তর্ভুক্ত।
• Memory files। Session শুরুতে load হওয়া CLAUDE.md এবং auto memory।
• Files and tool results। পড়া প্রতিটি file এবং আপনার command-এর output হিসেবে ফিরে আসা সবকিছু।
• Message history। আপনার turn এবং Claude Code-এর reply।

প্রথম তিনটি session চলাকালীন প্রতিটি request-এ প্রযোজ্য একটি fixed tax। শেষ দুটি ক্রমশ বাড়ে। শুরুতেই একবার fixed tax কমান। ক্রমবর্ধমান অংশ নিয়মিত পরিচালনা করুন।

দুটি string জানায় যে 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 প্রত্যাখ্যাত হয়। সংশ্লিষ্ট API (application programming interface) error হলো Prompt is too long। দ্বিতীয়টি একটি compaction window। 1 million token-এর model-এ এটি প্রকৃত context window-এর নিচে থাকতে পারে। এটি অতিক্রম করার পরও request সফল হয়। তাই এটি refusal নয়, warning।

Paid plan-এ /usage আরও একটি অংশ যোগ করে। এটি long context বা cache miss-এর মতো behavior চিহ্নিত করে এবং সাম্প্রতিক usage পৃথক skill, subagent ও MCP server-এর সঙ্গে যুক্ত করে। যদি এটি জানায় যে allowance ইতিমধ্যে শেষ, তাহলে আপনি কোন limit window-এর জন্য অপেক্ষা করছেন তা নির্ধারণ করে context trim করলে এখন কাজ হবে কি না, নাকি কাজে ফেরার জন্য অন্য পথ নিতে হবে।

CLAUDE.md একটি স্থায়ী context খরচ, তাই এটিকে সংক্ষিপ্ত রাখুন

আপনার CLAUDE.md session শুরু হওয়ার সময় context-এ লোড হয় এবং সেখানেই থাকে। এতে যদি বিস্তারিত deployment procedure থাকে, তাহলে test file-এর একটি typo ঠিক করার সময়ও সেই token-গুলো context-এ উপস্থিত থাকে। Anthropic-এর নির্দেশনা হলো শুধু প্রয়োজনীয় বিষয় অন্তর্ভুক্ত করা এবং file-টি 200 lines-এর মধ্যে রাখা।

Procedure-গুলো skills-এ সরিয়ে নিন। কোনো skill শুধু invoke করলে লোড হয়, তাই সপ্তাহে দুবার চালানো workflow অন্য দিনগুলোতে কোনো খরচ তৈরি করে না। Compaction-এর পরে skills-এর নিজস্ব budget থাকে: প্রতি skill-এ সর্বোচ্চ 5,000 tokens এবং মোট 25,000 tokens; সবচেয়ে পুরোনোগুলো আগে বাদ পড়ে। Truncation file-এর শুরুর অংশ রেখে দেয়, তাই SKILL.md-এর শুরুতেই সবচেয়ে গুরুত্বপূর্ণ instruction রাখুন।

Compaction-এর পরে কোন বিষয় টিকে থাকে, তার ওপর নির্ভর করে instruction কোথায় রাখা উচিত।

• System prompt এবং output style অপরিবর্তিত থাকে, কারণ এগুলো message history-এর অংশ নয়।
• Project-root CLAUDE.md, unscoped rule এবং auto memory disk থেকে আবার inject করা হয়।
• paths: frontmatter-সহ কোনো rule আবার matching file পড়া না হওয়া পর্যন্ত হারিয়ে যায়।
• কোনো subdirectory-র nested CLAUDE.md সেই directory-র কোনো file আবার পড়া না হওয়া পর্যন্ত হারিয়ে যায়।
• Hook প্রভাবিত হয় না, কারণ hook code হিসেবে চলে এবং কখনো context-এ প্রবেশ করে না।

তাই যে rule-এর ওপর আপনি নির্ভর করেন, সেটি project-root CLAUDE.md-এ রাখা উচিত: Claude Code পুরোনো tool output আগে clear করে, তারপর summary তৈরি করে। ফলে conversation-এর শুরুর দিকের instruction হারিয়ে যেতে পারে। /memory দিয়ে memory edit করুন। Claude Code session শুরু হওয়ার সময় লোড করা copy ধরে রাখে, তাই mid-session trim prompt cache বজায় রাখে এবং পরবর্তী /clear, /compact বা restart না হওয়া পর্যন্ত কার্যকর হয় না। Context loss কোনো rule অনুসরণ বন্ধ হওয়ার একমাত্র কারণ নয়। তাই rule-টি window-তে স্পষ্টভাবে থাকা সত্ত্বেও উপেক্ষিত হলে, rewrite করার আগে অন্য কারণগুলো পরীক্ষা করে দেখুন।

কাজ বদলালে /clear, একই কাজের মধ্যে /compact

এই দুটি কমান্ড দেখতে একই রকম মনে হলেও খরচের পার্থক্য অনেক।

/clear [name] খালি context নিয়ে নতুন conversation শুরু করে। এটি কোনো request পাঠায় না, তাই কোনো খরচ হয় না। আগের conversation-টির নাম দিতে /resume picker-এ একটি নাম পাস করুন; /reset এবং /new হলো alias। সম্পর্কহীন কোনো কাজে যাওয়ার সঙ্গে সঙ্গে এটি ব্যবহার করুন। তা না হলে নতুন কাজের প্রতিটি message-এর সঙ্গে পুরোনো কাজটি আবার পাঠানো হবে এবং তার জন্য আবার বিল হবে।

/compact [instructions] একই conversation চালু রেখে context খালি করে। এটি এখন পর্যন্ত history-এর সারাংশ তৈরি করে এবং history-কে সেই সারাংশ দিয়ে প্রতিস্থাপন করে। একই দীর্ঘ কাজের মধ্যে continuity প্রয়োজন হলে এটি ব্যবহার করুন।

সবসময় /compact-কে একটি instruction দিন। শুধু /compact দিলে এমন একটি default prompt-এর ভিত্তিতে সারাংশ তৈরি হয়, যা আপনার কাজের কোন অংশটি এখনও প্রয়োজন তা জানে না। Instruction দিলে সেটি তা ধরে রাখে:

/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 শেয়ার করে, তাই history আবার process না করে বিদ্যমান cache পড়ে। ফলে এর বেশিরভাগ সময় summary তৈরি করতে ব্যয় হয়। বড় context compact করাও বড় request, কারণ যে conversation-এর সারাংশ তৈরি হচ্ছে সেটিই input। Compact করার পরের turn ধীর অংশ নয়; অনেক ছোট prompt-এর জন্য cache আবার তৈরি হয়।

আরও কম খরচের দুটি command আছে। /rewind [description] একটি checkpoint-এ code এবং conversation ফিরিয়ে নেয়। কোনো path সম্পূর্ণ পরিত্যাগ করতে চাইলে compact করার চেয়ে এটি ভালো, কারণ এটি ইতিমধ্যে cached prefix পর্যন্ত history truncate করে। /recap history প্রতিস্থাপন না করে command output হিসেবে একটি summary যোগ করে, তাই cached prefix অক্ষত থাকে।

Automatic compaction বারবার চালু হলে এটি দেখায়:

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

Compaction সফল হয়েছে, কিন্তু একটি file বা tool output পরপর কয়েকবার window পূর্ণ করে দিয়েছে। তাই Claude Code পুনরায় চেষ্টা করা বন্ধ করেছে। অতিরিক্ত বড় file-টি line range ধরে পড়ে, বড় output বাদ দেয় এমন focus দিয়ে /compact চালিয়ে, সেই কাজ subagent-এ সরিয়ে, অথবা আগের conversation শেষ হয়ে থাকলে /clear ব্যবহার করে পুনরুদ্ধার করুন।

MCP server-গুলো স্থির overhead তৈরি করে

আপনি যে প্রতিটি MCP server-এ সংযোগ করেন, সেটি পুরো session-এর প্রতিটি request-এর খরচ বাড়ায়। আপনি server-টির কোনো tool ব্যবহার না করলেও এই খরচ দিতে হয়।

Claude Code এই প্রভাব কমায়। MCP tool definition ডিফল্টভাবে deferred থাকে। তাই Claude নির্দিষ্ট কোনো tool ব্যবহার না করা পর্যন্ত শুধু tool name context-এ যুক্ত হয়। আপনার server-গুলোর প্রকৃত খরচ দেখতে /context চালান। আজ ব্যবহার করবেন না এমন server সরাতে /mcp disable <name> চালান। আপনি যদি নিজস্ব MCP server VPS-এ চালান, একই হিসাব নির্ধারণ করে যে একটি server-এ কতগুলো tool প্রকাশ করা উচিত।

Session-এর শুরুতেই এটি করুন। Definition deferred থাকা অবস্থায় server সংযোগ বা বিচ্ছিন্ন করলে তা শুধু conversation-এ যুক্ত হয়, এবং cache অক্ষত থাকে। এর পরিবর্তে definition prefix-এ load হলে—tool search বন্ধ থাকার কারণে বা কোনো server deferral থেকে exempt হওয়ায়—একই পরিবর্তনের ফলে পরবর্তী request-এ সবকিছু আবার পড়তে হয়।

Context-এ ঢোকার আগে verbose tool output filter করুন

Tool result একটি input, এবং পরবর্তী প্রতিটি turn-এ সেই input আবার পাঠানো হয়। 20,000 tokens-এর output তৈরি করা একটি test run একবারের খরচ নয়: output-টি window থেকে বের না হওয়া পর্যন্ত প্রতিটি turn-এ এর জন্য আবার খরচ হয়।

Source-এই filter করুন। Claude output দেখার আগে কোনো hook যদি test run-এর ফলাফলকে শুধু failure-এ কমিয়ে আনে, তাহলে এই বিপুল output এই turn-এ এবং পরবর্তী প্রতিটি resend-এ কয়েক শ tokens-এ নেমে আসে:

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

Hook নিজে context-এ ঢোকে না, কারণ এটি code হিসেবে চলে। যে কোনো tool-এর output একটি screen-এর বেশি হলে একই পদ্ধতি ব্যবহার করুন। 3,000-line file-এর ক্ষেত্রেও এই যুক্তি প্রযোজ্য: আপনার প্রয়োজনীয় line range চাইুন, কারণ পুরো file এসে গেলে সেটি window-এ থেকে যায়।

এজেন্ট কী পড়বে তা নির্ধারণ করুন এবং বেশি শব্দের কাজ অর্পণ করুন

যে prompt-এ ফাইলের নাম ও সমস্যার লক্ষণ উল্লেখ থাকে, সেটি ওই ফাইল পড়ে। প্রকল্প গুছিয়ে দেওয়ার মতো উন্মুক্ত অনুরোধে এজেন্ট প্রাসঙ্গিক মনে করা যেকোনো বিষয় পড়ে, এবং প্রতিটি পড়ার ফল window-তে থেকে যায়।

বেশি output তৈরি করে এমন কাজ subagent-কে অর্পণ করুন। Test run এবং log processing—দুটিই প্রকৃত context ব্যবহার করে; subagent ওই output নিজের window-তে রাখে এবং শুধু একটি summary ফেরত দেয়। এর বিনিময়ে subagent নিজের cache তৈরি করে, তাই প্রথম call-এ কোনো cache hit থাকে না। Subscription ব্যবহার করলেও পাঁচ মিনিটের cache lifetime প্রযোজ্য হয়। Delegation নির্ভরযোগ্যভাবে আপনার মূল context সুরক্ষিত রাখে। তবে এটি মোট token ব্যবহার সবসময় কমায় না।

ক্যাশের ঘড়ি: ধারাবাহিক সময়সীমায় কাজ করুন

Prompt caching পুনরায় পাঠানোর খরচ কম রাখে: prefix পড়ার ক্ষেত্রে base input rate-এর 0.1x, prefix লেখার ক্ষেত্রে 1.25x, আর one-hour lifetime-এ লেখার ক্ষেত্রে 2x। প্রতিবার ব্যবহার হলে অতিরিক্ত খরচ ছাড়াই entry-টির lifetime নতুন করে শুরু হয়, তাই ঘড়ি শেষ ব্যবহারের সময় থেকে গণনা হয়। এই multiplier-গুলো বিলের কাঠামো বোঝায়, কিন্তু মোট খরচ নয়। তাই এগুলোর সঙ্গে এক মিলিয়ন token-এর প্রকৃত খরচ মিলিয়ে full context window-এর dollar-ভিত্তিক খরচ হিসাব করুন।

আপনি কোন lifetime পাবেন, তা authentication পদ্ধতির ওপর নির্ভর করে। তাই সবার ক্ষেত্রে “আপনার cache পাঁচ মিনিট পরে expire হয়”—এমন সাধারণ বক্তব্য সঠিক নয়।

• Claude subscription-এ Claude Code স্বয়ংক্রিয়ভাবে one-hour lifetime অনুরোধ করে।
• আপনার plan-এর limit পার হয়ে usage credits ব্যবহার করলে সেই usage-এর জন্য বিল করা হয়, তাই lifetime আবার পাঁচ মিনিটে নেমে আসে।
• API key বা cloud provider ব্যবহার করলে lifetime পাঁচ মিনিটই থাকে। ENABLE_PROMPT_CACHING_1H=1 one-hour lifetime নির্বাচন করে, আর FORCE_PROMPT_CACHING_5M=1 এটিকে আবার পাঁচ মিনিটে নামিয়ে দেয়।

দুই ক্ষেত্রেই কাজের পরামর্শ একই: বিরতিহীন সময়সীমায় কাজ করুন। কারণ lifetime-এর চেয়ে বেশি সময় idle থাকলে পরের turn-এ সঞ্চিত পুরো prefix আবার লিখতে হয়। একটি tmux-এ detached Claude Code session idle অবস্থায় কোনো খরচ করে না; তবে idle থাকার বিনিময়ে warm cache আর থাকে না।

কাজ চলাকালীন কিছু action cache মুছে দেয়: model পরিবর্তন, effort level পরিবর্তন, fast mode চালু করা, MCP server সংযোগ বা বিচ্ছিন্ন করা, plugin চালু বা বন্ধ করা, কোনো tool সম্পূর্ণভাবে deny করা, compacting, এবং Claude Code upgrade করা। /model-ই সাধারণত অপ্রত্যাশিত বিষয়। কারণ প্রতিটি model-এর আলাদা cache থাকে। তাই content একই থাকলেও পরের request পুরো history পড়ে এবং কোনো cache hit পায় না। এই পুনরায় পড়ার জন্য destination model-এর rate অনুযায়ী বিল করা হয়। ফলে session-এর মাঝখানে Fable-এ switch করলে আপনার সঞ্চিত পুরো history-এর জন্য Fable 5-এর প্রকাশিত input rate প্রযোজ্য হবে।

File edit করা, CLAUDE.md edit করা, skill ও command invoke করা, /recap চালানো, rewind করা এবং subagent চালু করা cache বজায় রাখে। Cache একটি machine এবং একটি directory-র মধ্যে সীমাবদ্ধ। তাই ভিন্ন directory-তে থাকা দুটি session একে অপরের cache ব্যবহার করতে পারে না। এই scope আপনার account নয়, CLI অনুসরণ করে। তাই এর কোনো অংশ Claude desktop app-এ যায় না। Linux-এ Claude desktop app হলো CLI-এর পাশাপাশি ইনস্টল করা একটি পৃথক beta।

Caching কাজ করছে কি না দেখতে current_usage পড়ুন। cache_creation_input_tokens cache write rate-এ লেখা হয়েছিল। cache_read_input_tokens standard input rate-এর প্রায় এক-দশমাংশ rate-এ পরিবেশিত হয়েছিল। Read-to-creation ratio বেশি হওয়া স্বাভাবিক। যদি প্রতিটি turn-এ creation বেশি থাকে, তাহলে আপনার prefix-এর কোনো অংশ বারবার পরিবর্তিত হচ্ছে।

বড় context window কি এই সমস্যা সমাধান করে?

আংশিকভাবে। বর্তমানে কয়েকটি model 1 million token context window সমর্থন করে, এবং বড় সীমাতেও compaction একইভাবে কাজ করে। অর্থনীতির হিসাব বদলায় না, কারণ প্রতিটি turn-এ পুরো prompt আবার পাঠানো হয় এবং তার জন্য বিল করা হয়। বড় window নির্ধারণ করে কখন আপনাকে ব্যবস্থা নিতে হবে; hygiene নির্ধারণ করে খরচ। সমস্যা যদি ceiling নয়, bill হয়, তাহলে আপনার কাজের ধরন অনুযায়ী কোন Claude plan উপযুক্ত তা নির্ধারণ করে আপনি dollars খরচ করবেন, নাকি plan allowance ব্যবহার করবেন।

API-তে context editing এবং compaction এক জিনিস নয়

আপনি যদি নিজের agent Messages API-তে তৈরি করেন, সেখানে কোনো slash command নেই, তাই এটি নিজেকেই implement করতে হবে। শুরু থেকেই এই কাজের জন্য বাজেট রাখুন, কারণ সামান্য signup credit-এর বাইরে API-তে কোনো free tier নেই। ফলে ছাঁটাই না করা history-এর প্রতিটি turn-এর সম্পূর্ণ বিল দিতে হবে। কোনো trimming হওয়ার আগেই আপনি কোন provider-এর ওপর agent তৈরি করবেন, তা এই হিসাব নির্ধারণ করে। তাই পছন্দ এখনো চূড়ান্ত না হলে headline per-token rate তুলনা না করে উভয় API-তে একই workload-এর খরচ হিসাব করুন। এই কাজের জন্য server-side দুটি feature আছে। এগুলো একই feature নয়।

Context editing conversation history বড় হওয়ার সঙ্গে নির্দিষ্ট content বেছে বেছে সরিয়ে দেয়। প্রতিটি সরানো content-এর পরিবর্তে placeholder text বসানো হয়, যাতে Claude বুঝতে পারে যে কিছু content সরানো হয়েছে। এটি একটি beta feature। anthropic-beta: context-management-2025-06-27 পাঠিয়ে context_management.edits-এর অধীনে strategy configure করুন। clear_tool_uses_20250919 tool result সরায় এবং clear_thinking_20251015 thinking block পরিচালনা করে। এর trigger-এর default হলো 100,000 input token, keep-এর default হলো সর্বশেষ 3টি tool use, এবং clear_tool_inputs-এর default হলো false। ফলে input থেকে যায়, শুধু result সরানো হয়।

Compaction একটি summary তৈরি করে এবং সম্পূর্ণ conversation history-এর পরিবর্তে সেটি বসায়। এটিও একটি beta feature। anthropic-beta: compact-2026-01-12 পাঠিয়ে compact_20260112 edit type ব্যবহার করুন। Trigger-এর default হলো {"type": "input_tokens", "value": 150000}, এবং value অন্তত 50,000 হতে হবে।

Compaction-এ একটি handoff rule আছে, যা নীরবে agent ভেঙে দিতে পারে। Response একটি compaction content block দিয়ে শুরু হয়, যেখানে summary থাকে। এর পরে সাধারণ text block থাকে। পরবর্তী request-এ আপনাকে ওই block-টি আবার পাঠাতে হবে। এরপর API তার আগের প্রতিটি content block সরিয়ে দেয়। বাস্তবে এর অর্থ হলো: শুধু text নয়, সম্পূর্ণ response.content append করুন।

Anthropic-এর documentation অনুযায়ী, দীর্ঘস্থায়ী conversation-এ context পরিচালনার primary strategy হলো server-side compaction। আর context editing ব্যবহার করা হয় কোন content সরানো হবে, সে বিষয়ে আরও সূক্ষ্ম নিয়ন্ত্রণের জন্য। আগে model support পরীক্ষা করুন। বর্তমান Opus, Sonnet এবং Fable model compaction support করে। claude-haiku-4-5 support করে না। Compaction page-এ বর্তমান তালিকা দেওয়া আছে। কোনো beta-ই Claude Code-এর নিজস্ব /compact পরিচালনা করে না। Documentation অনুযায়ী, এটি client-এর পাঠানো একবারের summarization request।

FAQ

আমার Claude Code session যত দীর্ঘ সময় চলে, তত ধীর এবং ব্যয়বহুল হয় কেন?

কারণ প্রতিটি turn-এ পুরো conversation আবার পাঠানো হয়। তাই সারাদিন খোলা থাকা একটি session-এ এক লাইনের প্রশ্নের সঙ্গেও পুরো দিনের conversation পাঠানো হয়। Prompt caching cache সক্রিয় থাকা অবস্থায় এই খরচ কম রাখে; read-এর জন্য base input rate-এর 0.1x হারে চার্জ হয়। কোনো turn cache-এ না মিললে একই prefix 1.25x হারে আবার লেখা হয়। Context window-এ কী জায়গা দখল করছে তা দেখতে /context চালান। এই ব্যবস্থাটি জানতে Claude Code session-এর জন্য কীভাবে বিল করা হয় পড়ুন।

Claude Code-এ /clear এবং /compact-এর মধ্যে পার্থক্য কী?

/clear খালি context-সহ একটি নতুন conversation শুরু করে। এটি কোনো request পাঠায় না, তাই এর জন্য কোনো খরচ হয় না। সম্পর্কহীন কাজের মধ্যে এটি ব্যবহার করাই সঠিক। /compact একই conversation বজায় রাখে এবং history-কে একটি summary দিয়ে প্রতিস্থাপন করে। তাই একটি দীর্ঘ কাজের মাঝখানে এটি ব্যবহার করা উপযুক্ত। /compact keep only the plan and the diff-এর মতো করে একটি focus নির্দিষ্ট করুন, কারণ কোন তথ্য রাখা হবে তা instruction-ই নির্ধারণ করে।

আমার Claude Code context window-এ কী কী জায়গা ব্যবহার করছে তা কীভাবে দেখব?

/context চালান। প্রতিটি item-এর পূর্ণ breakdown দেখতে /context all চালান। এটি system prompt, tool definitions, MCP servers, memory files এবং history-কে একটি রঙিন grid-এ দেখায়। Context বেশি ব্যবহারকারী tool এবং অতিরিক্ত memory সম্পর্কে এতে পরামর্শও থাকে। Paid plan-এ /usage সাম্প্রতিক ব্যবহার individual skills, subagents এবং MCP servers অনুযায়ীও দেখায়।

Compaction করার বদলে কি 1 million token context window ব্যবহার করা উচিত?

বড় window সমস্যার সমাধান করে না; শুধু সমস্যাটি পরে দেখা দেয়। Opus 4.8 এবং Sonnet 5-সহ বর্তমানে কয়েকটি model 1 million token context window চালায়। সেখানেও compaction একইভাবে কাজ করে। প্রতিটি turn-এ পুরো prompt আবার পাঠানো হয় এবং তার জন্য বিল করা হয়। তাই 400,000-token conversation window-এর মধ্যে ধরলেও ব্যয়বহুল থাকে।

Claude API-তে context editing এবং compaction-এর মধ্যে পার্থক্য কী?

Context editing পুরোনো content, বিশেষ করে tool result, বেছে বেছে সরিয়ে দেয়। প্রতিটির জায়গায় placeholder text রেখে দেওয়া হয়, যাতে Claude বুঝতে পারে যে সেটি সরানো হয়েছে। Compaction একটি summary তৈরি করে এবং পুরো history-কে সেই summary দিয়ে প্রতিস্থাপন করে। Anthropic-এর documentation দীর্ঘ সময় চলা conversation-এর জন্য compaction-কে প্রধান strategy হিসেবে উল্লেখ করে এবং context editing-কে সূক্ষ্ম নিয়ন্ত্রণের option হিসেবে বর্ণনা করে। উভয়ই নিজস্ব header-সহ beta feature। দুটিই Claude Code-এর /compact থেকে আলাদা।