Claude Pro-তে কত token অন্তর্ভুক্ত থাকে?

Claude Pro-তে কত token অন্তর্ভুক্ত থাকে?

Claude Pro-তে নির্দিষ্ট token allowance থাকে না, এবং September 2026 পর্যন্ত Anthropic কোনো token allowance প্রকাশ করেনি। Claude subscription-এ token balance থেকে token খরচ করার পরিবর্তে rolling time window-এর মধ্যে message অনুযায়ী ব্যবহার গণনা করা হয়। আপনি কোন model বেছে নিয়েছেন, আপনার conversation কত দীর্ঘ হয়েছে এবং প্রতিটি turn-এ কতটা text রয়েছে—তার ওপর ওই window-তে আপনি কতদূর ব্যবহার করতে পারবেন তা নির্ভর করে।

এই প্রশ্নের যে উত্তরটি সাধারণত পাওয়া যায় না, তার কারণ মানুষ plan-কে API key-এর মতো কাজ করবে বলে ধরে নেয়। API key-তে token হিসেবে গণনা করা balance খরচ হয়, তাই আপনি নিজেই মোট invoice হিসাব করতে পারেন। Plan এমন একটি usage cap-এ access দেয়, যা Anthropic নির্ধারণ ও পরিবর্তন করে। সেই cap message হিসেবে নির্ধারিত হয়। তাই উদ্ধৃত করার মতো কোনো নির্দিষ্ট token সংখ্যা নেই। কেউ যদি আপনাকে এমন একটি সংখ্যা দেয়, তবে সে সেটি বানিয়ে বলেছে।

তাই অন্য প্রশ্ন করুন। আমার message-গুলোর খরচ বেশি হওয়ার কারণ কী? এই প্রশ্নের বাস্তব উত্তর আছে, এবং আপনি আজই সেই অনুযায়ী পদক্ষেপ নিতে পারেন।

কেন একটি subscription token সংখ্যার নির্দিষ্ট হিসাব দিতে পারে না

API প্রতিটি request-এর জন্য token অনুযায়ী বিল করে। আপনি যা পাঠান তার সবকিছু input token-এর মধ্যে পড়ে, আর model যা লিখে ফেরত দেয় তা output token-এর মধ্যে পড়ে। এই দুই ধরনের token-এর rate আলাদা। তাই আগে আনুমানিক হিসাব করার সময় input ও output token-এর খরচ আলাদা।

Consumer plan-গুলোতে খরচ করার মতো কোনো balance থাকে না। Anthropic একটি rolling window-এর মধ্যে আপনি কতগুলো message পাঠাতে পারবেন, তার সীমা নির্ধারণ করে। আপনার প্রথম message-এর সঙ্গে এই window শুরু হয় এবং নির্দিষ্ট সংখ্যক ঘণ্টা পরে শেষ হয়। Paid plan-এ এর পাশাপাশি একটি দ্বিতীয়, দীর্ঘতর cap থাকে, যা এক সপ্তাহজুড়ে হিসাব করা হয়। একটি message-এর আকার নির্দিষ্ট নয়। তাই একই message count দুইজন ভিন্ন ব্যক্তির জন্য সম্পূর্ণ ভিন্ন পরিমাণ কাজ বোঝাতে পারে। Anthropic-এর help page-গুলো একটি সংক্ষিপ্ত conversation-এর জন্য আনুমানিক message সংখ্যা হিসেবে cap বর্ণনা করে। এরপর সতর্ক করে যে দীর্ঘ conversation এবং বড় attachment allowance দ্রুত ব্যবহার করে ফেলে। এই সতর্কতাই পুরো বিষয়টি সংক্ষেপে বলে, কিন্তু এর পেছনের mechanism প্রায় কখনো ব্যাখ্যা করা হয় না।

20তম turn-এর খরচ 1ম turn-এর তুলনায় অনেক বেশি কেন

