Claude Code স্লো ও ব্যয়বহুল হওয়া রোধ করার উপায়

Claude Code session স্লো এবং ব্যয়বহুল হওয়া কীভাবে রোধ করবেন

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

কেন মিটার চলে তার উত্তর রয়েছে an agent session-এর পেছনের token meter-এ।

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

উইন্ডোতে কী আছে তা অনুমান করার চেষ্টা করবেন না। Claude Code আপনাকে তা জানিয়ে দেবে।

/context [all] বর্তমান context ব্যবহারের একটি রঙিন গ্রিড দেখায়, যেখানে context-heavy টুল এবং memory bloat-এর জন্য optimization পরামর্শ দেওয়া হয়; all fullscreen mode-এ প্রতিটি আইটেমের বিস্তারিত বিবরণ বড় করে দেখায়। ফলাফলটিকে পাঁচটি ভাগে (buckets) পড়ুন।

• The system prompt. Claude Code-এর নিজস্ব harness instructions। এটি সেশনের জন্য নির্ধারিত (fixed)।
• Tool definitions. এজেন্ট যে টুলগুলো কল করতে পারে তার schema, যার মধ্যে প্রতিটি সংযুক্ত MCP (Model Context Protocol) server অন্তর্ভুক্ত।
• Memory files. CLAUDE.md এবং auto memory, যা সেশন শুরুর সময় লোড করা হয়।
• Files and tool results. প্রতিটি পড়া ফাইল এবং আপনার কমান্ডের আউটপুট।
• Message history. আপনার মেসেজ এবং এর উত্তর।

প্রথম তিনটি হলো একটি fixed tax, যা সেশনের প্রতিটি request-এর জন্য দিতে হয়। শেষ দুটি ক্রমাগত বৃদ্ধি পায়। শুরুতে একবার fixed tax কমিয়ে ফেলুন; এবং ক্রমবর্ধমান অংশটি নিয়মিতভাবে manage করুন।

দুটি স্ট্রিং আপনাকে জানাবে যে উইন্ডোটি পূর্ণ হয়ে গেছে:

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 মডেলের ক্ষেত্রে মডেলের প্রকৃত context window-এর নিচে থাকতে পারে। এর পরেও request সফল হয়, তাই এটি রিফিউজ করার বদলে একটি warning হিসেবে কাজ করে।

Paid plan-এর ক্ষেত্রে, /usage বাকি অর্ধেক তথ্য যোগ করে, যা long context বা cache misses-এর মতো আচরণগুলো চিহ্নিত করে এবং সাম্প্রতিক usage-এর জন্য individual skills, subagents এবং MCP servers-এর দায় নির্ধারণ করে।

CLAUDE.md is a permanent tax, so keep it lean

Your CLAUDE.md is loaded into context at session start and stays there. If it holds a detailed deployment procedure, those tokens are present while you fix a typo in a test file. Anthropic's guidance is to include only essentials and keep the file under 200 lines.

Move procedures into skills. A skill loads only when invoked, so a workflow you run twice a week costs nothing on the other days. Skills have their own budget after a compaction: bodies are re-injected, capped at 5,000 tokens per skill and 25,000 in total, oldest dropped first. Truncation keeps the start of the file, so put the most important instructions near the top of SKILL.md.

What survives a compaction decides where an instruction belongs.

• The system prompt and output style are unchanged, because they are not part of message history.
• The project-root CLAUDE.md, unscoped rules, and auto memory are re-injected from disk.
• A rule with paths: frontmatter is lost until a matching file is read again.
• A nested CLAUDE.md in a subdirectory is lost until a file in that subdirectory is read again.
• Hooks are unaffected, because a hook runs as code and never enters context.

So a rule you depend on belongs in the project-root CLAUDE.md: Claude Code clears older tool outputs first and then summarizes, so instructions from early in the conversation may be lost. Edit memory with /memory. Claude Code holds the copy it loaded at session start, so a mid-session trim keeps the prompt cache and does not apply until the next /clear, /compact, or restart.

/clear between tasks, /compact inside one

These two look interchangeable and cost very different amounts.

/clear [name] starts a new conversation with empty context. It sends no request, so it costs nothing. Pass a name to label the previous conversation in the /resume picker; /reset and /new are aliases. Use it the moment you switch to an unrelated task, because the old task would otherwise be re-sent, and re-billed, on every message of the new one.

/compact [instructions] frees up context while continuing the same conversation: it summarizes the history so far and replaces it. Use it inside one long task, where you still need continuity.

