Claude-এ token কী এবং এর খরচ কেমন?

Claude-এ token কী?

Token হলো Claude-এর টেক্সট পড়ার এবং লেখার একক: এটি একটি শব্দের অংশ, যা মোটামুটি 3.5টি English character-এর সমান। Anthropic-এর glossary অনুযায়ী এই হিসাবটি করা হয়েছে। স্পেস এবং punctuation যোগ করলে প্রতি শব্দের জন্য ১টির বেশি token প্রয়োজন হয়, তাই ১,০০০ শব্দের গদ্যের জন্য অনায়াসেই ১,৩০০-এর বেশি token লাগে। Code-এর ক্ষেত্রে প্রতি লাইনে token-এর ব্যবহার বেশি হয়: braces, operators, underscores, এবং indentation-এর কারণে English-এর তুলনায় প্রতি character-এ বেশি token তৈরি হয়। কয়েকশ লাইনের একটি source file সাধারণত কয়েক হাজার token নিয়ে গঠিত হয়। কোনো নতুন code লেখার আগেই, agent যদি ২,০০০ লাইনের একটি file পড়ার সিদ্ধান্ত নেয়, তবে তার জন্য পাঁচ অঙ্কের (five-figure) token খরচ হবে।

Tokenizer সংক্রান্ত দুটি বিষয় বিভ্রান্তি তৈরি করতে পারে। প্রথমত, এগুলো model-specific। ২০২৬ সালের জুলাই পর্যন্ত, Opus 4.7 এবং পরবর্তী সংস্করণ, Sonnet 5, এবং Fable 5 একটি নতুন tokenizer ব্যবহার করে। এটি আগের Claude model-গুলোর তুলনায় একই টেক্সটের জন্য প্রায় ৩০% বেশি token তৈরি করে (নির্ভুল পরিমাণ কন্টেন্টের ওপর নির্ভর করে)। এর ফলে token-এর দাম না বাড়লেও, আপনার token budget বা বরাদ্দ পরিবর্তিত হয়ে যায়। দ্বিতীয়ত, tiktoken, যা প্রায় প্রতিটি ব্লগ পোস্টে ব্যবহৃত হয়, সেটি হলো OpenAI-এর tokenizer। এটি সাধারণ টেক্সটের ক্ষেত্রে Claude-এর তুলনায় প্রায় ১৫–২০% কম token গণনা করে, এবং code-এর ক্ষেত্রে এই ব্যবধান আরও বেশি। একমাত্র নির্ভরযোগ্য গণনা হলো count_tokens endpoint, যা নিচে আলোচনা করা হয়েছে।

আপনার কোডিং সেশনের খরচ কেন এত বেশি হয়

Claude-এর প্রতিটি বিল, তা API invoice হোক বা subscription limit, একটি মাত্র মাপকাঠির ওপর নির্ভর করে: input tokens এবং output tokens। pricing page দেখে মনে হতে পারে বিষয়টি সহজ: প্রতি মিলিয়ন input token-এর জন্য নির্দিষ্ট ডলার এবং প্রতি মিলিয়ন output token-এর জন্য নির্দিষ্ট ডলার। কিন্তু এটি যা বলে না তা হলো, একটি agentic coding session-এ input side-এর খরচ অনুমানের চেয়ে অনেক বেশি হয়। কারণ প্রতিটি turn-এ পুরো conversation-টি পুনরায় পাঠানো হয়। আমি পনের বছর ধরে metered infrastructure বিক্রি করছি, এবং tokens হলো প্রথম এমন একটি মাপকাঠি যেখানে বেশিরভাগ গ্রাহক নিশ্চিতভাবে বলতে পারেন না যে খরচটি কেন বাড়ছে। এই পাঠে আমরা শিখব: একটি agentic session-এ কী কী input এবং output হিসেবে গণ্য হয়, কেন resend loop এত ব্যয়বহুল, কেন prompt caching হিসাব বদলে দেয়, এবং কোন বিষয়গুলো আসলে খরচ নিয়ন্ত্রণ করে।

সবকিছুই ইনপুট: মিটার আসলে যা গণনা করে

