Claude-এ 1M token-এর দাম কত?

Claude-এ 1M token-এর দাম কত?

1M token মানে এক মিলিয়ন token। Claude API (application programming interface)-এর সব মূল্য এই এককেই প্রকাশ করা হয়। এর কোনো একক মূল্য নেই, কারণ input ও output-এর জন্য আলাদা হারে বিল করা হয় এবং প্রতিটি model-এর জন্য আলাদা rate pair প্রযোজ্য। August 2026 অনুযায়ী, Claude Haiku 4.5-এ এক মিলিয়ন input token-এর দাম $1, Claude Sonnet 5-এ $2, এবং Claude Opus 5-এ $5।

Output হলো বেশি ব্যয়বহুল অংশ। বর্তমানে প্রতিটি model-এ output rate, input rate-এর পাঁচ গুণ। তাই আপনার bill নির্ধারণে headline figure-এর চেয়ে input ও output-এর অনুপাত বেশি গুরুত্বপূর্ণ। কোনো app দীর্ঘ document পাঠিয়ে সংক্ষিপ্ত উত্তর ফেরত দিলে তার খরচের ধরন এমন app-এর থেকে সম্পূর্ণ ভিন্ন হবে, যা সংক্ষিপ্ত prompt থেকে দীর্ঘ উত্তর তৈরি করে।

এই পৃষ্ঠায় unit economics ব্যাখ্যা করা হয়েছে: একটি token-এর খরচ কত এবং build শুরু করার আগে bill কীভাবে আনুমানিক হিসাব করবেন। কাজের সময় tokenগুলো আসলে কোথায় ব্যবহৃত হয়, তা জানতে Claude Code session-এর ভেতরে tokenগুলো কোথায় ব্যবহৃত হয় পড়ুন।

1M token দেখতে কেমন

Token হলো এমন একটি text অংশ, যা model পড়ে বা লেখে। Anthropic-এর আনুমানিক নির্দেশনা অনুযায়ী, প্রতি 4টি character-এ প্রায় 1টি token থাকে, অথবা English ভাষায় প্রায় 0.75টি word থাকে। তাই 1M token-এ প্রায় 750,000টি word, অথবা আনুমানিক 4 MB plain text থাকে।

সাধারণ input-এর প্রকাশিত হিসাব এই পরিমাণটি আরও ভালোভাবে বোঝায়।

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

এই হারে 1M token প্রায় 400টি গড় web page একবার পড়ার সমান, অথবা একই আকারের 8টি research paper-এর সমান। এটি মাঝারি আকারের একটি codebase একবার পড়ার সমান, অথবা একজন ব্যক্তির এক মাসের হালকা chat ব্যবহারের সমান।

এগুলোকে আনুমানিক হিসাব হিসেবে বিবেচনা করুন। Code, JSON এবং English ছাড়া অন্য ভাষার text-এ একটি token-এর মধ্যে কম word থাকে। তাই 0.75 অনুপাতটি আশাবাদী প্রান্তের হিসাব। আরও একটি বিষয় token-এর সংখ্যা পরিবর্তন করে: Claude Opus 4.7 এবং পরবর্তী version, যার মধ্যে Opus 5 এবং Sonnet 5 রয়েছে, নতুন tokenizer ব্যবহার করে। একই text-এর জন্য এই tokenizer Sonnet 4.6 এবং আগের version-এর তুলনায় প্রায় 30 percent বেশি token তৈরি করে। Claude Haiku 4.5 পুরোনো tokenizer ব্যবহার করে। তাই Haiku 4.5-এ মাপা কোনো count একই input-এর ক্ষেত্রে Sonnet 5-এর count-কে কম দেখায়। এর অর্থ, এই সীমার দুই পাশে সরাসরি প্রতি-million price তুলনা করা ন্যায্য নয়। সিদ্ধান্ত নেওয়ার আগে একই prompt উভয় model-এর বিরুদ্ধে count করুন।

প্রতি মিলিয়ন token-এ Claude-এর মূল্য

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug 2026)",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 5 (from 1 Sep 2026)",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5-এর প্রারম্ভিক মূল্য 31 August 2026 পর্যন্ত প্রতি মিলিয়ন input token-এ $2 এবং প্রতি মিলিয়ন output token-এ $10। 1 September 2026 থেকে standard rate প্রযোজ্য হবে: প্রতি মিলিয়ন input token-এ $3 এবং প্রতি মিলিয়ন output token-এ $15। Claude Opus 5-এর মূল্য যথাক্রমে $5 এবং $25। এর চেয়েও বেশি দামের একটি model আছে: Claude Fable 5-এর মূল্য input-এর জন্য $10 এবং output-এর জন্য $50। তাই এই rate-এর জন্য মূল্য দেওয়া সঙ্গত কি না তা নির্ভর করে আপনি আসলে কোন কাজের জন্য model-টি ব্যবহার করছেন তার ওপর।

