Claude Code-এ 80,000 token খরচ কেন হয়?

Claude-এ token কী?

একটি token হলো Claude যে text পড়ে ও লেখে তার একক: একটি শব্দের অংশ, যা প্রায় 3.5টি English character-এর সমান। এই হিসাব Anthropic-এর নিজস্ব glossary থেকে এসেছে। Space ও punctuation ধরলে প্রতি শব্দে token-এর সংখ্যা 1-এর চেয়ে যথেষ্ট বেশি হয়। তাই 1,000 শব্দের prose-এ সহজেই 1,300-এর বেশি token থাকে। Code প্রতি লাইনে বেশি token ব্যবহার করে। Braces, operators, underscores এবং indentation English text-এর তুলনায় প্রতি character-এ বেশি token তৈরি করে। কয়েক-শো লাইনের source file-এ সাধারণত কয়েক হাজার token থাকে। Agent যদি 2,000 লাইনের একটি file পড়ার সিদ্ধান্ত নেয়, তাহলে নতুন code লেখার আগেই এতে পাঁচ অঙ্কের token খরচ হতে পারে।

Tokenizers সম্পর্কে দুটি বিষয় অনেককে বিভ্রান্ত করে। প্রথমত, tokenizer model-নির্ভর। July 2026 অনুযায়ী, Opus 4.7 এবং পরবর্তী version, Sonnet 5 এবং Fable 5 একটি নতুন tokenizer ব্যবহার করে। একই text-এর জন্য এটি আগের Claude model-গুলোর তুলনায় প্রায় 30% বেশি token তৈরি করে। Exact বৃদ্ধি content অনুযায়ী পরিবর্তিত হয়। ফলে প্রতি-token price না বাড়লেও token-ভিত্তিক বাজেটের হিসাব বদলে যায়। দ্বিতীয়ত, tiktoken হলো সেই library, যেটি প্রায় প্রতিটি blog post-এ ব্যবহৃত হয়। এটি OpenAI-এর tokenizer এবং সাধারণ text-এ Claude-এর token সংখ্যা প্রায় 15–20% কম দেখায়। Code-এ এই পার্থক্য আরও বেশি। নির্ভরযোগ্য একমাত্র count হলো count_tokens endpoint, যা নিচে ব্যাখ্যা করা হয়েছে।

আপনার coding session-এর খরচ এমন কেন

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

সবকিছুই input: meter আসলে যা গণনা করে

অনেকে মনে করেন, Claude যে code লেখে তার জন্যই তারা অর্থ পরিশোধ করেন। Agentic session-এ এটি মোট খরচের ছোট অংশ। কম দামের হলেও পরিমাণে অনেক বেশি input token-এর মধ্যে রয়েছে:

• System prompt। Claude Code-এর নিজস্ব harness instruction, পাশাপাশি আপনার CLAUDE.md ও memory file—যেগুলো session শুরুর সময় load হয় এবং এরপর প্রতিটি request-এ উপস্থিত থাকে।
• Tool definition। Agent যে প্রতিটি tool call করতে পারে, তার schema। আপনি যে প্রতিটি MCP server সংযুক্ত করেন, তা এই নির্দিষ্ট overhead বাড়ায়। তবে Claude Code এখন default হিসেবে সম্পূর্ণ MCP tool definition পরে load করে। তাই কোনো tool প্রথমবার ব্যবহার না করা পর্যন্ত context-এ শুধু tool name থাকে। এতে খরচ কমে, কিন্তু পুরোপুরি দূর হয় না।
• Agent যে প্রতিটি file পড়ে। কোনো source file-এর Read করলে সম্পূর্ণ file-টি context-এ যুক্ত হয় এবং সেখানেই থেকে যায়।
• প্রতিটি tool result। Test run, grep output, terminal output, build log—সবই input token হিসেবে ফিরে আসে। কোনো failing test suite যদি 8,000 line output করে, তাহলে তার জন্য আপনাকে একটি ছোট বইয়ের সমান token-এর বিল দিতে হয়।
• এখন পর্যন্ত সম্পূর্ণ conversation, প্রতিটি turn-এ আবার পাঠানো হয়। এই বিষয়টির জন্য আলাদা section প্রয়োজন।

