Claude Fable 5-এর দাম ও কখন ব্যবহার করবেন

Claude Fable 5-এর দাম কত?

Claude API-তে Claude Fable 5-এর দাম প্রতি 1 মিলিয়ন input token-এর জন্য $10 এবং প্রতি 1 মিলিয়ন output token-এর জন্য $50। এগুলো Anthropic-এর প্রকাশিত list rate, যা 3 August 2026-এ pricing page থেকে নেওয়া হয়েছে। API model ID হলো claude-fable-5। এটি 9 June 2026-এ Claude API, Amazon Bedrock, Claude Platform on AWS, Google Cloud এবং Microsoft Foundry-তে সাধারণভাবে ব্যবহারের জন্য উপলভ্য হয়।

[
  {
    "label": "Claude Fable 5",
    "input": "10",
    "output": "50",
    "cache_read": "1",
    "batch_input": "5",
    "batch_output": "25"
  },
  {
    "label": "Claude Opus 5",
    "input": "5",
    "output": "25",
    "cache_read": "0.50",
    "batch_input": "2.50",
    "batch_output": "12.50"
  },
  {
    "label": "Claude Sonnet 5 (intro rate)",
    "input": "2",
    "output": "10",
    "cache_read": "0.20",
    "batch_input": "1",
    "batch_output": "5"
  },
  {
    "label": "Claude Sonnet 5 (from 1 Sep)",
    "input": "3",
    "output": "15",
    "cache_read": "0.30",
    "batch_input": "1.50",
    "batch_output": "7.50"
  },
  {
    "label": "Claude Haiku 4.5",
    "input": "1",
    "output": "5",
    "cache_read": "0.10",
    "batch_input": "0.50",
    "batch_output": "2.50"
  }
]

এটিকে একটি ধাপভিত্তিক তুলনা হিসেবে দেখুন। Fable 5-এর list price Claude Opus 5-এর দ্বিগুণ, বর্তমান Claude Sonnet 5 rate-এর পাঁচগুণ এবং Claude Haiku 4.5-এর দশগুণ। বিলের উভয় দিকেই অনুপাত একই, কারণ ওই chart-এর প্রতিটি model নিজের input rate-এর ঠিক পাঁচগুণ দামে output নির্ধারণ করে। তাই কোনো কাজের input ও output token-এর অনুপাত জানা থাকলে, গুণ করে একটি price থেকে অন্য যেকোনো price হিসাব করা যায়।

একটি তারিখে এই হিসাব বদলে যায়। 31 August 2026 পর্যন্ত Sonnet 5-এর introductory pricing হলো প্রতি 1 মিলিয়ন token-এর জন্য $2 এবং $10। 1 September 2026 থেকে এর list price হবে $3 এবং $15। Fable 5-এর নিজস্ব price বদলাবে না। তাই ওই দিনে দুইটির দামের ব্যবধান পাঁচগুণ থেকে কমে সামান্য তিনগুণের বেশি হবে। শরৎকালের জন্য budget তৈরি করলে Sonnet-এর পরের rate ব্যবহার করুন।

ডিসকাউন্ট এবং বিপরীত দিকে কাজ করা একমাত্র multiplier

Prompt caching-ই সবচেয়ে বড় সাশ্রয়ের সুযোগ। Cache read-এর খরচ base input price-এর এক-দশমাংশ। Fable 5-এ প্রতি মিলিয়ন token-এর জন্য এই খরচ $1। Cache-এ লেখা সাধারণ input token-এর চেয়ে বেশি ব্যয়বহুল: পাঁচ মিনিটের cache-এর জন্য base-এর 1.25 গুণ এবং এক ঘণ্টার cache-এর জন্য base-এর 2 গুণ। পাঁচ মিনিটের cache একবার read হলেই নিজের খরচ তুলে ফেলে। এক ঘণ্টার cache-এর ক্ষেত্রে এটি দুইবার read-এর পরে ঘটে। সর্বত্র এটি চালু করার আগে কোথায় prompt caching-এর খরচ উঠে আসে তা হিসাব করা-র পক্ষে এই হিসাবই যথেষ্ট।

