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 একটি স্থায়ী overhead, তাই এটি সংক্ষিপ্ত রাখুন

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

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

Compaction-এর পর কোন বিষয় টিকে থাকে, তা দেখে নির্দেশনাটি কোথায় রাখা উচিত নির্ধারণ করুন।

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

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

/clear ব্যবহার করুন task বদলালে, আর একই task-এর মধ্যে /compact [instructions]/compact ব্যবহার করুন

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

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

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

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

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

প্রতিবার একই কারণে compact করলে আপনার project's CLAUDE.md-এ # Compact instructions heading-এর অধীনে একটি স্থায়ী instruction রাখুন। নতুন session-এ /compact চালালে Not enough messages to compact. দেখায়। এর অর্থ হলো summary তৈরি করার মতো পর্যাপ্ত turn conversation-এ নেই। একটি বড় paste পুরো context পূরণ করে ফেললেও এমন হতে পারে।

এখানে দুটি খরচ প্রায়ই গুলিয়ে যায়। Summarization request আপনার prefix share করে। তাই এটি history আবার process না করে বিদ্যমান cache পড়ে, এবং অধিকাংশ সময় summary তৈরি করতেই ব্যয় হয়। বড় context compact করা তবু বড় request, কারণ যে conversation-এর summary তৈরি হচ্ছে সেটিই input। Compaction-এর পরের turn ধীর অংশ নয়। এটি অনেক ছোট prompt-এর জন্য cache পুনর্নির্মাণ করে।

আরও কম খরচের দুটি command আছে। /rewind code এবং conversation-কে একটি checkpoint-এ rollback করে। কোনো path সম্পূর্ণভাবে বাদ দিতে চাইলে compact করার চেয়ে এটি ভালো, কারণ এটি এমন একটি prefix-এ ফিরে যায় যা ইতিমধ্যে cached। /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-এর overhead বাড়ায়। আপনি server-টি ব্যবহার করুন বা না করুন, এই খরচ দিতে হয়।

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

Session শুরুতেই এটি করুন। Definition deferred থাকা অবস্থায় server সংযুক্ত বা বিচ্ছিন্ন করলে শুধু conversation-এ নতুন তথ্য যোগ হয়, এবং cache অক্ষত থাকে। অন্যদিকে tool search disabled, unavailable বা তার auto threshold-এর নিচে থাকায় definition prefix-এ load হলে একই পরিবর্তনের কারণে পরের 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-ই resend-কে সাশ্রয়ী করে। Prefix লেখার খরচ base input rate-এর 1.25x, অথবা one-hour lifetime-এ 2x। এটি আবার পড়ার খরচ Haiku 5.5-এ 0.1x, Opus 5.5 ও Sonnet 5.5-এ 0.05x ($0.20 এবং প্রতি million tokens-এ $0.10), এবং Fable 5.1-এ 0.025x (প্রতি million tokens-এ $0.25)। প্রতিবার ব্যবহার করলে অতিরিক্ত খরচ ছাড়াই entry refresh হয়, তাই clock শেষ ব্যবহারের সময় থেকে গণনা হয়। এই multiplier-গুলো bill-এর গঠন দেখায়, কিন্তু মোট পরিমাণ নয়। তাই এগুলোর সঙ্গে এক million tokens-এর প্রকৃত খরচ মিলিয়ে full context window-এর dollar মূল্য নির্ণয় করুন।

আপনি কোন lifetime পাবেন, তা authentication পদ্ধতির ওপর নির্ভর করে। তাই সবার ক্ষেত্রে "your cache expires after five minutes" বলা সঠিক নয়।

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

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

কাজ চলার সময়ও কিছু action cache বাতিল করে: model পরিবর্তন করা, পুরোনো model-এ effort level পরিবর্তন করা, fast mode চালু করা, MCP server connect বা disconnect করা, tool definition শুরুতেই load হওয়ার সময় কোনো সম্পূর্ণ tool deny করা, tool যোগ করে এমন plugin enable বা disable করা, compact করা, conversation-এ অতিরিক্ত image জমলে পুরোনো image বাদ দেওয়া, এবং Claude Code upgrade করা। API key বা subscription সহ Opus 5.5, Sonnet 5.5, Haiku 5.5 ও Fable 5.1-এ effort পরিবর্তন করলে এখন cache বজায় থাকে। /model সাধারণত অপ্রত্যাশিত ফল তৈরি করে, কারণ প্রতিটি model-এর আলাদা cache থাকে। তাই content একই হলেও পরের request পুরো history পড়ে এবং কোনো cache hit পায় না। এই পুনরায় পড়ার খরচ destination model-এর rate অনুযায়ী fresh cache write হিসেবে ধরা হয়। ফলে session-এর মাঝখানে Fable-এ switch করলে জমা হওয়া পুরো history-র জন্য Fable-এর প্রকাশিত cache-write rate অনুযায়ী bill হবে: five-minute lifetime-এ প্রতি million tokens-এ $12.50 অথবা one-hour lifetime-এ $20। Fable 5 এবং Fable 5.1-এ খরচ একই।

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

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

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