প্রতিবার পুনরায় পাঠানোর খরচ কেউ বহন করে না

Claude API stateless। অনুরোধগুলোর মধ্যে এটি আপনার session মনে রাখে না; কোনো কিছুই তা করে না। তাই turn 2-এ client turn 1, তার response এবং আপনার নতুন message পাঠায়। turn 50-এ এটি turn 1 থেকে turn 49 পর্যন্ত সব turn, পড়া প্রতিটি file, প্রতিটি tool result, প্রতিটি diff এবং turn 50 আবার পাঠায়। model প্রতিবার পুরো transcript পুনরায় পড়ে, এবং পুনরায় পড়া প্রতিটি token-এর input হিসেবে বিল হয়।

এর ফল হলো, session যত দীর্ঘ হয়, প্রতি turn-এর খরচ প্রায় linear হারে বাড়ে এবং পুরো session-এর মোট খরচ প্রায় quadratic হারে বাড়ে। একই এক লাইনের প্রশ্নের জন্য turn 3-এ যে message-এর খরচ half cent ছিল, turn 60-এ তার খরচ বিশ গুণ হতে পারে, কারণ এর সঙ্গে ষাটটি turn-এর সব বিষয় পুনরায় পাঠানো হচ্ছে। “আমার bill এত বেশি হলো কেন” ধরনের অধিকাংশ ticket-এর মূল কারণ এই একটি বিষয়। এটি Claude-এর বিশেষ কোনো আচরণ নয়; stateful মনে হওয়া প্রতিটি LLM product-এর পেছনে আসলে resend loop-সহ একটি stateless API থাকে।

আউটপুট: আপনি যা দেখেন, এবং যে চিন্তাপ্রক্রিয়া দেখেন না

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

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

Prompt caching হিসাব বদলে দেয়

Prompt caching-এর কারণেই resend loop-এর খরচ নিয়ন্ত্রণে থাকে। API আপনার prompt-এর স্থিতিশীল prefix, system prompt, tool definitions এবং conversation history cache করতে পারে। পরের request-এ এটি সেই অংশের জন্য মূল দামের একটি ভগ্নাংশ নেয়। July 2026 অনুযায়ী multiplier হলো: cache write-এর খরচ base input rate-এর 1.25× (1-hour variant-এর জন্য 2×), আর cache read-এর খরচ 0.1×। Write-এর জন্য অতিরিক্ত খরচ আছে; read-এ 90% ছাড় রয়েছে। একটি read-ই 5-minute write-এর অতিরিক্ত খরচের তুলনায় বেশি সাশ্রয় করে।

Claude Code আপনার হয়ে caching পরিচালনা করে। সুস্থ session-এ ওই বড় resend-এর প্রায় পুরোটাই cache থেকে সরবরাহ করা হয়। তবে default cache শেষবার ব্যবহারের পর five minutes পর্যন্ত থাকে। দীর্ঘ coffee break-এর পর ফিরে এসে message পাঠালে cache expired হয়ে যায়। তখন পুরো সঞ্চিত prefix 0.1× দামে read না হয়ে 1.25× দামে আবার write হয়। 150K-token session-এ এমন একটি cold turn-এর খরচ এক ডজনেরও বেশি warm turn-এর খরচ ছাড়িয়ে যেতে পারে। মনে রাখার মতো বিপরীতধর্মী ফল হলো: কিছুক্ষণ কাজ বন্ধ রেখে আবার শুরু করার ছন্দ continuous work-এর চেয়ে বেশি খরচ করতে পারে, কারণ TTL-এর চেয়ে দীর্ঘ প্রতিটি বিরতি পরের turn-কে সস্তা read থেকে ব্যয়বহুল re-write-এ বদলে দেয়। একটানা দীর্ঘ session-এ প্রতি দশ মিনিটে একটি করে message না পাঠিয়ে নির্দিষ্ট সময়ের work stint-এ কাজ করুন।

