Claude Code খরচ বাড়ে পুরোনো context-এ: কমানোর ছয়টি বাস্তব উপায়

Claude Code-এর পুরোনো conversation history প্রতিটি নতুন turn-এ context-এর অংশ হলে token consumption বাড়ে। ব্যয় কমাতে session-এ ব্যবহার মাপা ও অপ্রাসঙ্গিক history সরানো, project-এ CLAUDE.md ছোট রাখা এবং API organization-এ workspace limit বসানো—এই তিন স্তরে কাজ করতে হবে।

সবচেয়ে কার্যকর নিয়ম হলো: নতুন ও সম্পর্কহীন কাজের আগে /clear, একই দীর্ঘ কাজ চালিয়ে যাওয়ার সময় /compact। তবে তার আগে authentication বুঝে নিন—Anthropic-এর usage ও limits নির্দেশিকা অনুযায়ী subscription seat-এর ব্যবহার plan allowance থেকে গণনা হয়, আর API key-এর ব্যবহার প্রতি token হিসেবে bill হয়। তাই subscription quota এবং API session-এর dollar cost এক মাপকাঠি নয়।

১. /usage ও /cost দিয়ে সঠিক মিটার দেখুন

কাজের শুরু ও শেষে /usage চালিয়ে session-এর token statistics দেখুন। API billing হলে Session অংশে token count ও আনুমানিক dollar cost পাওয়া যায়; /cost একই command-এর alias। এই হিসাব একটি session তুলতে সুবিধা দেয়, কিন্তু invoice নয়।

Pro, Max, Team বা Enterprise subscription-এ /usage plan limit, activity এবং প্রযোজ্য usage breakdown দেখাতে পারে। সেখানে Session-এর dollar estimate seat allowance-এর প্রকৃত bill নয়। API ব্যবহারকারী authoritative charge যাচাই করবেন Claude Console-এর Usage page-এ; cloud provider দিয়ে API ব্যবহার করলে সংশ্লিষ্ট provider-এর billing console দেখতে হবে।

একই ধরনের কয়েকটি কাজের জন্য ছোট baseline রাখুন: ব্যবহৃত model, শুরু ও শেষের usage এবং turn-এর সংখ্যা। এতে কোন session অস্বাভাবিকভাবে বড় হচ্ছে তা বোঝা যায়। এটি আনুষ্ঠানিক accounting নয়; বরং অপচয় শনাক্ত করার operational record।

২. কাজ বদলালে /clear দিয়ে পুরোনো history সরান

একটি turn শুধু নতুন prompt বহন করে না; আগের conversation, project instructions এবং আগে পড়া file-ও context-এ থাকতে পারে। ফলে login bug শেষ করে একই conversation-এ database migration শুরু করলে নতুন কাজের সঙ্গে পুরোনো debugging history-ও process হতে থাকে। context যত বড় হয়, পরের message-এ ব্যবহৃত token তত বাড়তে পারে।

Claude Code-এর cost নির্দেশিকা বলছে, token cost context-এর আকারের সঙ্গে বাড়ে এবং unrelated task-এর মাঝে /clear ব্যবহার করলে stale context পরের message-গুলোতে আর token নষ্ট করে না। নতুন prompt যদি একেবারে নতুন terminal session-এও স্বয়ংসম্পূর্ণ হয়, সেটিই clear করার ভালো সংকেত।

/clear নতুন conversation শুরু করে, তবে আগের conversation পরে resume করা যায় এবং project memory থাকে। আগের আলোচনার সিদ্ধান্ত দরকার হতে পারে মনে হলে clear করার আগে session-টির নাম দিন, অথবা প্রয়োজনীয় সিদ্ধান্ত repository-র উপযুক্ত নথিতে সংরক্ষণ করুন।

৩. একই দীর্ঘ কাজে /compact ব্যবহার করুন

চলমান debugging, refactor বা migration-এর মাঝখানে আগের সিদ্ধান্ত প্রয়োজন হলে /clear উপযুক্ত নয়। /compact conversation-কে ছোট summary-তে পরিণত করে, যাতে প্রয়োজনীয় context রেখে একই কাজ চালানো যায়। সংক্ষিপ্ত সিদ্ধান্তটি তাই স্পষ্ট: কাজ বদলালে clear, কাজ একই থাকলে compact।

Command-এর সঙ্গে focus instruction দেওয়া যায়—যেমন test failure, পরিবর্তিত file এবং অমীমাংসিত সিদ্ধান্ত ধরে রাখতে বলা। Claude Code command reference অনুযায়ী /compact ঐচ্ছিক instruction মেনে conversation summarize করে, /clear empty context-সহ নতুন conversation শুরু করে এবং /context বর্তমানে কী context দখল করছে তা দেখায়।