Model কোনো request-এর মধ্যে memory ধরে রাখে না। এটি stateless, তাই প্রতিটি turn-এ পুরো conversation আবার পাঠানো হয়: system prompt, আপনি আগে লেখা প্রতিটি message, Claude-এর আগের প্রতিটি reply এবং আপনি attach করা প্রতিটি file। আপনার নতুন question হয়তো 20টি শব্দের। কিন্তু সেটি বহনকারী request-এ থাকে পুরো transcript।

তাই chat যত দীর্ঘ হয়, একটি turn-এর খরচও তত বাড়ে, এবং এই বৃদ্ধি সরলরৈখিক। নিচের সারিগুলো একটি নির্দিষ্ট round assumption অনুযায়ী এই হিসাব দেখায়: প্রায় 1,000 token-এর system prompt, প্রতিটি প্রায় 1,000 token-এর আপনার message এবং প্রতিটি প্রায় 1,200 token-এর reply। এগুলো প্রক্রিয়াটি বোঝায়। এগুলো আপনার account-এর পরিমাপ নয়।

[
  {
    "label": "Turn 1",
    "sent_this_turn": "2,000",
    "cumulative_input": "2,000"
  },
  {
    "label": "Turn 5",
    "sent_this_turn": "10,800",
    "cumulative_input": "32,000"
  },
  {
    "label": "Turn 10",
    "sent_this_turn": "21,800",
    "cumulative_input": "119,000"
  },
  {
    "label": "Turn 20",
    "sent_this_turn": "43,800",
    "cumulative_input": "458,000"
  }
]

প্রথম turn-এ 2,000 input token পাঠানো হয়। 20তম turn-এ একই ছোট question-এর জন্য পাঠানো হয় 43,800, অর্থাৎ আপনার একই পরিমাণ typing-এর জন্য 20 গুণেরও বেশি। পুরো conversation জুড়ে আপনি 458,000 input token পাঠিয়েছেন, যার বেশিরভাগ একই text বারবার পাঠানো হয়েছে।

20টি আলাদা one-turn chat হলে উপরের প্রথম সারির 20 গুণ token পাঠানো হতো, এর বেশি নয়। একই question, কিন্তু load-এর একটি অংশ। Attachment এই ব্যবধান আরও বাড়ায়, কারণ আপনি turn দুই-এ attach করা PDF turn তিন, turn চার এবং তার পরের প্রতিটি turn-এ আবার পাঠানো হয়, conversation-এ সেটি এখনও প্রাসঙ্গিক কি না তা বিবেচনা না করেই।

এই কারণে একই plan ব্যবহার করেও দুজনের mileage সম্পূর্ণ আলাদা হতে পারে। একজন পুরো সপ্তাহ একটি thread খোলা রাখেন এবং Wednesday-তেই cap-এ পৌঁছে যান। অন্যজন প্রতিটি task-এর জন্য নতুন chat খোলেন এবং খুব কমই limit দেখেন। কেউ ভুল করছেন না। তাঁদের token spend-এর মধ্যে এক order of magnitude পার্থক্য হয়, কারণ তাঁদের ব্যবহারের ধরন আলাদা।

API-তে prompt caching ব্যবহার করে পুনরাবৃত্তির খরচ কিছুটা কমানো যায়। এটি request-এর অপরিবর্তিত শুরুর অংশ সংরক্ষণ করে, যাতে পরের call-গুলোতে ওই অংশের input rate কম ধরা হয়। Subscription-এ caching আপনি নিয়ন্ত্রণ করতে পারেন না। তাই conversation-এর দৈর্ঘ্যই আপনার হাতে থাকা কার্যকর নিয়ন্ত্রণ। একই প্রক্রিয়া coding session-এ আরও বেশি প্রভাব ফেলে, কারণ file content এবং tool definition প্রতিটি turn-এর সঙ্গে পাঠানো হয়। তাই coding session-এর context ছোট রাখা যেকোনো setting-এর চেয়ে আপনার limit-এর ওপর বেশি প্রভাব ফেলে। Plan-কে দোষ দেওয়ার আগে Claude Code session-এর token আসলে কোথায় খরচ হয় পড়ে নেওয়া উপকারী।