মানুষ মনে করে তারা Claude-এর লেখা কোডের জন্য টাকা দিচ্ছে। একটি agentic session-এ, এটি একটি ক্ষুদ্র অংশ মাত্র। Input tokens — যার রেট কম কিন্তু ভলিউম অনেক বেশি — এর মধ্যে অন্তর্ভুক্ত:

• The system prompt. Claude Code-এর নিজস্ব harness instructions, এবং আপনার CLAUDE.md ও memory files, যা session শুরু করার সময় লোড করা হয় এবং পরবর্তী প্রতিটি request-এ উপস্থিত থাকে।
• Tool definitions. এজেন্ট যে tool schema গুলো কল করতে পারে তার প্রতিটি। প্রতিটি আপনি কানেক্ট করা MCP server এই fixed overhead বাড়িয়ে দেয় — যদিও Claude Code এখন ডিফল্টভাবে পূর্ণ MCP tool definitions স্থগিত রাখে, তাই একটি tool প্রথমবার ব্যবহার না করা পর্যন্ত শুধুমাত্র tool name গুলো context-এ থাকে; এটি খরচ কিছুটা কমায় কিন্তু পুরোপুরি দূর করে না।
• এজেন্ট যে প্রতিটি ফাইল পড়ে। একটি source file-এর Read মানে পুরো ফাইলটি context-এ চলে আসে এবং সেটি সেখানেই থাকে।
• প্রতিটি tool result. Test runs, grep output, terminal spew, build logs — এই সব কিছুই input tokens হিসেবে ফিরে আসে। একটি failing test suite যা 8,000 লাইন প্রিন্ট করে, তা আপনাকে একটি ছোট বইয়ের সমান বিল করতে পারে।
• এ পর্যন্ত হওয়া সম্পূর্ণ কথোপকথন, যা প্রতিটি turn-এ পুনরায় পাঠানো হয়। এটি একটি আলাদা অনুচ্ছেদের দাবি রাখে।

কেন প্রতিবার নতুন করে সব তথ্য পাঠাতে হয়

Claude API হলো stateless। এটি রিকোয়েস্টের মাঝখানে আপনার সেশন মনে রাখে না — আসলে কিছুই মনে রাখে না। তাই ২ নম্বর টার্নে, ক্লায়েন্ট ১ম টার্নের তথ্য, তার রেসপন্স এবং আপনার নতুন মেসেজটি পাঠায়। ৫০ নম্বর টার্নে, এটি ১ম থেকে ৪৯ নম্বর টার্ন পর্যন্ত সব তথ্য পুনরায় পাঠায় — প্রতিটি ফাইল রিড, প্রতিটি টুল রেজাল্ট, প্রতিটি diff — এবং সাথে ৫০ নম্বর টার্নটি। মডেলটি প্রতিবার পুরো ট্রান্সক্রিপ্টটি পুনরায় পড়ে, এবং সেই রি-রিড করা প্রতিটি টোকেনের জন্য ইনপুট হিসেবে বিল করা হয়।

এর ফলাফল হলো: প্রতি টার্নের খরচ সেশনের দৈর্ঘ্যের সাথে রৈখিকভাবে (linearly) বৃদ্ধি পায়, এবং মোট সেশন খরচ প্রায় দ্বিঘাত হারে (quadratically) বৃদ্ধি পায়। ৩ নম্বর টার্নে একটি মেসেজের খরচ যদি অর্ধেক সেন্ট হয়, তবে ৬০ নম্বর টার্নে একই এক লাইনের প্রশ্নের জন্য খরচ তার ২০ গুণ হতে পারে, কারণ এতে ৬০টি টার্নের তথ্য বহন করা হচ্ছে। "আমার বিল এত বেশি কেন" — এই ধরনের বেশিরভাগ সমস্যার মূল কারণ হলো এই বিষয়টি। এটি Claude-এর কোনো বিশেষ বৈশিষ্ট্য নয় — প্রতিটি stateful-এর মতো মনে হওয়া LLM প্রোডাক্ট আসলে একটি stateless API যা ব্যাকএন্ডে একটি resend loop ব্যবহার করে।

Output: আপনি যা দেখেন, এবং যা দেখেন না তা সহ