Batch API উভয় দিকের খরচে 50% ছাড় দেয়। তাই batched Fable 5 কাজের খরচ প্রতি মিলিয়ন token-এর জন্য $5 এবং $25। Batch request asynchronous হওয়ায়, এখনই উত্তর দরকার নেই এমন কাজেই এটি কার্যকর। দুটি discount একসঙ্গে প্রযোজ্য হয়। ফলে cached, batched job উভয় দিকেই কম খরচের হয়।

Claude 4.6 এবং পরবর্তী model-এ 1M token-এর context window standard rate-এর মধ্যেই অন্তর্ভুক্ত। Long context-এর জন্য অতিরিক্ত surcharge নেই। তাই 900k token-এর request-এর প্রতি token-এর rate 9k token-এর request-এর মতোই।

Bill বাড়ায় যে multiplier, সেটি হলো data residency। inference United States-এর মধ্যে সীমাবদ্ধ রাখতে inference_geo: "us" সেট করলে cache read এবং cache write-সহ প্রতিটি token category-তে 1.1 গুণ multiplier প্রযোজ্য হয়। কোনো contract-এ অন্যথা বলা না থাকলে default global routing চালু রাখুন।

এই model-এর জন্য একটি billing rule নির্দিষ্ট। Fable 5 এমন safety classifier সরবরাহ করে যা request প্রত্যাখ্যান করতে পারে। এ ক্ষেত্রে Messages API error ফেরত না দিয়ে সফল HTTP 200 response হিসেবে stop_reason: "refusal" ফেরত দেয়। কোনো output তৈরি হওয়ার আগে request প্রত্যাখ্যাত হলে এর জন্য আপনাকে bill করা হয় না। একই prompt অন্য কোনো Claude model-এ retry করলে fallback credit switch-এর prompt cache cost ফেরত দেয়। ফলে একই cache দুবার warm করার জন্য আপনাকে অর্থ দিতে হয় না।

কোন প্ল্যানগুলোতে Claude Fable 5 অন্তর্ভুক্ত?

3 August 2026 অনুযায়ী, Anthropic-এর Claude Fable পেজে বলা হয়েছে যে মডেলটি Pro, Max, Team এবং Enterprise ব্যবহারকারীদের জন্য উপলভ্য। Free plan-এর নাম সেখানে উল্লেখ করা হয়নি। এই তালিকায় Pro হলো সবচেয়ে সস্তা seat। তাই Pro-এর খরচ এবং কোথায় এর usage limit আপনাকে থামিয়ে দেয়—এটাই Fable ব্যবহারের যেকোনো subscription route-এর ন্যূনতম খরচ নির্ধারণ করে। আপনি upgrade করার প্রধান কারণ হিসেবে Fable access বিবেচনা করলে, আগে আপনার নিজের ব্যবহারের ক্ষেত্রে Pro seat-এর জন্য অর্থ দেওয়া সার্থক কি না যাচাই করুন। কারণ সীমিত Fable allowance একাই subscription নেওয়ার যথেষ্ট কারণ নয়। Developers-এর জন্য Claude API এবং উপরে তালিকাভুক্ত cloud marketplace-গুলোতে এটি সাধারণভাবে উপলভ্য। ওই route-এ কোনো free tier নেই। তাই meter চালু হওয়ার আগে Anthropic signup-এর সময় যে সামান্য credit দেয় সেটিই আপনার প্রাপ্য।

কোনো প্ল্যানে উপলভ্য থাকা মানেই সীমাহীনভাবে অন্তর্ভুক্ত থাকা নয়। Subscription-এর ব্যবহারও API-এর মতো metered নয়। কারণ কোনো Pro seat-এর জন্য প্রকাশিত token quota নেই; এর পরিবর্তে rolling window-এ message সংখ্যার ভিত্তিতে ব্যবহার গণনা করা হয়। তাই কোনো প্ল্যানের সুবিধাকে ওপরের প্রতি million সংখ্যার সঙ্গে সরাসরি মেলানো যায় না।