প্রতিটি plan tier তুলনামূলকভাবে কী সুবিধা দেয়

কোনো tier নির্দিষ্ট absolute allowance প্রকাশ করে না। যা প্রকাশ করা হয়, তা আপেক্ষিক তথ্য; এবং সিদ্ধান্ত নেওয়ার জন্য এই তুলনামূলক চিত্রই যথেষ্ট। Free সবচেয়ে নিচে থাকে, আর service-এ demand বেশি হলে free capacity কমে যেতে পারে। Pro তার উপরে থাকে। Max দুটি আকারে বিক্রি হয়; এগুলোকে Pro usage-এর গুণিতক হিসেবে বর্ণনা করা হয়—প্রায় পাঁচ গুণ এবং প্রায় বিশ গুণ। Team এবং Enterprise প্রতি seat অনুযায়ী মূল্য নির্ধারণ করে এবং তাদের নিজস্ব cap থাকে।

এই multiplier-গুলোকে contract-এর নিশ্চয়তা হিসেবে নয়, বরং intended usage-এর নির্দেশনা হিসেবে বিবেচনা করুন। Anthropic cap সমন্বয় করে, এবং এই সমন্বয় আগে থেকে জানানো হয় না। তাই কোনো নির্ভরযোগ্য page-ই আপনাকে নির্দিষ্ট token সংখ্যা দিতে পারে না। একই তুলনার খরচের দিকের জন্য Pro-এর খরচ এবং কোথায় cap প্রযোজ্য এবং দুটি Max tier-এর পার্থক্য দেখুন। সর্বনিম্ন সীমা বোঝার জন্য Free plan-এ আসলে কী সুবিধা পাওয়া যায় দেখুন।

Model নির্বাচন tier-এর ওপর আরেকটি multiplier হিসেবে কাজ করে। একই প্রশ্ন ছোট model-এর তুলনায় বড় model-এ আপনার window-এর বেশি অংশ ব্যবহার করে, কারণ ভারী model প্রতি token চালাতে বেশি খরচ হয়। নিয়মিত কাজ Opus থেকে Sonnet বা Haiku-তে নামিয়ে আনলে অনেক সময় upgrade করার চেয়ে বেশি working time পাওয়া যায়। তাই বারবার usage limit-এ পৌঁছে গেলে প্রথমে কাজ অনুযায়ী model নির্বাচন করার চেষ্টা করুন।

নিজের ব্যবহার অনুমান না করে কীভাবে দেখবেন

আপনার নিজের account-ই একমাত্র নির্ভরযোগ্য উৎস, এবং এটি দেখতে মাত্র দুইবার ক্লিক করতে হয়। claude.ai-তে Settings খুলুন, তারপর Usage নির্বাচন করুন। এখানে বর্তমান window-তে আপনি কতটা ব্যবহার করেছেন এবং window কখন reset হবে তা দেখা যায়। উত্তর প্রত্যাখ্যান করা শুরু হলে একবার এবং দীর্ঘ session-এর পরে আরেকবার পরীক্ষা করুন। এতে প্রকাশিত যেকোনো সংখ্যার চেয়ে দ্রুত আপনার নিজস্ব ব্যবহারের ধরন বুঝতে পারবেন।

Claude Code-এ terminal থেকে একই কাজের জন্য দুটি slash command রয়েছে। /usage plan usage এবং reset-এর সময় জানায়। /context বর্তমানে context window কোন কোন উপাদানে পূর্ণ হচ্ছে তা আলাদা করে দেখায়। এতে system prompt, tool definitions, files এবং conversation history পৃথকভাবে দেখা যায়। /context-এ যদি দেখা যায় যে পুরোনো conversation-ই বেশি জায়গা দখল করছে, তাহলে /clear একটি নতুন session শুরু করে। এতে প্রতি turn-এর খরচ উপরের chart-এর প্রথম row-এর কাছাকাছি কমে আসে।