Output tokens অত্যন্ত ব্যয়বহুল — বর্তমান lineup অনুযায়ী input rate এর চেয়ে পাঁচ গুণ বেশি ($5/$25 Opus 4.8-এ, $3/$15 Sonnet 5-এ, এবং July 2026 অনুযায়ী $1/$5 Haiku 4.5-এ)। Output এর মধ্যে Claude দ্বারা তৈরি text এবং code অন্তর্ভুক্ত, এবং thinking tokens অন্তর্ভুক্ত: যা উত্তর দেওয়ার আগে model এর অভ্যন্তরীণ reasoning। এখানে দুটি বিষয় গুরুত্বপূর্ণ। Thinking এর জন্য output rate অনুযায়ী বিল করা হয় এবং এটি max_tokens এর অন্তর্ভুক্ত — একটি API response যা stop_reason: "max_tokens" এর মাধ্যমে শেষ হয়ে যায় এবং একটি truncated উত্তর মানে হলো উত্তর দেওয়ার আগেই thinking বাজেট শেষ করে ফেলেছে। এবং বর্তমান model গুলোর ক্ষেত্রে reasoning summary হয়তো প্রদর্শিত নাও হতে পারে — Opus 4.8, Sonnet 5, এবং Fable 5 ডিফল্টভাবে এটি বাদ দেয় — কিন্তু thinking প্রক্রিয়াটি সম্পন্ন হয় এবং এর জন্য বিল করা হয়। অদৃশ্য মানেই ফ্রি নয়।

Claude Code ডিফল্টভাবে extended thinking সক্ষম করে কারণ এটি multi-step কাজের মান উল্লেখযোগ্যভাবে উন্নত করে, এবং ডিফল্ট বাজেট প্রতি request এ হাজার হাজার token পর্যন্ত হতে পারে। সহজ কাজের ক্ষেত্রে আপনি এটি কমিয়ে দিতে পারেন: /effort বা /model ব্যবহার করে effort level কমিয়ে দিন, অথবা /config এ thinking settings অ্যাডজাস্ট করুন। এটি একটি প্রকৃত cost lever, কোনো কুসংস্কার নয়।

Prompt caching গণিত পরিবর্তন করে দেয়

Prompt caching এর কারণেই বারবার একই রিকোয়েস্ট পাঠানোর ফলে অতিরিক্ত খরচ হয় না। API আপনার প্রম্পটের একটি স্থির prefix — যেমন system prompt, tool definitions, বা conversation history — ক্যাশ করে রাখতে পারে। পরবর্তী রিকোয়েস্টের সময় এটি অনেক কম খরচে প্রদান করা হয়। ২০২৬ সালের জুলাই অনুযায়ী মাল্টিপ্লায়ারগুলো হলো: একটি cache write এর খরচ বেস ইনপুট রেটের ১.২৫× (১-ঘন্টার ভেরিয়েন্টের জন্য ২×), এবং একটি cache read এর খরচ ০.১×। Write এর জন্য প্রিমিয়াম দিতে হয়; আর read করার ক্ষেত্রে ৯০% ডিসকাউন্ট পাওয়া যায়। একটি মাত্র read এর মাধ্যমে ৫ মিনিটের write প্রিমিয়ামের খরচ অনায়াসেই উঠে আসে।

Claude Code আপনার জন্য ক্যাশিং ম্যানেজ করে। একটি সচল সেশনে প্রায় সব বড় রিকোয়েস্ট ক্যাশ থেকে সার্ভ করা হয়। তবে ডিফল্ট ক্যাশ শেষ ব্যবহারের পর পাঁচ মিনিট পর্যন্ত কার্যকর থাকে। আপনি যদি কফি খেতে একটু বেশি সময় নিয়ে ফেলেন এবং ফিরে এসে মেসেজ পাঠান, তবে ক্যাশটি এক্সপায়ার হয়ে যায়। ফলে সম্পূর্ণ প্রিফিক্সটি ০.১× খরচে read করার পরিবর্তে ১.২৫× খরচে পুনরায় write করতে হয়। ১৫০K-token সেশনের ক্ষেত্রে, একটি মাত্র cold turn এর খরচ এক ডজন warm turn এর খরচের চেয়েও বেশি হতে পারে। এটি একটি আপাতবিরোধী বিষয় যা মনে রাখা জরুরি: অবিরত কাজের চেয়ে বিরতি দিয়ে কাজ করা বেশি ব্যয়বহুল হতে পারে, কারণ TTL পার হওয়ার পর প্রতিটি বিরতি আপনার পরবর্তী turn কে একটি সস্তা read থেকে একটি ব্যয়বহুল re-write এ রূপান্তরিত করে। কাজের সময়গুলো ছোট ছোট ভাগে ভাগ করে নিন; প্রতি দশ মিনিট অন্তর একটি করে মেসেজ পাঠিয়ে একটি বিশাল সেশন চালানো এড়িয়ে চলুন।