Anthropic-এর pricing page-এর plan comparison table-এ কিছু seat-এর জন্য weekly usage limit-এর একটি অংশের মাধ্যমে এবং অন্য কিছু seat-এর জন্য usage credit-এর মাধ্যমে Fable ব্যবহারের সীমা নির্ধারণ করা হয়েছে। July 2026-এ এই ব্যবস্থা একাধিকবার পরিবর্তিত হয়েছে। Fable 5 পুনরায় deploy করা নিয়ে Anthropic-এর নিজস্ব বিবৃতিতে বলা হয়েছিল যে Pro, Max, Team এবং নির্বাচিত Enterprise plan-এ 7 July 2026 পর্যন্ত weekly usage limit-এর সর্বোচ্চ 50% পর্যন্ত model-টি ব্যবহার করা যাবে। ওই তারিখের পরে usage credit প্রযোজ্য হবে। July-এর বাকি সময়ের প্রতিবেদনগুলোতে আরও extension এবং বিভিন্ন seat type-এর মধ্যে বিভাজনের কথা বলা হয়েছে।

তাই এই পেজে plan অনুযায়ী কোনো নির্দিষ্ট limit দেওয়া হবে না। ওই মাসে প্রকাশিত কোনো সংখ্যাই দুই সপ্তাহ স্থায়ী ছিল না। এখানে পুরোনো সংখ্যা দেওয়া হলে কোনো সংখ্যা না দেওয়ার চেয়ে বেশি বিভ্রান্তিকর হবে। আপনি সিদ্ধান্ত নেওয়ার দিন plan comparison table-এ Fable লেখা row খুলুন। কোনো news article-এ থাকা সংখ্যাকে পুরোনো ধরে নিন। Fable access-এর জন্য seat নেওয়ার পর যদি allowance table দেখে আপনার প্রত্যাশার চেয়ে কম মনে হয়, পরবর্তী renewal-এর আগে plan downgrade করলে ইতিমধ্যে যে মাসের জন্য অর্থ দিয়েছেন সেটি অক্ষত থাকবে।

যেটি স্থিতিশীল, সেটি হলো API rate। যেকোনো route-এ included allowance শেষ হয়ে গেলে পরবর্তী Fable 5 usage-এর জন্য উপরের chart-এ দেওয়া price অনুযায়ী বিল হবে। Enterprise এই কাঠামোটি স্পষ্ট করে। কারণ Enterprise seat fee access কেনে, কিন্তু token-এর জন্য আলাদাভাবে API rate অনুযায়ী meter চলতে থাকে। তাই দুই ক্ষেত্রেই পরিকল্পনা করার জন্য price list-ই প্রধান সংখ্যা। অন্য কোনো Claude model-এর ক্ষেত্রে API billing এবং subscription-এর তুলনা করলেও একই সিদ্ধান্তে পৌঁছাবেন। আপনি এখনো কোনো tier বেছে না নিলে কোন Claude plan আপনার ব্যবহারের সঙ্গে মানানসই তা দিয়ে শুরু করুন। ওই seat যদি শুধু Fable access-এর জন্য নয়, আপনার দৈনন্দিন assistant হিসেবেও ব্যবহৃত হয়, তাহলে সিদ্ধান্ত নেওয়ার আগে Claude plan-গুলোর মূল্য ChatGPT-এর মূল্যের তুলনায় কেমন তা যাচাই করা ভালো।

আপনার বিল কেন মূল্য অনুপাতের চেয়ে বেশি হয়

দুটি নথিবদ্ধ প্রক্রিয়ার কারণে সরাসরি মূল্য তুলনা থেকে যে হিসাব পাওয়া যায়, Fable 5-এর খরচ তার চেয়ে বেশি হয়।