API-তে count নির্ভুলভাবে পাওয়া যায়। কিছু পাঠানোর আগেই এটি জানতে পারবেন:

curl https://api.anthropic.com/v1/messages/count_tokens \
  --header "x-api-key: $ANTHROPIC_API_KEY" \
  --header "anthropic-version: 2023-06-01" \
  --header "content-type: application/json" \
  --data '{
    "model": "claude-sonnet-5",
    "messages": [{"role": "user", "content": "Summarise the attached report."}]
  }'

সঠিক response-এ একটি মাত্র field থাকে। billing-এ এই সংখ্যাটিই ব্যবহার করা হবে:

{"input_tokens": 14}

প্রতিটি সম্পূর্ণ হওয়া request শেষ হলে একই accounting জানায়:

{"usage": {"input_tokens": 21430, "output_tokens": 512}}

একটি নতুন request হিসেবে একটি সংক্ষিপ্ত question পাঠান। এরপর একটি দীর্ঘ thread-এর শেষে একই question পাঠান। তারপর দুটি input_tokens value তুলনা করুন। পার্থক্যটিই আপনার subscription যে ব্যবহার মাপছে তার সঠিক প্রভাব, যা একটি সংখ্যায় প্রকাশিত হয়েছে।

কাজের মাঝখানে সীমা কার্যকর হলে কী করবেন

1. সময়সীমা শেষ হওয়া পর্যন্ত অপেক্ষা করুন। অ্যাপ reset-এর সময় দেখায়, এবং workaround ব্যবহার করার চেয়ে অপেক্ষার সময় প্রায়ই কম হয়। কোনো কাজ জরুরি না থাকলে এটিই সঠিক পদক্ষেপ।
2. হালকা model-এ যান। প্রতিটি plan-এ ছোট model প্রতি turn-এ কম খরচ হয়। কিছু plan-এ এটি আলাদা allowance থেকে ব্যবহার হয়। তাই ভারী model-এর allowance পুনরায় চালু হওয়ার অপেক্ষার সময়ও কাজ চালিয়ে যেতে পারবেন।
3. পরবর্তী ধাপের জন্য প্রয়োজনীয় তথ্য নিয়ে একটি নতুন chat শুরু করুন। পুরো transcript নয়, conclusion paste করুন। এতে প্রতি turn-এর খরচ সঙ্গে সঙ্গে কমে। উত্তরও সাধারণত উন্নত হয়, কারণ model-কে আর হাজার হাজার token-এর নিষ্পত্তি হওয়া আলোচনা বিবেচনা করতে হয় না।
4. কাজটি API-তে স্থানান্তর করুন। সেখানে প্রতিটি request অনুযায়ী token গণনা হয় এবং প্রতিটি token-এর জন্য billing হয়। অপেক্ষা করে window শেষ হওয়ার প্রয়োজন নেই। প্রতিটি call করার আগে ও পরে এর মূল্য দেখতে পারবেন।

কোন option উপযুক্ত হবে, তা নির্ভর করে আপনার সমস্যা clock নাকি workload। একবারের চাপ timing problem। প্রতি Wednesday যে সীমায় পৌঁছান, সেটি workload problem। এর সমাধান better timing নয়; API বা বড় plan ব্যবহার করা। কাজের মাঝখানে কার্যকর হওয়া সীমার সম্পূর্ণ checklist recovery প্রক্রিয়াটি ধাপে ধাপে দেখায়। rolling window কীভাবে খোলে এবং reset হয় clock-এর আচরণের কারণ ব্যাখ্যা করে। আপনি যদি API ব্যবহার করতে যাচ্ছেন, আগে মূল্য হিসাব করুন: একই workload-এর জন্য subscription-এর সঙ্গে API-এর তুলনা এবং এক million token-এর প্রকৃত খরচ স্থানান্তরের আগে প্রয়োজনীয় হিসাব দেখায়।