আপনি যদি VPS-এ নিজের application থেকে API call করেন, তাহলে এর কোনো সুবিধাই স্বয়ংক্রিয়ভাবে পাবেন না। এ ক্ষেত্রে সাধারণ self-inflicted wound হলো system prompt-এ timestamp বা request ID interpolate করা। এতে প্রতিটি request-এ prefix-এর byte পরিবর্তিত হয় এবং নীরবে caching অকার্যকর হয়ে যায়। এর লক্ষণ হলো একই রকম দেখতে call-গুলোর ক্ষেত্রে usage.cache_read_input_tokens শূন্যে থাকা।

সূত্রটি, একটি সম্পূর্ণ উদাহরণসহ

যারা বলেন, “একটি session-এর খরচ $X”—তাদের কথায় নির্ভর করবেন না। Session-এর খরচে দুই order of magnitude পর্যন্ত পার্থক্য হতে পারে। কার্যকর সূত্রটি হলো:

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-এর একটি সম্পূর্ণ উদাহরণ দেখা যাক। July 2026 অনুযায়ী এর দাম প্রতি million input token-এ $5 এবং প্রতি million output token-এ $25। Session-এর মাঝামাঝি একটি turn-এ মোট 80,000 token-এর accumulated context রয়েছে: cache থেকে 75,000 read করা হয়েছে, নতুন করে 3,000 write করা হয়েছে, cache-এ না থাকা 2,000 fresh input রয়েছে, এবং thinking-সহ output token 1,500।

• Cache read: 75,000 × $0.50/M = $0.0375
• Cache write: 3,000 × $6.25/M = $0.019
• Cache-এ না থাকা input: 2,000 × $5/M = $0.010
• Output: 1,500 × $25/M = $0.0375

এই turn-এর খরচ প্রায় $0.10; এমন 50টি turn-এর খরচ প্রায় $5। এবার cache-এর মেয়াদ শেষ হওয়ার পরে একই turn বিবেচনা করুন: 80,000 token পুরোটা $6.25/M দরে নতুন করে write করতে $0.50 লাগবে, output-এর খরচ যোগ করার আগেই। এটি cache সক্রিয় থাকা পুরো turn-এর মোট খরচের প্রায় পাঁচ গুণ, অথচ কাজ একই। একটি সংখ্যায় caching-এর সম্পূর্ণ প্রভাব এটাই। Vendor তুলনা করার সৎ উপায়ও এই চারটি line, কারণ প্রকাশিত মূল্যে cache read এবং thinking-এর খরচ পুরোপুরি ধরা হয় না। আর তিনটি বাস্তব job-এ এগুলো চালালে দেখা যায় Claude-এর bill OpenAI-এর bill-এর চেয়ে বেশি না কম হয়।

একটি turn-এর বদলে billing unit সম্পর্কে ধারণা পেতে চাইলে এক million token-এ কত page, file এবং dollar হয় একই হিসাব আরও বড় পরিসরে দেখায়। এটি ভবিষ্যদ্বাণী নয়, বরং তুলনার ভিত্তি হিসেবে দেখুন: July 2026 অনুযায়ী enterprise Claude Code deployment-এর জন্য Anthropic-এর প্রকাশিত পরিসংখ্যানে active day-প্রতি developer-এর গড় খরচ প্রায় $13 এবং মাসে $150–250; 90% user প্রতিদিন $30-এর নিচে থাকে। আপনার প্রকৃত খরচ model choice, session hygiene এবং codebase-এর আকারের ওপর নির্ভর করে। তাই নিচের নিয়ন্ত্রণের বিষয়গুলো গুরুত্বপূর্ণ।

নিজের ব্যবহার দেখা