Rate পরিবর্তিত হতে পারে। এই পৃষ্ঠার প্রতিটি সংখ্যাকে August 2026-এর তারিখযুক্ত একটি উদাহরণ হিসেবে বিবেচনা করুন। বাজেট অনুমোদনের আগে official pricing page-এ বর্তমান সংখ্যা নিশ্চিত করুন।

Context length rate পরিবর্তন করে না। Claude 4.6 এবং পরবর্তী version-এ সম্পূর্ণ 1M token context window-এর জন্য standard pricing প্রযোজ্য। তাই 900,000 token-এর একটি request-এর প্রতি token-এর খরচ 9,000 token-এর request-এর সমান। দীর্ঘ prompt-এর খরচ বেশি হয়, কারণ এতে বেশি token থাকে। এর জন্য আলাদা long-context rate প্রযোজ্য নয়।

মূল্য পরিবর্তনের পরও কার্যকর থাকে যে হিসাব

প্রতিটি বিলের ক্ষেত্রে দুটি গুণ এবং একটি যোগ করতে হয়।

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

চালানো যায় এমন কোডে এটি হবে:

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

এটি 0.0126 প্রিন্ট করে। 4,300টি input token পাঠিয়ে 400টি output token ফেরত পাওয়া একটি অনুরোধের খরচ Sonnet 5-এ প্রায় 1.3 সেন্ট। আপনার কোডে দুটি rate একই জায়গায় রাখুন। মূল্যে পরিবর্তন হলে দুটি লাইন সম্পাদনা করলেই আপনার সিস্টেমের প্রতিটি estimate সেই অনুযায়ী আপডেট হবে।

বাস্তব একটি অ্যাপের আনুমানিক হিসাব

একটি support assistant বিবেচনা করুন। এর system prompt এবং product documentation মিলিয়ে 4,000 tokens হয়। এগুলো প্রতিটি request-এর সঙ্গে পাঠানো হয়, কারণ Messages API stateless এবং model কলগুলোর মধ্যে কিছু মনে রাখে না। ব্যবহারকারীর প্রশ্নে প্রায় 300 tokens যোগ হয়। একটি উত্তর প্রায় 400 tokens হয়। তাই প্রতিটি request-এ 4,300 input এবং 400 output থাকে।

এক মিলিয়ন input tokens দিয়ে এই ধরনের প্রায় 232টি request করা যায়। প্রতিদিন 1,000টি request হলে অ্যাপটি দৈনিক 4.3 million input tokens ব্যবহার করে। তাই "1M tokens" ছয় ঘণ্টারও কম সময়ের traffic-এর সমান।

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

Claude Opus 5-এ এই traffic-এর 1,000টি request-এর খরচ $31.50। Sonnet 5-এ খরচ $12.60। Claude Haiku 4.5-এ নামলে খরচ $6.30 হয়। Sonnet 5-এ warm prompt cache ব্যবহার করলে খরচ আরও কমে $5.40 হয়।

এক মাসের এই traffic-এর খরচ বের করতে 30 দিয়ে গুণ করুন। list rate অনুযায়ী Sonnet 5-এর খরচ মাসে প্রায় $378। একই অ্যাপে warm cache ব্যবহার করলে খরচ প্রায় $162। এই volume-এ আপনি যে কোনো rate negotiation-এ যত সাশ্রয় করতে পারবেন, তার চেয়ে model নির্বাচন এবং caching সিদ্ধান্ত—দুটির প্রতিটির প্রভাব বেশি। কোন model চালাবেন, সেটি আলাদা প্রশ্ন। আপনার evaluation-এ উত্তীর্ণ হওয়া সবচেয়ে সস্তা model-ই বেছে নিন: Opus, Sonnet এবং Haiku-এর মধ্যে নির্বাচন-এ এটি সঠিকভাবে পরীক্ষা করার পদ্ধতি দেওয়া আছে।

Prompt caching পুনরাবৃত্ত অংশের খরচ কমায়

প্রতিটি অনুরোধে 4,000 token-এর এই prefix একই থাকে, কিন্তু প্রতিবার এর জন্য পুরো input rate দিতে হয়। Prompt caching প্রক্রিয়াকৃত prefix সংরক্ষণ করে এবং সেটি পুনরায় ব্যবহার করলে কম rate নেয়।