Always give /compact an instruction. A bare /compact summarizes against a default prompt that does not know which part of the work you still need. An instructed one keeps it:

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

If you compact for the same reason every time, put a standing instruction in your project's CLAUDE.md under a # Compact instructions heading. In a new session /compact prints Not enough messages to compact., which only means there is no history yet.

Two costs get confused here. The summarization request shares your prefix, so it reads the existing cache rather than reprocessing the history, and most of its time goes to generating the summary. Compacting a large context is still a large request, because the conversation being summarized is the input. The turn after compaction is not the slow part: it rebuilds the cache for a much shorter prompt.

Two cheaper commands exist. /rewind [description] rolls back code and conversation to a checkpoint; for a path you want to abandon entirely it beats compacting, because it truncates back to a prefix that is already cached. /recap appends a summary as command output instead of replacing history, so the cached prefix stays intact.

Automatic compaction firing over and over prints this:

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

Compaction succeeded, but a file or tool output refilled the window several times in a row, so Claude Code stopped retrying. Recover by reading the oversized file in line ranges, running /compact with a focus that drops the large output, moving that work to a subagent, or /clear if the earlier conversation is done.

MCP server-এর জন্য নির্দিষ্ট overhead প্রয়োজন হয়

প্রতিটি সংযুক্ত MCP server পুরো session-এর প্রতিটি request-এর সাথে অতিরিক্ত overhead যোগ করে। আপনি সেটি ব্যবহার করুন বা না করুন, আপনাকে তার জন্য খরচ করতে হবে।

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

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

Context-এ প্রবেশের আগে verbose tool output ফিল্টার করুন

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

সোর্স থেকেই ফিল্টার করুন। একটি hook যা Claude দেখার আগে test run-এর শুধুমাত্র failures গুলোকে কমিয়ে আনে, সেটি output-এর বিশাল পরিমাণকে মাত্র কয়েকশ token-এ পরিণত করে; এটি বর্তমান turn এবং পরবর্তী প্রতিটি resend-এর জন্য প্রযোজ্য:

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

Hooks নিজে কখনো context-এ প্রবেশ করে না, কারণ এগুলো code হিসেবে রান করে। যে কোনো tool যার output স্ক্রিনের সীমা ছাড়িয়ে যায়, সেটির জন্য এটি করুন। একই লজিক 3,000-line বিশিষ্ট ফাইলের ক্ষেত্রেও প্রযোজ্য: আপনার প্রয়োজনীয় line range-টি চান, কারণ ফাইলটি একবার চলে আসলে পুরো ফাইলটি window-তে থেকে যায়।

Agent-এর পড়ার পরিধি নির্ধারণ করুন এবং অতিরিক্ত কাজের দায়িত্ব অন্যকে দিন

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

অতিরিক্ত বা বিস্তারিত কাজের জন্য subagent ব্যবহার করুন। Test run এবং log processing উভয় ক্ষেত্রেই অনেক context প্রয়োজন হয়; একটি subagent সেই আউটপুট তার নিজস্ব উইন্ডোতে রাখে এবং শুধুমাত্র একটি summary প্রদান করে। এর একটি অসুবিধা হলো: প্রথমবার কল করার সময় subagent-এর নিজস্ব cache থাকে না, এবং subscription থাকা সত্ত্বেও এটি ৫ মিনিটের cache lifetime ব্যবহার করে। Delegation আপনার main context-কে নির্ভরযোগ্যভাবে সুরক্ষিত রাখে। তবে এটি সবসময় মোট token সংখ্যা কমায় না।

ক্যাশ ক্লক: একটানা কাজ করুন

Prompt caching ব্যবহারের ফলে পুনরায় পাঠানো (resend) সাশ্রয়ী হয়: prefix পড়ার জন্য বেস ইনপুট রেটের 0.1x খরচ হয়, এটি লেখার জন্য 1.25x খরচ হয়, অথবা এক ঘণ্টার লাইফটাইমের জন্য 2x খরচ হয়। প্রতিটি ব্যবহারের ফলে কোনো অতিরিক্ত খরচ ছাড়াই এন্ট্রিটি রিফ্রেশ হয়, তাই শেষ ব্যবহারের সময় থেকে ক্লক গণনা শুরু হয়।

আপনি কোন লাইফটাইম পাবেন তা নির্ভর করে আপনি কীভাবে অথেন্টিকেট করছেন তার ওপর; তাই "আপনার ক্যাশ পাঁচ মিনিট পর এক্সপায়ার হবে" - এই সাধারণ ধারণাটি ভুল।