প্রথমটি হলো tokenizer। Fable 5 Claude Opus 4.7-এর সঙ্গে প্রবর্তিত tokenizer ব্যবহার করে। Opus 4.7-এর আগে প্রকাশিত model-গুলোর তুলনায় একই text-এ প্রায় 30% বেশি token তৈরি হয়, এবং সঠিক বৃদ্ধি content-এর ওপর নির্ভর করে। Haiku 4.5 এই tokenizer-এর আগের, তাই উভয় model-এ একই text block পাঠালে price list-এর দশ গুণ ব্যবধান বাস্তবে প্রায় তেরো গুণের কাছাকাছি হয়। Sonnet 5 নতুন tokenizer ব্যবহার করে, তাই Fable এবং Sonnet-এর মধ্যে প্রতি token-এর তুলনা যথাযথ। Fable এবং Haiku-এর মধ্যে তা নয়।

দ্বিতীয়টি হলো thinking। Fable 5-এ adaptive thinking সবসময় চালু থাকে, এবং thinking: {"type": "disabled"} সমর্থিত নয়। Thinking token-গুলো output token হিসেবে, সম্পূর্ণ output rate-এ, বিল করা হয়। এই model-এ raw chain of thought কখনও ফেরত দেওয়া হয় না, এবং thinking.display-এর default মান "omitted"; এর অর্থ, সংক্ষিপ্ত দৃশ্যমান উত্তরের সঙ্গেও বড় billed output count থাকতে পারে। Anthropic-এর documentation বিষয়টি স্পষ্টভাবে উল্লেখ করে: billed output token count response-এ দৃশ্যমান token count-এর সঙ্গে মেলে না।

অনুমান না করে breakdown দেখুন। usage.output_tokens_details.thinking_tokens field-এ reasoning-এর জন্য ব্যবহৃত billed output token-এর সংখ্যা দেখানো হয়:

{
  "usage": {
    "input_tokens": 25,
    "output_tokens": 348,
    "output_tokens_details": {
      "thinking_tokens": 312
    }
  }
}

Anthropic-এর thinking documentation থেকে নেওয়া ওই উদাহরণে 348টি billed output token-এর মধ্যে 312টি ছিল এমন reasoning, যা কেউ দেখেনি। আপনি stream ব্যবহার করলে এই breakdown শুধু শেষ message_delta event-এ আসে। তাই শেষ text chunk-এর পর পড়া বন্ধ করে দেওয়া client এটি কখনও record করবে না।

নিয়ন্ত্রণটি হলো effort, যা output_config.effort-এ সেট করা হয়। এর level হলো low, medium, high (default), xhigh এবং max।

{
  "model": "claude-fable-5",
  "max_tokens": 32000,
  "output_config": { "effort": "medium" },
  "messages": [{ "role": "user", "content": "..." }]
}

এই model-এর জন্য Anthropic-এর নির্দেশনা হলো high দিয়ে শুরু করা, capability-sensitive সবচেয়ে গুরুত্বপূর্ণ কাজের ক্ষেত্রে শুধু xhigh-এ যাওয়া, এবং routine কাজের জন্য medium বা low-এ নামিয়ে আনা। কারণ, Fable 5-এ কম effort প্রায়ই আগের model-গুলোর xhigh-এর চেয়ে ভালো ফল দেয়। এর সঙ্গে দুটি বিষয় মনে রাখতে হবে। Request-এর মধ্যে effort পরিবর্তন করলে prompt cache অকার্যকর হয়, কারণ resolved effort value prompt-এর মধ্যে লেখা হয়। তাই প্রতিটি workload-এর জন্য একটি level বেছে নিয়ে সেটি অপরিবর্তিত রাখুন। আর max_tokens হলো thinking এবং response text-সহ মোট output-এর ওপর একটি hard cap। তাই thinking ছাড়া উত্তরের জন্য নির্ধারিত cap ব্যবহার করলে response অসম্পূর্ণ হয়ে যেতে পারে। stop_reason: "max_tokens" দেখা গেলে cap বাড়ান অথবা effort কমান।

সম্পন্ন কাজপ্রতি খরচ, tokenপ্রতি খরচ নয়