একটি cache read-এর খরচ base input rate-এর 0.1 গুণ। 5 minute lifetime-এর জন্য cache write-এর খরচ base rate-এর 1.25 গুণ, আর 1 hour lifetime-এর জন্য 2 গুণ। তাই 5 minute cache একবার read হলেই নিজের খরচ তুলে ফেলে, কারণ write-এর অতিরিক্ত খরচ 0.25, আর প্রতিটি read-এ সাশ্রয় হয় 0.9। 1 hour cache-এর ক্ষেত্রে break-even হতে দুইটি read দরকার।

এটি চালু করার সবচেয়ে সহজ উপায় হলো একটি একক top-level field যোগ করা:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

এরপর ফিরে আসা usage block পরীক্ষা করুন:

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

এই তিনটি input counter-এর জন্য তিনটি ভিন্ন rate প্রযোজ্য, এবং এগুলোর যোগফলই আপনার প্রকৃত input volume: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens। শুধু input_tokens দেখে cost estimate করলে caching চালু হওয়ার পর হিসাব অনেক ভুল হবে।

দুটি কারণে cache নিজের খরচ তুলে নিতে পারে না, এবং উভয় ক্ষেত্রেই কোনো error দেখা যায় না।

Prefix-এর প্রতিটি byte একই হতে হবে। Cache lookup prefix match ব্যবহার করে। তাই system prompt-এর শুরুতে timestamp বা user's name থাকলে প্রতিটি অনুরোধে prefix বদলে যায়। তখন প্রতিবার base input-এর 1.25 গুণ খরচ হয় এবং কোনো read হয় না। এর লক্ষণ হলো cache_creation_input_tokens-এর মান বেশি থাকা, আর cache_read_input_tokens-এর মান 0 থাকা। অনুরোধগুলোর মধ্যে একই থাকা শেষ block-এ cache_control রাখুন, এবং পরিবর্তনশীল সবকিছু তার পরে রাখুন। আপনার tools definition পরিবর্তন করলে সেগুলোর নিচের পুরো cache invalid হয়ে যায়, কারণ invalidation-এর ক্রম হলো tools, তারপর system, তারপর messages।

Prefix যথেষ্ট দীর্ঘ হতে হবে। Cache করার ন্যূনতম দৈর্ঘ্য Opus 5-এ 512 token, Sonnet 5-এ 1,024 এবং Haiku 4.5-এ 4,096। Prompt এর চেয়ে ছোট হলে cache করা হয় না এবং কোনো error ফেরত আসে না। উপরের উদাহরণের 4,000 token prefix Sonnet 5-এ cache হয়, কিন্তু Haiku 4.5-এ cache হয় না, কারণ 4,000 ওই model-এর ন্যূনতম সীমার নিচে। উভয় counter-এর মান 0 হলে কিছুই cache করা হয়নি।

ব্যাচ প্রসেসিং হার অর্ধেক করে

Batch API অনুরোধগুলো asynchronous পদ্ধতিতে প্রক্রিয়া করে এবং input ও output—উভয় ক্ষেত্রেই 50 percent ছাড় দেয়। উপরের উদাহরণে এর ফলে প্রতি 1,000 অনুরোধের খরচ $12.60 থেকে $6.30 হয়। এই ছাড় prompt caching-এর সঙ্গে একত্রে প্রযোজ্য হয়। তাই bulk কাজ চালানোর সবচেয়ে কম খরচের উপায় হলো cached batch job।

এর বিনিময়ে latency বাড়ে। তাই কোনো ব্যক্তি ফলাফলের জন্য অপেক্ষা করলে batch ব্যবহার করা উপযুক্ত নয়। এটি রাতভর classification এবং document backfill-এর মতো কাজে উপযোগী।

একটি কথোপকথনের মধ্যে চ্যাটের খরচ কেন বাড়ে

API কোনো state সংরক্ষণ করে না। তাই প্রতিটি turn-এ আপনার client পুরো কথোপকথন আবার পাঠায়। ফলে একটি chat-এর মধ্যে token usage সরলরেখায় নয়, কথোপকথনের দৈর্ঘ্যের বর্গের হারে বাড়ে।

ধরা যাক, প্রতিটি turn-এ গড়ে 500 token থাকে। Turn 1-এ 500 input token পাঠানো হয়। Turn 2-এ 1,000। Turn 20-এ 10,000। n(n+1)/2 সূত্রে যোগ করলে দেখা যায়, 20 turn-এর একটি কথোপকথনে মোট প্রায় 105,000 input token পাঠানো হয়েছে, যদিও transcript-এর দৈর্ঘ্য মাত্র 10,000 token।