আপনি যদি আপনার নিজস্ব VPS অ্যাপ্লিকেশনের মাধ্যমে API কল করেন, তবে আপনি এই সুবিধাগুলো বিনামূল্যে পাবেন না। একটি সাধারণ ভুল হলো system prompt-এ timestamp বা request ID যুক্ত করা। এর ফলে প্রতি রিকোয়েস্টে প্রিফিক্স বাইট পরিবর্তিত হয় এবং ক্যাশিং নিষ্ক্রিয় হয়ে যায়। এর লক্ষণ হলো একই ধরনের কলের ক্ষেত্রে usage.cache_read_input_tokens এর মান শূন্য থাকা।

সূত্র এবং একটি উদাহরণ

"একটি সেশনের খরচ $X" — এমন যেকোনো কথা উপেক্ষা করুন। সেশনের খরচ মডেলভেদে অনেক ভিন্ন হতে পারে। সঠিক পদ্ধতি হলো এই সূত্রটি:

turn cost = (uncached input      x base input price)
          + (cache writes        x 1.25 x base input price)
          + (cache reads         x 0.10 x base input price)
          + (output incl. thinking x output price)

session cost = sum over all turns

Claude Opus 4.8 এর একটি উদাহরণ দেওয়া হলো। ২০২৬ সালের জুলাই অনুযায়ী, এর ইনপুট টোকেনের খরচ প্রতি ১০ লক্ষ টোকেনে $5 এবং আউটপুট টোকেনের খরচ প্রতি ১০ লক্ষ টোকেনে $25। একটি মাঝারি দৈর্ঘ্যের সেশনের টার্ন যেখানে মোট ৮০,০০০ টোকেন কনটেক্সট আছে: ৭৫,০০০ টোকেন ক্যাশ থেকে পড়া হয়েছে, ৩,০০০ টোকেন নতুনভাবে লেখা হয়েছে, ২,০০০ টোকেন আনক্যাশড ইনপুট এবং ১,৫০০ টোকেন আউটপুট (thinking সহ)।

• Cache reads: 75,000 × $0.50/M = $0.0375
• Cache writes: 3,000 × $6.25/M = $0.019
• Uncached input: 2,000 × $5/M = $0.010
• Output: 1,500 × $25/M = $0.0375

প্রতি টার্নের খরচ প্রায় $0.10; এই ধরণের ৫০টি টার্নের খরচ হবে প্রায় $5। এখন ক্যাশ এক্সপায়ার হওয়ার পরের একই টার্নের হিসাব দেখুন: সম্পূর্ণ ৮০,০০০ টোকেন $6.25/M হিসেবে পুনরায় লিখতে হবে, যা আউটপুট ছাড়াই $0.50 — অর্থাৎ একই কাজের জন্য ওয়ার্ম টার্নের তুলনায় প্রায় পাঁচ গুণ বেশি খরচ। এই ব্যবধানটিই ক্যাশিংয়ের মূল বিষয়টি প্রকাশ করে।

ভবিষ্যদ্বাণী নয়, বরং ক্যালিব্রেশনের জন্য: ২০২৬ সালের জুলাই পর্যন্ত Anthropic-এর প্রকাশিত তথ্য অনুযায়ী, এন্টারপ্রাইজ Claude Code ব্যবহারের ক্ষেত্রে একজন ডেভেলপারের প্রতিদিনের গড় খরচ প্রায় $13 — মাসে $150–250 — যেখানে ৯০% ব্যবহারকারীর খরচ প্রতিদিন $30 এর নিচে থাকে। আপনার খরচ নির্ভর করবে মডেল নির্বাচন, সেশন হাইজিন এবং কোডবেস সাইজের ওপর; আর এই কারণেই নিচের বিষয়গুলো গুরুত্বপূর্ণ।