Claude Code-এ কমান্ডটি হলো /usage (/cost এখনও কাজ করে, এটি একটি alias)। শীর্ষের Session block-এ বর্তমান session-এর token পরিসংখ্যান এবং স্থানীয়ভাবে গণনা করা খরচের আনুমানিক হিসাব দেখা যায়। Subscription plan-এ একই screen-এ plan-limit bar এবং সাম্প্রতিক ব্যবহার skills, subagents, plugins ও পৃথক MCP server অনুযায়ী ভাগ করে দেখানো হয়। API account-এর ক্ষেত্রে নির্ভরযোগ্য billing তথ্যের উৎস হলো Claude Console-এর usage page; CLI-এর হিসাবটি আনুমানিক। /context একটি রঙিন grid দেখায় যেখানে context window-এ কী কী স্থান দখল করছে, system prompt, tools, MCP definitions, files এবং history দেখা যায়। এটি অতিরিক্ত বড় CLAUDE.md বা অতিরিক্ত বার্তা পাঠানো MCP server শনাক্ত করার দ্রুততম উপায়। সম্পূর্ণ প্রতি-item breakdown দেখতে 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 কেবল cache-এ না থাকা অবশিষ্ট অংশ। প্রকৃত prompt size হলো তিনটি input field-এর যোগফল। এক ঘণ্টা চলা কোনো agent-এ input_tokens: 4000 দেখা গেলেই সেটি সাশ্রয়ী নয়; বাকি 200,000 token cache থেকে সরবরাহ করা হয়ে থাকতে পারে। পাঠানোর আগে আনুমানিক হিসাব করতে token-counting endpoint ব্যবহার করুন। এটি ব্যবহার করার জন্য কোনো খরচ নেই, এর rate limit আলাদা, এবং আপনি যে model-এর নাম দেবেন সেটির tokenizer ব্যবহার করে গণনা করে। ফলাফলকে কাছাকাছি আনুমানিক হিসাব হিসেবে ধরুন; billing প্রকৃত request অনুযায়ী হয়:

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

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

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

এই গাইডের পদ্ধতি সব ক্ষেত্রেই একই; শুধু billing পদ্ধতি আলাদা। একটি API key ব্যবহার করলে Anthropic প্রকাশিত rate অনুযায়ী প্রতি token হিসেবে pay-as-you-go billing করে। উপরের প্রতিটি সংখ্যা প্রকৃত অর্থমূল্য। বেশির ভাগ মানুষ যতটা আশা করেন, তার আগেই এই meter চালু হয়। কারণ fallback হিসেবে কোনো free tier নেই। Signup-এর সময় শুধু একটি ছোট credit এবং কয়েকটি endpoint আছে যেগুলোর জন্য কোনো billing হয় না। কার্ডের তথ্য সংরক্ষণ করার আগে একটি নতুন API account-এ আসলে কী পাওয়া যায় তা এখানে দেখুন।

Claude subscription (Pro, Max, Team, Enterprise)-এ Claude Code-এর usage আপনার plan-এ অন্তর্ভুক্ত allowance থেকে গণনা হয়। July 2026 অনুযায়ী এতে একটি rolling five-hour session window এবং একটি weekly window থাকে। এগুলো বিভিন্ন model এবং claude.ai chat-এর মধ্যে shared। এখানে /usage dollar figure শুধু তথ্যের জন্য; এটি কোনো bill নয়। কোনো window-এর সীমা শেষ হলে reset time-সহ "আপনি আপনার session limit-এ পৌঁছে গেছেন" অথবা "আপনি আপনার weekly limit-এ পৌঁছে গেছেন" বার্তা দেখতে পাবেন। /model ব্যবহার করে model পরিবর্তন করলেও access ফিরে আসবে না, কারণ window-গুলো model-গুলোর মধ্যে shared।