তাই একটি chat feature-এর খরচ transcript দেখে যতটা মনে হয়, তার চেয়ে বেশি হয়। দীর্ঘ thread-এ স্থিতিশীল prefix cache করা বা পুরোনো turn-গুলোর সারসংক্ষেপ তৈরি করা সাশ্রয়ী হয়। যে agent বারবার tool call চালায়, তার ক্ষেত্রেও একই ধরনের বৃদ্ধি ঘটে, বরং আরও বেশি: প্রতিটি tool result history-তে থেকে যায় এবং পরবর্তী প্রতিটি turn-এ আবার পাঠানো হয়। নিজে চালানো agent-এর খরচের একটি কঠোর সীমা নির্ধারণ করা এখানে সবচেয়ে গুরুত্বপূর্ণ, কারণ এই বৃদ্ধি স্বয়ংক্রিয়ভাবে ঘটে এবং এটি পর্যবেক্ষণ করার কেউ নাও থাকতে পারে।

অনুমান করার আগে token গণনা করুন

শব্দের সংখ্যা থেকে token-এর সংখ্যা অনুমান করা বন্ধ করুন। API নিজেই এগুলো গণনা করে এবং এর জন্য কোনো অতিরিক্ত খরচ নেই। এই গণনা message তৈরির rate limit থেকে পৃথক rate limit-এর অধীনে হয়।

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{
      "role": "user",
      "content": "Hello, Claude"
    }]
  }'

Response-এ একটি field থাকে:

{ "input_tokens": 14 }

এখানে আপনার প্রকৃত system prompt ও tool definition-এর সঙ্গে একটি প্রতিনিধিত্বমূলক user message দিন। তারপর সেই সংখ্যা উপরের cost function-এ ব্যবহার করুন। এই endpoint একটি message request-এর মতো একই body গ্রহণ করে। তাই image ও PDF-ও সঠিকভাবে গণনা হয়।

দুটি বিষয় মনে রাখা জরুরি। এই গণনা একটি estimate এবং billed figure-এর সঙ্গে সামান্য পার্থক্য হতে পারে। এছাড়া, এটি আপনার দেওয়া model-এর tokenizer ব্যবহার করে মাপা হয়। তাই যে model প্রকৃতপক্ষে চালাবেন, সেটিই দিন।

Output token আগে থেকে গণনা করা যায় না, কারণ সেগুলো তখনও তৈরি হয়নি। max_tokens ব্যবহার করে সেগুলোর সর্বোচ্চ সীমা নির্ধারণ করুন। এরপর live traffic-এ usage.output_tokens থেকে প্রকৃত distribution মাপুন।

বিলে আর কী কী যোগ হয়

বিলের বেশির ভাগই token-এর জন্য। কয়েকটি খরচ token নয়, এবং এগুলো অনেককে অবাক করে।

• প্রতিটি request-এ tool definition input token হিসেবে গণনা হয়। আপনার নিজস্ব schema যোগ করার আগেই tool ব্যবহারের system prompt Opus 5-এ 286 থেকে 406 token যোগ করে। দশটি অতিরিক্ত বিস্তারিত tool description ছোট prompt-এর আকার দ্বিগুণ করতে পারে।
• Web search-এর জন্য প্রতি 1,000 search-এ $10 চার্জ হয়। এর পাশাপাশি, ফলাফল context-এ প্রবেশ করলে সেগুলো যে token ব্যবহার করে তার জন্যও চার্জ হয়।
• Web fetch-এর নিজস্ব কোনো অতিরিক্ত ফি নেই। তবে fetch করা page input token-এ পরিণত হয়। 100 kB-এর একটি documentation page-এ আনুমানিক 25,000 token থাকে।
• Claude 4.6 এবং পরবর্তী সংস্করণে inference_geo ব্যবহার করে শুধু US-এ inference চালানোর অনুরোধ করলে প্রতিটি token category-তে 1.1 multiplier প্রযোজ্য হয়। Cache read এবং cache write-ও এর অন্তর্ভুক্ত।