আংশিকভাবে। বর্তমান প্রতিটি model (Fable 5.1, Opus 5.5, Sonnet 5.5 এবং Haiku 5.5) 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 নেই; এটি আপনাকেই বাস্তবায়ন করতে হবে। শুরু থেকেই এই কাজের জন্য সময় ও সম্পদ বরাদ্দ করুন, কারণ API-এর বিনামূল্যের allowance আপনার token-এর খরচ বহন করবে না। নতুন ব্যবহারকারীরা API পরীক্ষা করার জন্য অল্প পরিমাণ free credit পান। Anthropic যে standing allowance উল্লেখ করে—pricing page-এ organization-পিছু দিনে 50 free hours এবং docs-এ মাসে 1,550—তা code execution container-এর সময়ের জন্য প্রযোজ্য; এটি token-এর থেকে আলাদাভাবে বিল হয়। প্রতিটি turn-এ ছাঁটাই না-করা পুরো history আবার পাঠানো হয় এবং তার সম্পূর্ণ অংশের জন্য বিল হয়: prefix cache-এ থাকলে cache read rate-এ, আর cache-এ না থাকলে full input rate-এ অথবা cache-write premium-সহ। আপনি কোন provider-এর উপর তৈরি করছেন, trimming শুরু হওয়ার আগেই সেই হিসাব নির্ধারণ করে। তাই পছন্দ এখনও চূড়ান্ত না হলে headline per-token rate তুলনা না করে দুই API-তেই একই workload-এর খরচ হিসাব করুন। এই কাজের জন্য server-side দুটি feature আছে, কিন্তু এগুলো একই feature নয়।

Context editing conversation history বাড়ার সঙ্গে নির্দিষ্ট 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 mode আছে। Threshold compaction আপনার সাধারণ request-এর মধ্যেই চলে: anthropic-beta: compact-2026-01-12 পাঠান এবং compact_20260112 edit type ব্যবহার করুন। Trigger-এর default হলো {"type": "input_tokens", "value": 150000}, এবং এই মান অন্তত 50,000 হতে হবে। On-demand compaction-এ কখন এটি চালানো হবে তা আপনার code নির্ধারণ করে: top-level "compaction": {"type": "summarize"}-সহ anthropic-beta: compact-2026-09-04 পাঠান। Response-এ শুধু summary block থাকে। Anthropic-এর compaction overview-এ বলা হয়েছে, যেখানে available সেখানে on-demand compaction ব্যবহার করতে।

Threshold compaction-এর একটি handoff rule আছে, যা নীরবে agent ভেঙে দিতে পারে। Response-এর শুরুতে summary-সহ একটি compaction content block থাকে, তার পরে স্বাভাবিক text block থাকে। পরবর্তী request-এ আপনাকে ওই block আবার পাঠাতে হবে। তখন API তার আগের প্রতিটি content block বাদ দেয়। বাস্তবে, শুধু text নয়, সম্পূর্ণ response.content append করুন। On-demand compaction-এর পদ্ধতি উল্টো: summarized message-গুলো আপনি নিজেই সরিয়ে দিন, returned block-টি messages-এর শুরুতে রাখুন, এবং signature-সহ ঠিক যেভাবে ফেরত এসেছে সেভাবেই পাঠান।

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

FAQ

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

কারণ প্রতিটি turn-এ পুরো conversation আবার পাঠানো হয়। তাই সারাদিন খোলা থাকা session-এ এক লাইনের প্রশ্নের সঙ্গেও পুরো দিনের conversation পাঠানো হয়। Prompt caching cache সক্রিয় থাকা অবস্থায় এই খরচ কম রাখে: Haiku 5.5-এ read-এর খরচ base input rate-এর 0.1x, Opus 5.5 এবং Sonnet 5.5-এ 0.05x, আর Fable 5.1-এ 0.025x। কোনো turn cache-এ না মিললে একই prefix আবার 1.25x হারে লেখা হয়, অথবা one-hour lifetime ব্যবহার করলে 2x হারে। কী কী 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 বেশি ব্যবহার করা tools এবং memory bloat কমানোর জন্য এতে পরামর্শও থাকে। Paid plan-এ /usage সাম্প্রতিক usage-কে পৃথক skills, subagents এবং MCP servers-এর সঙ্গে যুক্ত করেও দেখায়।

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

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

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

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