[
  {
    "label": "Short answer (5k in, 1k out)",
    "fable_5": "0.10",
    "opus_5": "0.05",
    "sonnet_5": "0.02",
    "haiku_4_5": "0.01"
  },
  {
    "label": "Coding session (300k in, 40k out)",
    "fable_5": "5.00",
    "opus_5": "2.50",
    "sonnet_5": "1.00",
    "haiku_4_5": "0.50"
  },
  {
    "label": "Long agent run (2M in, 400k out)",
    "fable_5": "40.00",
    "opus_5": "20.00",
    "sonnet_5": "8.00",
    "haiku_4_5": "4.00"
  }
]

ওই 3টি row benchmark নয়, arithmetic। Rate প্রকাশিত। Token volume অনুমানভিত্তিক; এগুলো আপনার নিজের usage data-এর পরিসংখ্যান দিয়ে প্রতিস্থাপন করুন। মাঝের row-এর মতো একটি coding session-এর খরচ Fable 5-এ $5.00, আর Sonnet 5-এ $1.00। দীর্ঘ run-এর খরচ যথাক্রমে $40.00 এবং $8.00। শেষ row-এর Haiku column-টি শুধু arithmetic: Haiku 4.5-এর context window 200k token, তাই সেটি ওই job ধারণ করতেই পারে না।

সিদ্ধান্ত নেওয়ার জন্য tokenপ্রতি খরচ সঠিক একক নয়। সম্পন্ন কাজপ্রতি খরচ হলো প্রতিটি attempt-এর খরচকে মোট attempt সংখ্যা দিয়ে গুণ করা। আজকের rate অনুযায়ী Fable 5-এর একটি attempt-এর খরচ Sonnet 5-এর পাঁচটি attempt-এর সমান। তাই শুধু retry count সাধারণত upgrade করার যথেষ্ট কারণ নয়। Token-এর হিসাবে সস্তা পথটি অকার্যকর হতে হলে Sonnet-কে পাঁচটির মধ্যে চারটির বেশি attempt-এ ব্যর্থ হতে হবে।

যে বিষয়গুলো upgrade-কে যুক্তিযুক্ত করে, সেগুলো token bill-এ অন্তর্ভুক্ত থাকে না। Chart-এর দুইটি দীর্ঘ run-এর খরচের পার্থক্য অধিকাংশ market-এ engineer-এর এক ঘণ্টার সময়ের খরচের চেয়েও কম। Expensive model যদি review করতে এক ঘণ্টা সময় বাঁচায়, অথবা একটি ভুল migration এড়ায় যেটি পরে আপনাকে ঠিক করতে হতো, তাহলে এমন একটি bill-এর ভিত্তিতেই সেটি নিজের খরচ তুলে ফেলেছে যেখানে সেই সাশ্রয় দেখা যায় না। তুলনাটি accepted resultপ্রতি অর্থমূল্যে করুন এবং মোট হিসাবের মধ্যে আপনার নিজের সময়ও অন্তর্ভুক্ত করুন। এক মিলিয়ন token আসলে কী সুবিধা দেয় তা জানা এই হিসাবকে অনেক কম বিমূর্ত করে।

Claude Fable 5-এর মূল্য সার্থক হওয়ার 3টি কাজ

দীর্ঘ সময় ধরে চলা agent run, যেখানে ভুল সিদ্ধান্তের খরচ বেশি। Fable 5 ঘণ্টায় পরিমাপ করা কাজের জন্য তৈরি: এতে 1M token-এর context window, প্রতিটি request-এ সর্বোচ্চ 128k output token এবং xhigh effort level রয়েছে। এই effort level 30 মিনিটের বেশি চলা এবং millions token budget প্রয়োজন এমন কাজের জন্য উপযোগী। এমন একটি run-এর খরচের সঙ্গে তুলনা করুন সেই cleanup-এর খরচ, যেখানে agent 40 নম্বর ধাপে ভুল branch বেছে নেয় এবং কেউ তা 300 নম্বর ধাপ পর্যন্ত বুঝতে পারে না।