API আদৌ কেনা আপনার জন্য সঠিক সিদ্ধান্ত কি না, তা আপনার ব্যবহারের পরিমাণের ওপর নির্ভর করে। কোনো plan-এর usage ceiling-এ পৌঁছানো থেকেই সাধারণত এই প্রশ্ন ওঠে। সীমা অতিক্রম করার বিকল্প পথ হিসেবে নির্ধারিত সময়সীমা শেষ হওয়ার অপেক্ষা করা থেকে শুরু করে সেই কাজ metered API call-এ স্থানান্তর করা পর্যন্ত বিভিন্ন ব্যবস্থা রয়েছে। নির্দিষ্ট একটি ব্যবহারের স্তরের নিচে flat monthly plan সরাসরি বেশি সাশ্রয়ী হয়। Claude subscription-এর সঙ্গে API-এর পরিমিত খরচের তুলনা বাস্তব সংখ্যা দিয়ে এই তুলনা দেখায়।

FAQ

Claude-এ 1M tokens-এর খরচ কত?

এটি model এবং tokens input নাকি output—তার ওপর নির্ভর করে। August 2026 অনুযায়ী, Claude Haiku 4.5-এ এক million input tokens-এর খরচ $1, introductory pricing-এর অধীনে Claude Sonnet 5-এ $2, এবং Claude Opus 5-এ $5। এই model-গুলোর প্রতিটিতে output-এর খরচ input rate-এর পাঁচ গুণ। 1 September 2026 থেকে Sonnet 5-এ input-এর খরচ হবে $3 এবং output-এর খরচ হবে $15। Rate পরিবর্তিত হয়, তাই budget-এ কোনো অঙ্ক নির্ধারণের আগে official pricing page-এ তা যাচাই করুন।

1M tokens কি 1M words-এর সমান?

না। একটি token-এ English ভাষার প্রায় 4টি character, অথবা প্রায় 0.75টি word থাকে। তাই এক million tokens প্রায় 750,000 words-এর সমান। এই অনুপাতটি কেবল একটি আনুমানিক নির্দেশনা। Code, JSON এবং English ছাড়া অন্যান্য ভাষায় প্রতি word-এ বেশি tokens ব্যবহৃত হয়। Claude Opus 4.7 এবং পরবর্তী version-গুলোতে নতুন tokenizer ব্যবহৃত হয়। একই text-এর জন্য এটি Claude Sonnet 4.6 এবং আগের version-গুলোর তুলনায় প্রায় 30 percent বেশি tokens তৈরি করে। তাই ভিন্ন model generation-এর মধ্যে count সরাসরি তুলনাযোগ্য নয়। আপনি যে model চালানোর পরিকল্পনা করছেন, সেটি পাঠিয়ে বিনামূল্যের /v1/messages/count_tokens endpoint ব্যবহার করে পরিমাপ করুন।

Prompt caching কি সব সময় খরচ কমায়?

না। 5 minute-এর cache write-এর খরচ base input rate-এর 1.25 গুণ। তাই কোনো prefix একবার write করার পর আর কখনও read না হলে, সেটি সরাসরি পাঠানোর তুলনায় 25 percent বেশি খরচ হয়। প্রথম read থেকেই এটি খরচ পুষিয়ে দেয়। এটি দুটি কারণে ব্যর্থ হতে পারে, এবং উভয় ক্ষেত্রেই কোনো error দেখা যায় না। Request-গুলোর মধ্যে cached prefix পরিবর্তিত হলে lookup কখনও মেলে না, কারণ এটি exact prefix match ব্যবহার করে। Prefix-টি model-এর minimum cacheable length-এর চেয়ে ছোট হলেও কিছু cache করা হয় না এবং কোনো error ফেরত দেওয়া হয় না। Sonnet 5-এ এই সীমা 1,024 tokens এবং Haiku 4.5-এ 4,096। cache_creation_input_tokens এবং cache_read_input_tokens উভয়ের মান 0 হলে cache কোনো কাজ করছে না।

আমার message count-এর তুলনায় bill দ্রুত বাড়ল কেন?

কারণ প্রতিটি turn-এ পুরো conversation আবার পাঠানো হয়। Messages API কোনো state ধরে রাখে না। তাই chat-এর turn 20-এ আগের 19টি turn আবার input হিসেবে পাঠানো হয়। প্রতিটি turn-এ গড়ে 500 tokens থাকলে, 20 turn-এর conversation-এ প্রায় 105,000 input tokens পাঠানো হয়, যদিও transcript-এর দৈর্ঘ্য মাত্র 10,000 tokens। Agent loop-ও একইভাবে কাজ করে, কারণ প্রতিটি tool result history-তে থেকে যায়। স্থির prefix cache করুন, অথবা পুরোনো turn-গুলোর summary তৈরি করে সেগুলো request থেকে বাদ দিন।