আপনি যে client-এ কাজ করছেন, window-গুলো তার পরিবর্তে account অনুসরণ করে। তাই Linux-এ কোন কাজ nativeভাবে চলে এবং কোন plan প্রতিটি surface কভার করে তা জানা গুরুত্বপূর্ণ। আপনি আসলে কোন দুই window-এর মধ্যে কোনটির সীমা শেষ করেছেন, তার ওপর অপেক্ষার সময় এবং এর মধ্যে কী করা উপযোগী তা নির্ভর করে। তাই কাজের মাঝপথে limit-এ পৌঁছালে আপনার কী কী বিকল্প আছে তা জানা ভালো।

Plan-গুলোতে ঐচ্ছিকভাবে usage credit চালু করা যায়। /usage-credits ব্যবহার করে এগুলো পরিচালনা করা হয় এবং ceiling পার হওয়ার পর usage কেনা যায়। আমি ইচ্ছাকৃতভাবে plan quota দিচ্ছি না। এই পুরো বিষয়ের মধ্যে এগুলোই সবচেয়ে দ্রুত পরিবর্তিত হওয়া সংখ্যা। তাই claude.com/pricing এবং আপনার নিজের /usage bar পরীক্ষা করুন।

Subscription ব্যবহার করলেও token-এর পদ্ধতি গুরুত্বপূর্ণ। অপ্রয়োজনীয় session আপনার window ঠিক সেইভাবেই শেষ করে, যেভাবে এটি dollar খরচ করত। Subscription সম্পর্কে আপনার usage-এর জন্য কোন Claude plan উপযুক্ত তা দেখুন।

যে নিয়ন্ত্রণগুলো বাস্তবে কাজ করে

• Agent কী পড়বে, তার পরিসর নির্ধারণ করুন। "auth.py-এর validation bug ঠিক করুন" বললে একটি ফাইল পড়ে; "এই codebase উন্নত করুন" বললে চল্লিশটি ফাইল পড়ে। CLAUDE.md সংক্ষিপ্ত রাখুন, কারণ এটি প্রতিটি session-এ load হয়। তাই এতে শুধু প্রয়োজনীয় বিষয় রাখুন এবং workflow-নির্দিষ্ট নির্দেশনা প্রয়োজন অনুযায়ী load হওয়া skills-এ সরিয়ে নিন।
• স্পষ্ট ও সংক্ষিপ্ত রাখুন। সম্পর্কহীন কাজের মধ্যে /clear করুন; না হলে পুরোনো context পরবর্তী প্রতিটি message-এ আবার পাঠানো এবং পুনরায় bill করা হয়। একটি দীর্ঘ task-এর মধ্যে /compact Focus on the failing tests and the diff history সংক্ষেপ করে এবং quadratic curve-এর বাইরে রাখে।
• মডেলের আকার কাজ অনুযায়ী নির্বাচন করুন। বেশিরভাগ coding-এর কাজ Sonnet সামলাতে পারে। July 2026 অনুযায়ী introductory pricing-এ এর দাম প্রতি million tokens-এ $2/$10 ($3/$15 sticker price; Opus-এর দাম $5/$25)। Haiku-এর দাম $1/$5, তাই log triage-এর মতো mechanical subagent কাজের জন্য এটি উপযুক্ত। অন্যদিকে Fable 5-এর দাম $10/$50, অর্থাৎ meter-এর উভয় দিকেই Opus-এর দ্বিগুণ। তাই routine কাজের জন্য এটি selected রাখার আগে কোন কাজ সত্যিই এই rate ন্যায্যতা দেয় তা জেনে নিন। /model session-এর মাঝেও model পরিবর্তন করে।
• Verbose output আগে filter করুন। Claude output দেখার আগে কোনো hook test run-এর ফলাফল থেকে শুধু failure রেখে দিলে tool result 20,000 tokens থেকে 300 tokens-এ নেমে আসে। পরবর্তীতে সেই turn আবার পাঠালেও প্রতিবার একই সাশ্রয় হয়।
• যা interactive নয়, তা batch করুন। নিজের API pipeline, classification, bulk review এবং nightly job-এর জন্য Batches API asynchronous delivery-এর বিনিময়ে একই model 50% কম দামে চালায়।
• Cache clock বিবেচনায় রাখুন। একটানা কাজের সময়সীমায় কাজ করুন। VPS-এ tmux-এর মধ্যে detached Claude Code session idle অবস্থায় কোনো খরচ করে না; tokens কেবল turn চলার সময় খরচ হয়। তবে idle সময়ে warm cache বজায় থাকে না, তাই পরবর্তী turn-এ context আবার লিখতে হয়।