বড় codebase জুড়ে একবার চালানো migration বা audit। একবারের কাজের ক্ষেত্রে volume দিয়ে খরচ কমানোর সুযোগ থাকে না। তাই প্রতি token-এর অতিরিক্ত খরচ একটি মাত্র invoice-এ যুক্ত হয়, এবং পুরো কাজটি একটি context window-এর মধ্যেই সম্পন্ন হতে পারে। কাজটি asynchronous ভাবে চালানো গেলে Batch API প্রতি million output token-এর খরচ অর্ধেক করে $25-এ নামিয়ে আনে।

যে কাজ একটি সস্তা model ইতিমধ্যে 2 বার ব্যর্থ হয়েছে। 2টি ব্যর্থ চেষ্টা এবং আপনার debugging time মিলিয়ে উপরের chart-এ দেখানো volume-এ একটি Fable attempt-এর চেয়ে বেশি খরচ হয়। তাই escalation-ই সস্তা পথ, এবং model ladder-এর উদ্দেশ্যও এটাই। আপনি যদি এখনও সাধারণভাবে tier বেছে নেওয়ার চেষ্টা করেন, Claude model tier-গুলোর capability comparison এই page-এর প্রশ্নের বদলে অন্য একটি প্রশ্নের উত্তর দেয়।

তিনটি কাজ, যেখানে Sonnet 5 বা Haiku 4.5-ই সঠিক পছন্দ

বেশি পরিমাণে শ্রেণিবিন্যাস ও তথ্য নিষ্কাশন। এই কাজগুলোর মূল্যায়ন হয় throughput এবং প্রতি ইউনিট খরচের ভিত্তিতে। গুণমানের সর্বোচ্চ সীমা এত কম যে একটি সস্তা model-ই তা পূরণ করতে পারে। Haiku 4.5 যে কাজ সঠিকভাবে সম্পন্ন করে, সেটির জন্য দশ গুণ বেশি খরচ করলে Fable 5 পরিমাপযোগ্য কোনো সুবিধা দেয় না।

যে interactive কাজে latency-ই মূল পণ্য। Anthropic-এর model table-এ Fable 5-এর তুলনামূলক latency বেশি ধীর হিসেবে দেখানো হয়েছে। এছাড়া thinking বন্ধ করা যায় না। chat box বা editor completion-এ বেশি সক্ষম model ব্যবহার করলে অভিজ্ঞতা খারাপ লাগে, কারণ ব্যবহারকারীরা গুণমান বোঝার আগে অপেক্ষার সময় অনুভব করেন।

যে কাজের ফলাফল January 2026-এর পরের ঘটনাগুলোর ওপর নির্ভর করে। Fable 5-এর নির্ভরযোগ্য knowledge cutoff হলো January 2026। Opus 5-এর cutoff হলো May 2026। বেশি ব্যয়বহুল model-টিই কম সাম্প্রতিক তথ্য ব্যবহার করে। তাই সাম্প্রতিক তথ্যসংক্রান্ত প্রশ্নে search বা fetch tool না দিলে পুরোনো জ্ঞানের জন্য আপনাকে দ্বিগুণ খরচ করতে হয়।

একটি সীমাবদ্ধতা সম্পূর্ণভাবে খরচের বাইরে। Fable 5-এ 30 day data retention প্রযোজ্য এবং এটি zero data retention-এর অধীনে উপলভ্য নয়, কারণ এটিকে Covered Model হিসেবে নির্ধারণ করা হয়েছে। আপনার agreement-এ zero retention বাধ্যতামূলক হলে কোনো মূল্যেই Fable 5 ব্যবহার করা যাবে না। কোনো discount এই সীমাবদ্ধতা পরিবর্তন করে না।

fable-method রিপোজিটরিগুলো কী দেখায়, আর কী দেখায় না

