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

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

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

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

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

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

Token হলো মডেল যে পাঠ্য পড়ে বা লেখে তার একটি অংশ। Anthropic-এর আনুমানিক নির্দেশনা অনুযায়ী, প্রতি 4 অক্ষরে 1টি token, অথবা ইংরেজিতে প্রায় 0.75টি শব্দ থাকে। তাই 1 million token প্রায় 750,000 শব্দ, অথবা আনুমানিক 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-এ কম শব্দ থাকে। তাই 0.75 অনুপাতটি আশাবাদী হিসাবের দিকের। আরও একটি বিষয় token-এর সংখ্যা পরিবর্তন করে: Claude Opus 4.7 এবং পরবর্তী সংস্করণ, যার মধ্যে Opus 5 ও Sonnet 5 রয়েছে, একটি নতুন tokenizer ব্যবহার করে। একই text-এর জন্য এটি Sonnet 4.6 এবং আগের সংস্করণগুলোর তুলনায় প্রায় 30 percent বেশি token তৈরি করে। Claude Haiku 4.5 পুরোনো tokenizer ব্যবহার করে। তাই Haiku 4.5-এ মাপা কোনো হিসাব একই input-এর ক্ষেত্রে Sonnet 5-এ প্রকৃত token সংখ্যা কম দেখায়। এর অর্থ, ওই সীমার দুই পাশে সরাসরি প্রতি-million মূল্য তুলনা ন্যায্য নয়। সিদ্ধান্ত নেওয়ার আগে একই prompt উভয় model-এর বিরুদ্ধে গণনা করুন।

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

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

এই rate Claude-এর খরচ জানায়, কিন্তু আপনার workload-এর জন্য এটি সস্তা option কি না তা জানায় না। Claude এবং ChatGPT উভয় ক্ষেত্রেই তিনটি কাজের খরচের হিসাব দেখায় কোন API কোন ক্ষেত্রে বেশি সাশ্রয়ী।

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 cents। আপনার কোডে দুটি rate একই জায়গায় রাখুন। মূল্যে পরিবর্তন হলে দুটি line সম্পাদনা করলেই আপনার system-এর প্রতিটি estimate-এর হিসাবও সেই অনুযায়ী পরিবর্তিত হবে।

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

একটি support assistant বিবেচনা করুন। এর system prompt এবং product documentation মিলিয়ে 4,000 tokens হয়। Messages API stateless হওয়ায় এবং model কোনো call-এর তথ্য পরবর্তী call-এর মধ্যে মনে না রাখায়, এগুলো প্রতিটি request-এর সঙ্গে পাঠানো হয়। একজন user-এর question-এ প্রায় 300 tokens যোগ হয়। একটি answer প্রায় 400 tokens হয়। অর্থাৎ প্রতি request-এ 4,300 input এবং 400 output tokens লাগে।

এক মিলিয়ন 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-এ আপনি যে model বেছে নেন এবং caching সম্পর্কে যে সিদ্ধান্ত নেন, প্রতিটির প্রভাব আপনার negotiated rate-এর চেয়ে বেশি। কোন model চালাবেন, সেটি আলাদা প্রশ্ন। আপনার evaluation পাস করা সবচেয়ে সস্তা model-টিই বেছে নিন: Opus, Sonnet এবং Haiku-এর মধ্যে নির্বাচন-এ এটি সঠিকভাবে পরীক্ষা করার পদ্ধতি ব্যাখ্যা করা হয়েছে।

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

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

Cache read-এর খরচ base input rate-এর 0.1 গুণ। 5 minute lifetime-এর জন্য cache লেখার খরচ 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-identical হতে হবে। Cache lookup prefix match ব্যবহার করে। তাই system prompt-এর শুরুতে timestamp বা user's name থাকলে প্রতিটি request-এ prefix পরিবর্তিত হয়। তখন প্রতিবার base input-এর 1.25 গুণ খরচ হয়, কিন্তু একবারও read হয় না। এর লক্ষণ হলো cache_creation_input_tokens-এর মান বেশি থাকা, আর cache_read_input_tokens-এর মান 0 থাকা। একই content থাকা request-গুলোর শেষ 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-এ হয় না, কারণ 4,000 ওই model-এর minimum-এর চেয়ে কম। উভয় counter-এর মান 0 হলে কোনো কিছু cache করা হয়নি।

Batch processing হার অর্ধেক করে

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

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

একটি conversation-এর মধ্যে chat-এর খরচ কেন বাড়ে

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

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

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

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

শব্দের সংখ্যা থেকে token-এর সংখ্যা নির্ণয় করা বন্ধ করুন। API আপনার জন্য বিনা খরচে token গণনা করে। এই গণনার rate limit message তৈরির 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"
    }]
  }'

উত্তরে একটি field থাকে:

{ "input_tokens": 14 }

আপনার প্রকৃত system prompt এবং tool definition, সঙ্গে একটি প্রতিনিধিত্বমূলক user message, এতে পাঠান। এরপর উপরের cost function-এ সেই সংখ্যা ব্যবহার করুন। এই endpoint একটি message request-এর মতো একই body গ্রহণ করে। তাই images এবং PDFs-ও সঠিকভাবে গণনা হয়। দুটি বিষয় মনে রাখতে হবে। এই সংখ্যা একটি 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 যোগ করে। দশটি verbose 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-এ পৌঁছানোই সাধারণত এই প্রশ্নের সূত্রপাত করে। limit অতিক্রম করার বিকল্প পথ হিসেবে window শেষ হওয়া পর্যন্ত অপেক্ষা করা থেকে শুরু করে সেই কাজ 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-এর rate পরিবর্তিত হয়ে input-এর জন্য $3 এবং output-এর জন্য $15 হবে। Rate পরিবর্তিত হতে পারে, তাই budget-এ কোনো অঙ্ক যুক্ত করার আগে official pricing page-এ তা নিশ্চিত করুন।

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

না। একটি token-এ English-এর প্রায় 4টি character, বা প্রায় 0.75টি word থাকে। তাই one million tokens-এ প্রায় 750,000টি word থাকে। এই অনুপাতটি কেবল একটি আনুমানিক নির্দেশনা। 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-তে থেকে যায়। Stable prefix cache করুন, অথবা পুরোনো turn-গুলোর summary তৈরি করে সেগুলো request থেকে বাদ দিন।