আপনার ব্যবহারের তথ্য দেখা

Claude Code-এ, কমান্ডটি হলো /usage (/cost এখনও কাজ করে — এটি একটি alias)। উপরের Session ব্লকটি বর্তমান সেশনের জন্য token পরিসংখ্যান এবং স্থানীয়ভাবে গণনা করা খরচের হিসাব দেখায়; subscription plan ব্যবহারকারীদের ক্ষেত্রে, একই স্ক্রিনে আপনার plan-limit বার এবং সাম্প্রতিক ব্যবহারের বিস্তারিত বিবরণ (skills, subagents, plugins, এবং individual MCP servers অনুযায়ী) দেখা যায়। API অ্যাকাউন্টের সঠিক বিলিং তথ্যের জন্য, Claude Console-এর usage পেজটিই চূড়ান্ত উৎস — CLI-তে দেখানো সংখ্যাটি একটি estimate মাত্র। /context কমান্ডটি context window-এ কী কী আছে তার একটি রঙিন গ্রিড দেখায় — যেমন system prompt, tools, MCP definitions, files, এবং history; এটি একটি অতিরিক্ত বড় CLAUDE.md বা অতিরিক্ত ডেটা পাঠানো MCP server শনাক্ত করার দ্রুততম উপায়; প্রতিটি আইটেমের বিস্তারিত বিবরণ পেতে all ব্যবহার করুন।

API থেকে প্রতিটি response আপনাকে বিস্তারিত তথ্য প্রদান করে:

response = client.messages.create(model="claude-sonnet-5", max_tokens=2048,
                                  messages=messages)
u = response.usage
total_prompt = u.input_tokens + u.cache_creation_input_tokens + u.cache_read_input_tokens
print(f"uncached={u.input_tokens} written={u.cache_creation_input_tokens} "
      f"read={u.cache_read_input_tokens} output={u.output_tokens}")

মনে রাখবেন, input_tokens শুধুমাত্র uncached remainder — প্রকৃত prompt size হলো তিনটি input field-এর সমষ্টি। যদি কোনো agent এক ঘণ্টা ধরে চলার পর input_tokens: 4000 দেখায়, তবে সেটি সস্তা নয়; বাকি 200,000 token cache থেকে নেওয়া হয়েছে। কমান্ড পাঠানোর আগে হিসাব করতে token-counting endpoint ব্যবহার করুন — এটি বিনামূল্যে ব্যবহার করা যায়, এর নিজস্ব rate limit আছে, এবং আপনি যে model-টি উল্লেখ করবেন তার tokenizer অনুযায়ী গণনা করে (ফলাফলটিকে একটি কাছাকাছি estimate হিসেবে ধরুন; বিলিং প্রকৃত request অনুযায়ী নির্ধারিত হয়):

count = client.messages.count_tokens(model="claude-sonnet-5",
                                     messages=[{"role": "user", "content": big_file}])
print(count.input_tokens)

উপরের কারণে কখনোই tiktoken করবেন না।

Subscription plans বনাম pay-as-you-go

এই গাইডের মেকানিজম সব জায়গায় একই; শুধুমাত্র পেমেন্ট পদ্ধতি আলাদা। API key ব্যবহার করলে, Anthropic প্রতিটি token-এর জন্য নির্ধারিত রেটে pay-as-you-go হিসেবে বিল করবে — উপরে উল্লিখিত প্রতিটি সংখ্যা প্রকৃত অর্থ প্রকাশ করে। Claude subscription (Pro, Max, Team, Enterprise) ব্যবহার করলে, Claude Code ব্যবহারের জন্য আপনার প্ল্যানে অন্তর্ভুক্ত allowance ব্যবহার করা হয়: ২০২৬ সালের জুলাই পর্যন্ত এটি একটি rolling five-hour session window এবং একটি weekly window, যা সব model এবং claude.ai chat-এর মধ্যে শেয়ার করা হয়; এখানে /usage ডলারের পরিমাণটি কেবল তথ্যমূলক, এটি কোনো বিল নয়। যদি কোনো window শেষ হয়ে যায়, তবে আপনি রিসেট সময়সহ "You've hit your session limit" অথবা "You've hit your weekly limit" বার্তাটি দেখতে পাবেন — এবং /model দিয়ে model পরিবর্তন করলে পুনরায় অ্যাক্সেস পাবেন না, কারণ window গুলো সব model-এর জন্য শেয়ার করা। আপনি চাইলে usage credits সক্রিয় করতে পারেন, যা /usage-credits দিয়ে ম্যানেজ করা হয়, যাতে লিমিট অতিক্রম করার পর আরও ব্যবহার করা যায়। আমি এখানে প্ল্যানের quota গুলো উল্লেখ করছি না: এই বিষয়ের মধ্যে এগুলো সবচেয়ে পরিবর্তনশীল সংখ্যা, তাই আপনি বরং claude.com/pricing এবং আপনার নিজস্ব /usage bar চেক করুন। Subscription ব্যবহার করলেও token মেকানিজম গুরুত্বপূর্ণ — একটি অপচয়কারী session আপনার window ঠিক একইভাবে শেষ করে দেয় যেভাবে ডলার শেষ হয়। Subscription সংক্রান্ত তথ্যের জন্য কোন Claude plan আপনার ব্যবহারের জন্য উপযুক্ত দেখুন।