• Claude subscription ব্যবহার করলে, Claude Code স্বয়ংক্রিয়ভাবে এক ঘণ্টার লাইফটাইম রিকোয়েস্ট করে।
• যখন আপনি আপনার প্ল্যানের লিমিট অতিক্রম করে usage credits ব্যবহার করতে শুরু করবেন, তখন সেই ব্যবহারের জন্য বিল দিতে হবে, তাই এটি কমে পাঁচ মিনিটে চলে আসে।
• API key বা cloud provider ব্যবহার করলে, এটি পাঁচ মিনিটেই থাকে। ENABLE_PROMPT_CACHING_1H=1 এক ঘণ্টার লাইফটাইম গ্রহণ করে, এবং FORCE_PROMPT_CACHING_5M=1 এটিকে পুনরায় পাঁচ মিনিটে নামিয়ে আনে।

উভয় ক্ষেত্রেই কাজের ছন্দ সম্পর্কে পরামর্শ একই: একটানা কাজ করুন, কারণ লাইফটাইম পার হওয়ার মতো দীর্ঘ বিরতি নিলে পরবর্তী বার পুরো accumulated prefix পুনরায় লিখতে হবে। একটি tmux-এ detached Claude Code session অলস অবস্থায় (idle) কোনো খরচ করে না, তবে অলস সময় কাটানোর ফলে আপনি warm cache হারিয়ে ফেলেন।

কিছু অ্যাকশন আপনি কাজ করার সময় ক্যাশ মুছে ফেলে: মডেল পরিবর্তন করা, effort level পরিবর্তন করা, fast mode চালু করা, MCP server কানেক্ট বা ডিসকানেক্ট করা, plugin চালু বা বন্ধ করা, কোনো টুল রিজেক্ট করা, compact করা এবং Claude Code আপগ্রেড করা। /model একটি সাধারণ বিস্ময়কর বিষয়, কারণ প্রতিটি মডেলের নিজস্ব ক্যাশ থাকে; তাই কন্টেন্ট একই হওয়া সত্ত্বেও পরবর্তী রিকোয়েস্টটি কোনো cache hit ছাড়াই পুরো হিস্ট্রি পুনরায় পড়ে।

ফাইল এডিট করা, CLAUDE.md এডিট করা, skills এবং commands কল করা, /recap চালানো, rewinding করা এবং subagent তৈরি করা—এই সবক্ষেত্রেই ক্যাশ বজায় থাকে। এটি একটি নির্দিষ্ট মেশিন এবং একটি ডিরেক্টরির মধ্যে সীমাবদ্ধ, তাই ভিন্ন ডিরেক্টরিতে দুটি সেশন একে অপরের ক্যাশ ব্যবহার করতে পারে না।

ক্যাশিং কাজ করছে কিনা তা দেখতে current_usage পড়ুন। cache_creation_input_tokens ক্যাশ রাইট রেটে লেখা হয়েছিল; cache_read_input_tokens স্ট্যান্ডার্ড ইনপুট রেটের প্রায় এক দশমাংশ গতিতে সার্ভ করা হয়েছিল। একটি উচ্চ read-to-creation ratio থাকা মানে সিস্টেমটি সঠিকভাবে কাজ করছে। যদি প্রতিবার creation রেট বেশি থাকে, তবে বুঝতে হবে আপনার prefix-এর কোনো অংশ বারবার পরিবর্তিত হচ্ছে।

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

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

API-তে Context editing এবং compaction সম্পূর্ণ আলাদা বিষয়

আপনি যদি Messages API-তে নিজের agent তৈরি করেন, তবে কোনো slash commands থাকবে না এবং আপনাকে এটি নিজেই implement করতে হবে। সার্ভার-সাইড ফিচার হিসেবে দুটি আলাদা ফিচার এই কাজটি সম্পন্ন করে।