FAQ

Claude Code-এ একটি coding session কত token ব্যবহার করে?

এর কোনো নির্দিষ্ট সংখ্যা নেই। files এবং history জমা হলে session-এর মাঝামাঝি একটি turn-এ সাধারণত কয়েক দশ হাজার prompt token থাকে, আর একটি working session-এ মোট token সংখ্যা কয়েক million-এ পৌঁছাতে পারে। এর বেশিরভাগই cache থেকে পরিবেশিত হয়, base rate-এর প্রায় এক-দশমাংশ খরচে। তুলনার জন্য, Anthropic-এর প্রকাশিত enterprise পরিসংখ্যান অনুযায়ী July 2026-এ প্রতি active day-তে প্রতি developer-এর গড় খরচ প্রায় $13, এবং 90% user-এর খরচ $30-এর নিচে। নিজের session-এ /usage চালান। পাঁচ মিনিট এটি monitor করলে যেকোনো প্রকাশিত average-এর চেয়ে বেশি নির্ভরযোগ্য ধারণা পাবেন।

আমি দেখতে না পেলেও কি thinking token-এর জন্য খরচ হয়?

হ্যাঁ। Thinking token output token হিসেবে, অর্থাৎ বেশি ব্যয়ের rate-এ, বিল হয় এবং max_tokens-এর সীমার মধ্যে গণনা করা হয়। বর্তমান model-গুলো interface-এ reasoning summary না দেখালেও এই token-এর জন্য বিল করে। দৃশ্যমান answer শেষ হওয়ার আগে কোনো response stop_reason: "max_tokens" দিয়ে truncate হলে, সম্ভবত thinking token-ই budget শেষ করেছে। Claude Code-এ গভীর reasoning প্রয়োজন নেই এমন task-এর জন্য /effort ব্যবহার করে effort level কমান।

দীর্ঘ Claude Code session-এ প্রতি message-এর খরচ কেন বাড়ে?

কারণ API stateless। প্রতিটি turn-এ সম্পূর্ণ conversation, প্রতিটি file read, tool result এবং আগের exchange আবার input হিসেবে পাঠানো হয় এবং সেগুলোর জন্য বিল হয়। তাই turn 50-এ turns 1 থেকে 49 পর্যন্ত সবকিছু বহন করতে হয়। Prompt caching পুনরাবৃত্ত prefix-কে base input price-এর প্রায় এক-দশমাংশে পরিবেশন করে। কিন্তু prefix নিজেই ক্রমশ বড় হয়। Cache TTL-এর চেয়ে বেশি সময় idle থাকলে পরের turn-এ prefix আবার full-price-এ পাঠাতে হয়। /compact history ছোট করে। /clear history reset করে।

আমার Claude token usage এবং cost কীভাবে পরীক্ষা করব?

Claude Code-এ /usage চালালে session-এর token statistics, local cost estimate এবং subscription-এর plan-limit bar দেখা যায়। (/cost এর একটি alias।) /context দেখায় window-তে কোন বিষয়গুলো জায়গা নিচ্ছে। নির্ভরযোগ্য API billing-এর জন্য Claude Console-এর usage page ব্যবহার করুন। নিজের code-এ response.usage পড়ুন। input_tokens, cache_creation_input_tokens এবং cache_read_input_tokens যোগ করলে প্রকৃত prompt size পাওয়া যায়। আগে থেকে estimate করার জন্য count_tokens endpoint ব্যবহার করুন, কখনো tiktoken নয়।