FAQ

Claude Pro-তে কত token অন্তর্ভুক্ত থাকে?

Anthropic Pro-এর জন্য কোনো token allowance প্রকাশ করে না, এবং September 2026 পর্যন্ত উদ্ধৃত করার মতো এমন কোনো নির্দিষ্ট সংখ্যা নেই। Pro-তে rolling window-এর মধ্যে message অনুযায়ী ব্যবহার মাপা হয়। এছাড়া এক সপ্তাহজুড়ে দীর্ঘতর cap-ও প্রযোজ্য হয়। কোন model ব্যবহার করছেন এবং আপনার conversation কত দীর্ঘ, তার ওপর নির্ভর করে ওই সীমার মধ্যে message-এর সংখ্যা পরিবর্তিত হয়। Pro-এর জন্য নির্দিষ্ট মাসিক token সংখ্যা উল্লেখ করা যেকোনো page অনুমানভিত্তিক। নিজের ব্যবহার এবং reset time দেখতে claude.ai-তে Settings খুলে Usage নির্বাচন করুন।

নতুন chat শুরু করলে কি আমার usage reset হয়?

না। আপনার account-এর জন্য পুরো window জুড়ে usage গণনা করা হয়। তাই নতুন chat শুরু করলেও ইতিমধ্যে ব্যবহার করা usage ফেরত আসে না। তবে এরপরের প্রতিটি turn-এর খরচ পরিবর্তিত হয়। নতুন chat-এ আগের transcript পুনরায় পাঠাতে হয় না। তাই এটি উপরের chart-এর নিম্ন প্রান্ত থেকে শুরু হয়, আগের chat-এর মতো ক্রমশ বাড়তে থাকে না। বিষয় পরিবর্তিত হলে নতুন chat খোলা যেকোনো plan-এ সবচেয়ে কম খরচের অভ্যাস।

গতকালের তুলনায় আজ কেন দ্রুত limit-এ পৌঁছালাম?

সাধারণত কারণ, আজকের কাজ একটি দীর্ঘ thread-এর মধ্যে হয়েছে। প্রতিটি turn-এ পুরো conversation এবং সংযুক্ত file-গুলো আবার পাঠানো হয়। ফলে আপনার কাছে message count অপরিবর্তিত মনে হলেও প্রতি message-এর খরচ ধীরে ধীরে বাড়তে থাকে। অন্য সাধারণ কারণটি হলো model। বেশি সক্ষম model প্রতি turn-এ allowance দ্রুত কমিয়ে দেয়। তাই সবচেয়ে বড় model-এ একটি afternoon, ছোট model-এ একটি morning-এর তুলনায় আগে শেষ হয়ে যায়।

প্রকৃত token গণনা পেতে কি API-তে যাওয়া উচিত?

সংখ্যা বা পূর্বানুমানযোগ্যতা প্রয়োজন হলে API ব্যবহার করুন। API প্রতিটি call-এ input এবং output token গণনা করে। পাঠানোর আগে চালানো যায় এমন একটি token counting endpoint-ও এটি দেয়। এছাড়া অপেক্ষা করে window শেষ হওয়ার প্রয়োজন নেই। API token অনুযায়ী billing করে। তাই বেশি ব্যবহারে flat subscription-এর তুলনায় খরচ বেশি হয়, আর কম ব্যবহারে অনেক কম হয়। পরিবর্তন করার আগে আপনার প্রকৃত workload-এর খরচ বর্তমান plan-এর সঙ্গে তুলনা করুন। আপনি কত token পাঠান, তার ওপর ফলাফল নির্ভর করে।