কার্যকর পদ্ধতিসমূহ

• Agent-এর রিড রেঞ্জ সীমিত করুন। "auth.py-এর validation bug ঠিক করুন" বললে একটি ফাইল পড়া হয়; কিন্তু "এই codebase উন্নত করুন" বললে চল্লিশটি ফাইল পড়া হয়। CLAUDE.md-কে হালকা রাখুন — এটি প্রতিটি session-এ লোড হয়, তাই শুধুমাত্র প্রয়োজনীয় তথ্য রাখুন — এবং workflow-এর জন্য নির্দিষ্ট নির্দেশাবলী এমন skills-এ রাখুন যা প্রয়োজন অনুযায়ী load হয়।
• স্পষ্ট এবং সংক্ষিপ্ত রাখুন। সম্পর্কহীন কাজের মাঝে /clear ব্যবহার করুন — অপ্রাসঙ্গিক context বারবার পাঠানো হয় এবং প্রতিটি বার নতুন করে বিল করা হয়। একটি দীর্ঘ কাজের ক্ষেত্রে, /compact Focus on the failing tests and the diff ইতিহাস সংক্ষেপিত করে রাখে যাতে খরচ বহুগুণ বেড়ে না যায়।
• সঠিক মডেল নির্বাচন করুন। ২০২৬ সালের জুলাই মাসের প্রাথমিক মূল্য অনুযায়ী, প্রতি মিলিয়ন টোকেনে $2/$10 খরচে Sonnet বেশিরভাগ কোডিংয়ের কাজ করতে পারে ($3/$15 রেট, যেখানে Opus-এর রেট $5/$25), এবং log triage-এর মতো যান্ত্রিক subagent কাজের জন্য $1/$5 রেটের Haiku একটি সঠিক টুল। /model সেশনের মাঝখানে মডেল পরিবর্তন করতে পারে।
• অতিরিক্ত আউটপুট প্রি-ফিল্টার করুন। Claude দেখার আগে একটি hook ব্যবহার করে test run থেকে শুধুমাত্র failure গুলো grep করে নিলে ২০,০০০ টোকেনের tool result মাত্র ৩০০ টোকেনে নেমে আসে; এবং এটি প্রতিটি পরবর্তী resend-এর ক্ষেত্রে কাজ করে।
• অ-ইন্টারঅ্যাক্টিভ কাজগুলো ব্যাচ প্রসেস করুন। আপনার নিজস্ব API pipeline-এর জন্য — যেমন classification, bulk review, বা nightly jobs — Batches API ব্যবহার করলে asynchronous ডেলিভারির বিনিময়ে একই মডেলে ৫০% ছাড় পাওয়া যায়।
• Cache-এর সময়ের গুরুত্ব দিন। একটানা কাজ করুন। একটি বিচ্ছিন্ন tmux এবং VPS-এ চলা Claude Code session অলস অবস্থায় কোনো খরচ করে না — টোকেন শুধুমাত্র একটি turn চলার সময় খরচ হয় — কিন্তু অলস অবস্থায় থাকাকালীন warm cache হারিয়ে যায়, এবং পরবর্তী turn-এ পুনরায় সেটি লিখতে খরচ হয়।

