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

Claude Fable 5-এর খরচ কত?

Claude API-তে Claude Fable 5-এর মূল্য প্রতি 1 million input token-এ $10 এবং প্রতি 1 million output token-এ $50। এগুলো Anthropic-এর প্রকাশিত তালিকাভুক্ত মূল্য, যা 3 August 2026 তারিখে pricing page থেকে নেওয়া হয়েছে। API model ID হলো claude-fable-5। 9 June 2026 তারিখে Claude API, Amazon Bedrock, AWS-এর Claude Platform, 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-এর খরচ Claude Opus 5-এর দ্বিগুণ, বর্তমান Claude Sonnet 5 rate-এর পাঁচগুণ এবং Claude Haiku 4.5-এর দশগুণ। দুই ধরনের token-এর ক্ষেত্রেই অনুপাত একই, কারণ ওই chart-এর প্রতিটি model নিজের input rate-এর ঠিক পাঁচগুণ output rate নির্ধারণ করে। তাই কোনো কাজের input ও output token-এর অনুপাত জানা থাকলে, multiplication করে একটি মূল্যের ভিত্তিতে অন্য যেকোনো model-এর মূল্য হিসাব করা যায়।

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

ছাড়, এবং বিল বাড়ায় এমন একমাত্র multiplier

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

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

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

যে multiplier বিল বাড়ায়, সেটি হলো data residency। inference_geo: "us" সেট করে inference United States-এর মধ্যে সীমাবদ্ধ করলে 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 প্রত্যাখ্যাত হলে এর জন্য billing হয় না। একই 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 প্ল্যানের নাম সেখানে উল্লেখ করা হয়নি। ডেভেলপারদের জন্য মডেলটি Claude API-তে এবং উপরে তালিকাভুক্ত cloud marketplace-গুলোর মাধ্যমে সাধারণভাবে উপলভ্য।

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

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

যা স্থিতিশীল, তা হলো API rate। প্রতিটি route-এ অন্তর্ভুক্ত allowance শেষ হয়ে গেলে পরবর্তী Fable 5 ব্যবহারের জন্য উপরের chart-এ দেওয়া rate অনুযায়ী বিল করা হবে। তাই উভয় ক্ষেত্রেই পরিকল্পনার ভিত্তি হিসেবে price list-ই ব্যবহার করতে হবে। অন্য কোনো Claude model-এর ক্ষেত্রে API billing ও subscription-এর তুলনা করলেও একই সিদ্ধান্তে পৌঁছাবেন। আপনি যদি এখনও কোনো tier নির্বাচন না করে থাকেন, তাহলে আপনার ব্যবহারের সঙ্গে কোন Claude plan মেলে তা দিয়ে শুরু করুন।

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

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

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

দ্বিতীয় কারণ 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 token-এর সংখ্যা অনেক বেশি হতে পারে। 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 থেমে গেলে সেটি breakdown কখনো record করবে না।

নিয়ন্ত্রণটি হলো effort। এটি output_config.effort-এ set করা হয়। এর 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-এ বাড়ান। নিয়মিত কাজের জন্য medium বা low-এ কমান। কারণ Fable 5-এ কম effort অনেক সময় আগের model-গুলোর xhigh-এর চেয়ে ভালো ফল দেয়। এর সঙ্গে দুটি সমস্যা আছে। Request-এর মধ্যে effort পরিবর্তন করলে prompt cache invalid হয়ে যায়, কারণ resolved effort value prompt-এর মধ্যে লেখা হয়। তাই প্রতিটি workload-এর জন্য একটি level বেছে নিয়ে সেটি অপরিবর্তিত রাখুন। আর max_tokens হলো thinking এবং response text-সহ মোট output-এর hard cap। তাই thinking ছাড়া উত্তরের জন্য নির্ধারিত cap ব্যবহার করলে output truncated হবে। 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 হলো arithmetic, benchmark নয়। 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 ধারণ করতেই পারে না।

সিদ্ধান্ত নেওয়ার জন্য cost per token সঠিক unit নয়। Cost per completed task হলো প্রতি 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 এড়ায় যেটি পরে আপনাকে সংশোধন করতে হতো, তাহলে saving-এর হিসাব bill-এ না থাকলেও এটি ইতিমধ্যে নিজের খরচ তুলে নিয়েছে। তুলনাটি accepted resultপ্রতি অর্থমূল্যে করুন এবং মোট খরচে আপনার নিজের সময়ও অন্তর্ভুক্ত করুন। এক মিলিয়ন token আসলে কী দেয় তা জানা এই estimate-কে অনেক কম বিমূর্ত করে।

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

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

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

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

যে 3টি কাজে Sonnet 5 বা Haiku 4.5 ব্যবহার করাই বাস্তবসম্মত সিদ্ধান্ত

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

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

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

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

fable-method repository-গুলো কী দেখায় এবং কী দেখায় না

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

এটিকে ঠিক সেইভাবেই বিবেচনা করুন। এটি দেখায় মানুষ কীভাবে model-কে পরিচালনা করছে। এটি model কীভাবে কাজ করে তার documentation নয়। এর কোনো বিষয় Anthropic validate করেনি। একই ধরনের wording-সহ একাধিক প্রায় অভিন্ন fork-ও আছে। এটি কোনো specification-এর বদলে প্রচলিত অভিজ্ঞতা থেকে তৈরি হওয়ার সঙ্গেই বেশি সামঞ্জস্যপূর্ণ।

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

কমিট করার আগে নিজের খরচের হিসাব যাচাই করুন

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

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

FAQ

Claude Fable 5-এর প্রতি million token-এর খরচ কত?

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

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

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

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

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

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

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