Context editing কথোপকথনের ইতিহাস বড় হওয়ার সাথে সাথে নির্দিষ্ট কন্টেন্ট বেছে নিয়ে মুছে ফেলে। মুছে ফেলা কন্টেন্টের পরিবর্তে একটি placeholder text ব্যবহার করা হয় যাতে Claude বুঝতে পারে কিছু মুছে ফেলা হয়েছে। এটি একটি beta ফিচার: anthropic-beta: context-management-2025-06-27 পাঠান এবং context_management.edits-এর অধীনে strategies কনফিগার করুন। clear_tool_uses_20250919 টুল রেজাল্ট মুছে ফেলে এবং clear_thinking_20251015 thinking blocks ম্যানেজ করে। এর trigger ডিফল্টভাবে 100,000 input tokens, keep ডিফল্টভাবে শেষ 3টি tool uses, এবং clear_tool_inputs ডিফল্টভাবে false সেট করা থাকে, যাতে ইনপুটগুলো থেকে যায় এবং শুধুমাত্র রেজাল্টগুলো মুছে যায়।

Compaction একটি সামারি তৈরি করে এবং সম্পূর্ণ কথোপকথনের ইতিহাসকে সেই সামারি দিয়ে প্রতিস্থাপন করে। এটিও একটি beta ফিচার: anthropic-beta: compact-2026-01-12 পাঠান এবং compact_20260112 edit type ব্যবহার করুন। এর trigger ডিফল্টভাবে {"type": "input_tokens", "value": 150000} সেট করা থাকে এবং এর মান অবশ্যই অন্তত 50,000 হতে হবে।

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

Anthropic-এর ডকুমেন্টেশন অনুযায়ী, দীর্ঘ কথোপকথনের ক্ষেত্রে context ম্যানেজ করার জন্য সার্ভার-সাইড compaction হলো প্রধান কৌশল, আর context editing হলো কী মুছে ফেলা হবে তার ওপর সূক্ষ্ম নিয়ন্ত্রণ রাখার উপায়। প্রথমে মডেল সাপোর্ট চেক করে নিন। বর্তমান Opus, Sonnet এবং Fable মডেলগুলো compaction সাপোর্ট করে; claude-haiku-4-5 এটি সাপোর্ট করে না। compaction পেজে লাইভ লিস্ট পাওয়া যাবে। কোনোটিই Claude Code-এর নিজস্ব /compact পরিচালনা করে না, যা ডকুমেন্টেশনে ক্লায়েন্ট দ্বারা পাঠানো একটি এককালীন summarization request হিসেবে বর্ণনা করা হয়েছে।

FAQ

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

কারণ প্রতিটি turn-এ পুরো conversation-টি আবার পাঠানো হয়। ফলে সারাদিন খোলা থাকা একটি session-এ একটি মাত্র লাইনের প্রশ্ন পাঠালেও পুরো দিনের সমস্ত তথ্য সাথে নিয়ে যায়। Prompt caching ব্যবহার করলে cache warm থাকা অবস্থায় খরচ কম থাকে (read-এর জন্য base input rate-এর 0.1x)। কিন্তু একবার cache miss হলে, একই prefix 1.25x হারে পুনরায় লিখতে হয়। 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 প্রদান করুন, কারণ নির্দেশনাই নির্ধারণ করে কোন তথ্যগুলো টিকে থাকবে।

আমার Claude Code context window-তে কী কী ব্যবহার হচ্ছে তা আমি কীভাবে দেখব?

/context চালান, অথবা প্রতিটি আইটেমের বিস্তারিত দেখতে /context all চালান। এটি system prompt, tool definitions, MCP servers, memory files, এবং history-কে একটি রঙিন grid হিসেবে দেখায়। এছাড়া context-heavy tools এবং memory bloat সম্পর্কে পরামর্শও প্রদান করে। পেইড প্ল্যানে, /usage সাম্প্রতিক ব্যবহারের জন্য individual skills, subagents এবং MCP servers-এর হিসাবও প্রদান করে।

compaction করার পরিবর্তে আমার কি 1 million token context window ব্যবহার করা উচিত?

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

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

Context editing বেছে বেছে পুরনো কন্টেন্ট (মূলত tool results) মুছে ফেলে এবং যেখানে সেগুলো ছিল সেখানে placeholder text রেখে দেয়, যাতে Claude বুঝতে পারে সেগুলো সরিয়ে ফেলা হয়েছে। Compaction একটি summary তৈরি করে এবং পুরো history-কে সেটি দিয়ে প্রতিস্থাপন করে। Anthropic-এর ডকুমেন্টেশন অনুযায়ী, দীর্ঘস্থায়ী conversation-এর জন্য compaction হলো প্রাথমিক কৌশল, আর context editing হলো একটি সূক্ষ্ম বা fine-grained বিকল্প। এই দুটিই বর্তমানে beta পর্যায়ে আছে এবং Claude Code-এর /compact থেকে আলাদা।