ব্যবহারকারীরা এমন রিপোজিটরি প্রকাশ করেছেন, যেগুলো Fable 5-এর পদ্ধতিগুলো কীভাবে কাজ করে তা সংক্ষেপে তুলে ধরে, যাতে কম খরচের একটি মডেল সেগুলো অনুসরণ করতে পারে। fable-method রিপোজিটরি-তে একটি চিন্তন দক্ষতা, একটি orchestration loop এবং একটি adversarial verifier-এর বর্ণনা আছে। এই verifier agent-এর নিজস্ব প্রতিবেদনের ওপর নির্ভর না করে দাবিকৃত প্রতিটি check আবার চালায়। এর README-তে সরাসরি বলা আছে: "এটি একটি community distillation, Anthropic-এর artifact নয়।"

বিষয়টিকে ঠিক সেভাবেই বিবেচনা করুন। এটি দেখায় যে মানুষ কীভাবে মডেলটি পরিচালনা করছে। এটি মডেলটি কীভাবে কাজ করে তার documentation নয়। এর কোনো বিষয় Anthropic যাচাই করেনি। একই ধরনের wording-সহ একাধিক প্রায় অভিন্ন fork-ও রয়েছে। এটি কোনো specification-এর চেয়ে প্রচলিত অনানুষ্ঠানিক জ্ঞানের ফল বলেই বেশি প্রত্যাশিত।

খরচ-সংক্রান্ত সিদ্ধান্তের জন্য এখান থেকে যে বিষয়টি গ্রহণযোগ্য, তা হলো মানুষ যে অংশগুলো অনুলিপি করার মতো গুরুত্বপূর্ণ মনে করেছে সেগুলো procedural। কাজের শ্রেণি নির্ধারণ করুন। কাজটি সম্পন্ন হয়েছে প্রমাণ করে এমন check নির্দিষ্ট করুন। সিদ্ধান্ত নেওয়ার আগে evidence সংগ্রহ করুন। তারপর summary পড়ে নয়, observation-এর মাধ্যমে verify করুন। কম খরচের একটি মডেলকে স্পষ্ট checklist এবং verification step দিলে পার্থক্যের একটি অংশ কমানো যায়। তাই ব্যয়বহুল মডেলকে standardize করার আগে নিজের evaluation set-এ এই পরীক্ষা চালান। ফলাফল আপনার কাজগুলোর ওপর নির্ভর করবে। এ কারণেই অন্য কারও সংখ্যা আপনার জন্য খুব বেশি কার্যকর নয়।

বাজেট নির্ধারণের আগে নিজের সংখ্যাগুলো যাচাই করুন

• প্রতিটি response-এ usage পড়ুন এবং visible output থেকে output_tokens_details.thinking_tokens আলাদাভাবে log করুন। আপনি যে reasoning দেখতে পান না, সেটিই প্রায়ই অপ্রত্যাশিত খরচের কারণ হয়।
• ডিফল্ট গ্রহণ না করে effort স্পষ্টভাবে নির্ধারণ করুন এবং prompt caching-এর ওপর নির্ভরশীল কোনো conversation-এর মধ্যে এটি অপরিবর্তিত রাখুন।
• প্রথমে আপনার স্থিতিশীল prefix-কে একটি cache breakpoint-এর পেছনে রাখুন। base input price-এর এক-দশমাংশ দামে cache read ব্যবহার করলে অধিকাংশ model downgrade-এর চেয়ে বেশি সাশ্রয় হয়।
• যেসব কাজের জন্য তাৎক্ষণিক উত্তর প্রয়োজন নেই, সেগুলো Batch API-তে স্থানান্তর করুন।
• বিকল্পটির মূল্য সঠিকভাবে হিসাব করুন। নিজের workload-এ Claude এবং ChatGPT API pricing তুলনা করা দীর্ঘমেয়াদি সিদ্ধান্ত নেওয়ার আগে একটি বিকেল ব্যয় করার মতো কাজ।

যদি workload আপনার নিজের server-এ চলা কোনো agent হয়, তাহলে সবচেয়ে গুরুত্বপূর্ণ নিয়ন্ত্রণগুলো model পছন্দের বাইরে থাকে। VPS-এ agent-এর খরচ নিয়ন্ত্রণে রাখা-এ runaway session থামানোর loop limit এবং spend cap ব্যাখ্যা করা হয়েছে, আর Claude Code আসলে কোথায় token খরচ করে-এ আপনার usage dashboard-এ দেখা সংখ্যাগুলোর ব্যাখ্যা রয়েছে।