FAQ

Claude Code-এ একটি কোডিং সেশনে কতগুলো token ব্যবহার হয়?

এর কোনো নির্দিষ্ট সংখ্যা নেই — ফাইল এবং হিস্ট্রি জমা হওয়ার ফলে একটি মিড-সেশন টার্নে সাধারণত হাজার হাজার prompt token ব্যবহৃত হয়। একটি ওয়ার্কিং সেশনে লক্ষ লক্ষ token ব্যবহৃত হতে পারে, যার বেশিরভাগই ক্যাশ (cache) থেকে আসে এবং বেস রেটের তুলনায় মাত্র দশ ভাগের এক ভাগ খরচ হয়। ক্যালিব্রেশনের জন্য, ২০২৬ সালের জুলাই পর্যন্ত Anthropic-এর প্রকাশিত এন্টারপ্রাইজ পরিসংখ্যান অনুযায়ী, প্রতি ডেভেলপার প্রতি সক্রিয় দিনে গড়ে প্রায় $13 খরচ হয় এবং ৯০% ব্যবহারকারীর খরচ $30-এর নিচে থাকে। আপনার নিজস্ব সেশনে /usage চালান; এটি পর্যবেক্ষণ করলে যেকোনো প্রকাশিত গড় মানের চেয়ে ভালো ধারণা পাবেন।

আমি যখন thinking tokens দেখতে পাই না, তখনও কি সেগুলোর জন্য টাকা দিতে হয়?

হ্যাঁ। Thinking tokens-এর জন্য output token হিসেবে চার্জ করা হয় — যা দামী রেট — এবং এগুলো max_tokens হিসেবে গণ্য হয়। বর্তমান মডেলগুলো reasoning summary ইন্টারফেসে না দেখালেও এগুলোর জন্য বিল করে। যদি দৃশ্যমান উত্তর শেষ হওয়ার আগেই stop_reason: "max_tokens" দিয়ে রেসপন্সটি কেটে যায়, তবে সম্ভবত thinking-এর কারণে বাজেট শেষ হয়ে গেছে। Claude Code-এ, যে কাজগুলোতে গভীর reasoning প্রয়োজন নেই সেগুলোর জন্য /effort ব্যবহার করে effort level কমিয়ে দিন।

Claude Code-এ একটি দীর্ঘ সেশনে প্রতি মেসেজে খরচ কেন বেড়ে যায়?

কারণ API হলো stateless: প্রতিটি টার্নে সম্পূর্ণ কথোপকথনটি পুনরায় পাঠানো হয় — প্রতিটি ফাইল রিড, tool result, এবং পূর্ববর্তী আলাপচারিতা — যা billed input হিসেবে গণ্য হয়। ফলে ৫০ নম্বর টার্নে ১ থেকে ৪৯ নম্বর টার্নের ডেটাও অন্তর্ভুক্ত থাকে। Prompt caching বারবার আসা prefix-এর জন্য বেস ইনপুট প্রাইসের প্রায় দশ ভাগের এক ভাগ খরচ করে, কিন্তু prefix নিজেই ক্রমাগত বাড়তে থাকে। এছাড়া cache TTL পার হওয়ার পর পরবর্তী টার্নটি পূর্ণ মূল্যে পুনরায় লিখতে হয়। /compact হিস্ট্রি ছোট করে; /clear এটি রিসেট করে।

আমি কীভাবে আমার Claude token ব্যবহার এবং খরচ পরীক্ষা করব?

Claude Code-এ, /usage সেশনের token পরিসংখ্যান, লোকাল খরচের প্রাক্কলন এবং সাবস্ক্রিপশনের প্ল্যান-লিমিট বার দেখায় (/cost হলো একটি alias); /context উইন্ডোতে কী দেখাচ্ছে তা দেখায়। সঠিক API বিলিং জানার জন্য Claude Console-এর usage পেজ ব্যবহার করুন। আপনার নিজস্ব কোডে, response.usage পড়ুন — input_tokens, cache_creation_input_tokens, এবং cache_read_input_tokens যোগ করলে প্রকৃত prompt সাইজ পাওয়া যাবে — এবং আগে থেকে প্রাক্কলন করতে count_tokens endpoint ব্যবহার করুন, কখনো tiktoken নয়।