Claude Code limit-এর কাছাকাছি গেলে স্বয়ংক্রিয় compaction করতে পারে। তবু দীর্ঘ কাজের যৌক্তিক milestone—যেমন একটি failing test আলাদা করা বা refactor-এর প্রথম ধাপ শেষ করা—manual compact-এর সুবিধাজনক সময়। তখন summary-তে কী রাখা দরকার তা developer নিজেই নির্ধারণ করতে পারেন।

৪. কাজের জটিলতা অনুযায়ী model বাছুন

প্রতিটি কাজের জন্য সবচেয়ে বেশি reasoning-ক্ষম model চালু রাখা ব্যয়সাশ্রয়ী নয়। Sonnet অধিকাংশ coding task-এর উপযোগী default; কঠিন architectural decision, বিস্তৃত refactor বা জটিল debugging-এর জন্য Opus নেওয়া যায়। account-এ পাওয়া গেলে ছোট lookup, সরল edit বা mechanical task-এ Haiku বিবেচনা করা যায়।

/model চালিয়ে account-এ উপলভ্য model দেখুন এবং প্রয়োজনে session-এর মাঝেই বদলান। নির্দিষ্ট model name ও availability সময়ের সঙ্গে পরিবর্তিত হতে পারে, তাই পুরোনো team document নয়, command-এ দেখা তালিকাই ব্যবহার করুন। বড় পরিবর্তনে শক্তিশালী model দিয়ে plan তৈরি করে যাচাইয়ের পর routine execution অপেক্ষাকৃত সাশ্রয়ী model-এ করা একটি ব্যবহারিক workflow।

৫. CLAUDE.md-কে lean project memory রাখুন

CLAUDE.md session শুরুতে context-এ load হয়। দীর্ঘ architecture history, অচল নিয়ম, বড় code sample কিংবা একবারের troubleshooting note সেখানে থাকলে সম্পর্কহীন কাজেও সেগুলো context দখল করে। prompt caching পুনরাবৃত্ত content-এর billing কমাতে পারে, কিন্তু অপ্রয়োজনীয় লেখা context window থেকে অদৃশ্য হয় না।

ফাইলটিতে শুধু বারবার প্রয়োজনীয় স্থায়ী নির্দেশনা রাখুন: build ও test command, repository convention, এড়িয়ে চলার path এবং সংক্ষিপ্ত validation rule। নির্দিষ্ট migration বা review workflow-এর বিস্তারিত আলাদা on-demand নথিতে রাখুন। একই নির্দেশনা root ও nested CLAUDE.md-তে নকল না করে obsolete rule নিয়মিত মুছুন।

৬. API team-এর workspace limit নির্ধারণ করুন

ব্যক্তিগত context hygiene organization-level ceiling-এর বিকল্প নয়। Claude Console-এর API organization-এ administrator Claude Code workspace-এর মোট spend limit ও rate limit নির্ধারণ করতে পারেন। Console dashboard ও Claude Code Analytics API member-level usage দেখাতে পারে, ফলে কোন developer বা workflow ব্যয় বাড়াচ্ছে তা মোট invoice আসার আগেই শনাক্ত করা সম্ভব।

Claude for Teams বা Enterprise seat এবং Claude Console API workspace আলাদা প্রশাসনিক ব্যবস্থা। seat allowance ও অতিরিক্ত usage-credit control থাকে claude.ai admin settings-এ; Console API usage প্রতি token হিসেবে bill হয়। Amazon Bedrock, Google Cloud-এর পরিবেশ বা Microsoft Foundry ব্যবহার করলে spend control ও reporting সংশ্লিষ্ট cloud billing system-এ রাখতে হবে। মিশ্র authentication-এর দলে প্রত্যেক developer যেভাবে sign in করেছেন, সেই পথেই তাঁর usage মাপা হবে।

Before: একটি session-এ সম্পর্কহীন একাধিক কাজ, সবসময় ভারী model, বড় CLAUDE.md এবং মাস শেষে শুধু মোট bill দেখা। After: শুরুতে billing mode ও /usage পরীক্ষা, নতুন কাজের আগে /clear, একই দীর্ঘ কাজের milestone-এ /compact, complexity অনুযায়ী /model, lean project memory এবং API workspace-এ spend ও rate ceiling। এই ছয়টি ব্যবস্থা session, project ও organization—তিন স্তরেই token consumption ও team spend-এর দায় দৃশ্যমান রাখে।