FAQ

Claude Fable 5-এর প্রতি মিলিয়ন token-এর খরচ কত?

Claude API-তে Claude Fable 5-এর মূল্য প্রতি মিলিয়ন input token-এ $10 এবং প্রতি মিলিয়ন output token-এ $50। Anthropic-এর pricing page-এ 3 August 2026 তারিখে এই মূল্য দেখা হয়েছে। Cache read-এর মূল্য প্রতি মিলিয়ন token-এ $1, যা মূল input rate-এর এক দশমাংশ। Batch API উভয় দিকের মূল্যে 50% ছাড় দেয়। ফলে asynchronous কাজের জন্য প্রতি মিলিয়ন token-এর মূল্য $5 input এবং $25 output। inference_geo parameter ব্যবহার করে inference যুক্তরাষ্ট্রের মধ্যেই রাখলে প্রতিটি category-তে 1.1 গুণ multiplier যোগ হয়।

Claude Pro subscription-এ কি Claude Fable 5 অন্তর্ভুক্ত?

Anthropic-এর Claude Fable page-এ model-টিকে Pro, Max, Team এবং Enterprise user-দের জন্য available বলা হয়েছে। সেখানে free plan-এর নাম উল্লেখ করা হয়নি। Included access সীমাহীন নয়। কিছু seat-এ weekly usage limit-এর অংশ হিসেবে Fable ব্যবহার করা যায়। অন্যগুলোতে usage credit-এর মাধ্যমে ব্যবহার করা যায়। July 2026-এ এই ব্যবস্থা একাধিকবার পরিবর্তিত হয়েছে। ব্যবহারের সিদ্ধান্ত নেওয়ার দিন Anthropic-এর pricing page-এর plan comparison table-এ Fable লেখা row দেখুন। কোনো article-এর পুরোনো সংখ্যার ওপর নির্ভর করবেন না। Included allowance শেষ হলে পরবর্তী ব্যবহারের জন্য API rate অনুযায়ী বিল হয়।

দৃশ্যমান output-এর তুলনায় Claude Fable 5-এর বিল বেশি কেন?

Claude Fable 5-এ adaptive thinking সবসময় চালু থাকে। Thinking token-কে output token হিসেবে বিল করা হয়। Raw chain of thought কখনো ফেরত দেওয়া হয় না। thinking.display-এর default মান omitted থাকলে আপনি একটি খালি thinking field দেখেন, কিন্তু এর পেছনে ব্যবহৃত প্রতিটি reasoning token-এর জন্য মূল্য দেন। বিভাজন দেখতে response-এ usage.output_tokens_details.thinking_tokens পড়ুন। Streaming ব্যবহারের সময় এটি শুধু শেষ message_delta event-এ আসে। Task-এর প্রয়োজনের তুলনায় reasoning এবং answer-এর অনুপাত বেশি হলে effort level কমান।

Claude Fable 5 নাকি Claude Opus 5 ব্যবহার করা উচিত?

Claude Opus 5 প্রতি token-এ অর্ধেক খরচ হয়। এর reliable knowledge cutoff-ও বেশি সাম্প্রতিক: Opus 5-এর জন্য May 2026, আর Fable 5-এর জন্য January 2026। প্রথমে Opus 5 ব্যবহার করুন। সেখানে task ব্যর্থ হলে, অথবা ভুল উত্তরের ক্ষতি price difference-এর চেয়ে বেশি হলে Fable 5-এ যান। দীর্ঘ horizon-এর agent কাজের জন্য Claude Fable 5 উপযুক্ত, যেখানে একটি ভুল branch ঠিক করতে কয়েক ঘণ্টা cleanup লাগতে পারে। এমন one-off কাজের ক্ষেত্রেও এটি উপযুক্ত, যেখানে অতিরিক্ত মূল্য প্রতিটি request-এ স্থায়ীভাবে না নিয়ে একটি মাত্র invoice-এ যোগ হয়।