দ্বারা Matt Connor 2026-10-27 · আপডেট করা হয়েছে 2026-10-30

Claude-এ input বনাম output token-এর খরচের পার্থক্য

Q: নিজের input-to-output token ratio কীভাবে বের করব?

প্রতিটি response-এর usage object থেকে input_tokens, output_tokens, cache_read_input_tokens এবং cache_creation_input_tokens log করুন। এরপর এক সপ্তাহের মোট মান ভাগ করুন। Input-to-output অনুপাত 5 to 1-এর বেশি হলে আপনার খরচ prompt-এ বেশি হচ্ছে। তাই স্থিতিশীল অংশ cache করুন এবং বাকি অংশ সংক্ষিপ্ত করুন। এর চেয়ে কম হলে খরচ reply-এ বেশি হচ্ছে। তাই reply-এর দৈর্ঘ্য সীমিত করুন এবং যেসব ধাপ সবচেয়ে বেশি output তৈরি করে, সেগুলো কম খরচের model বা Batch API-তে স্থানান্তর করুন।

Claude-এ output token-এর দাম input-এর পাঁচ গুণ। prefill ও decoding-এর পার্থক্য, এবং agent-এর মাসিক bill-এ workload-এর প্রভাব হিসাবসহ দেখুন।

Output token-এর খরচ input token-এর চেয়ে বেশি কেন

বর্তমান catalogue-এ Claude-এর প্রতিটি model-এ output token-এর খরচ input token-এর খরচের পাঁচ গুণ। এর কারণ computation-এর ধরন। Prompt পড়তে model-এর ওপর একবার pass চলে। Reply লিখতে প্রতি token-এর জন্য একবার করে pass চলে, এবং প্রতিটি pass-কে আগের pass শেষ হওয়া পর্যন্ত অপেক্ষা করতে হয়।

Price list-এর প্রতিটি row-তে এই অনুপাত একই। তাই কোন model বেছে নিলেন, তা আপনার bill-এর output অংশের পরিমাণ পরিবর্তন করে না। এটি নির্ধারিত হয় আপনার workload-এর ধরন দিয়ে। একটি agent step 60,000 token পড়ে 800 token-এ উত্তর দিলে output-এর জন্য প্রায় কোনো খরচ হয় না। একটি drafting job 2,000 token পড়ে 12,000 token লিখলে input-এর জন্য প্রায় কোনো খরচ হয় না। নিচে উভয় ক্ষেত্রেই Anthropic-এর প্রকাশিত rate ব্যবহার করে হিসাব করা হয়েছে; যাচাই করা হয়েছে 27 October 2026-এ।

Prefill একবার চলে, decoding প্রতিটি token-এর জন্য একবার চলে

একটি inference server একটি request দুইটি পর্যায়ে পরিচালনা করে। এই দুই পর্যায়ের খরচের ধরন অনেক আলাদা। Prefill prompt পড়ে। Decoding reply লিখে।

Prefill একবারে পুরো prompt প্রক্রিয়া করে। একই forward pass-এ prompt-এর প্রতিটি token network-এ প্রবেশ করে। ফলে attention এবং feed-forward কাজ হাজার হাজার token একসঙ্গে নিয়ে অল্পসংখ্যক বড় matrix multiplication-এ সম্পন্ন হয়। Memory থেকে model weights একবার পড়েই পুরো prompt প্রক্রিয়া করা যায়। Accelerator-এর matrix unit-গুলো ব্যস্ত থাকে। তাই prefill সাধারণত compute-bound হয়। সীমা নির্ধারণ করে chip কত দ্রুত গুণ করতে পারে। NVIDIA-এর serving documentation দুটি ব্যতিক্রম উল্লেখ করে: খুব ছোট prefill এবং এমন prefill যেখানে দীর্ঘ prefix আগে থেকেই cache hit হয়েছে। এগুলো memory-bound হয়ে যায়।

সাধারণ decoding এভাবে কাজ করতে পারে না, কারণ token 2, token 1-এর ওপর নির্ভর করে। Model যে token সদ্য তৈরি করেছে, সেটিই পরের ধাপের input-এর অংশ হয়ে যায়। তাই ধাপগুলো একটির পর একটি চলে। প্রতিটি output token-এর জন্য আলাদা forward pass হয়। প্রতিটি pass-এ একক token তৈরি করতে model weights-এর পুরো সেট এবং KV cache (key/value cache; এখন পর্যন্ত প্রতিটি token-এর জন্য সংরক্ষিত attention state) high-bandwidth memory থেকে পড়তে হয়। তাই decoding সাধারণত memory-bound হয়। সীমা নির্ধারণ করে weights এবং cached state কত দ্রুত সরানো যায়, সেগুলো কত দ্রুত গুণ করা যায় তা নয়। দীর্ঘ context-এর ক্ষেত্রে NVIDIA বিশেষভাবে KV cache পড়ার কাজকে bottleneck হিসেবে উল্লেখ করে। Prefill-এ যে একই weight traffic দিয়ে পুরো prompt প্রক্রিয়া করা হয়, decoding-এ তা দিয়ে মাত্র একটি token তৈরি হয়।

Speculative decoding এই নিয়ম পরিবর্তন করে, তবে পুরোপুরি ভাঙে না। একটি ছোট draft model সামনের কয়েকটি token অনুমান করে। বড় model একটি pass-এ parallelভাবে সব অনুমান যাচাই করে। NVIDIA-এর মতে, এতে decode-এর কাজ compute-bound-এর দিকে যেতে পারে। বড় model এখনও অনুমানগুলো ক্রমানুসারে গ্রহণ করে এবং প্রথম ভুল অনুমানে থেমে যায়। তাই দীর্ঘ reply-এর জন্য এখনও অনেক pass প্রয়োজন হয়।

Serving system-গুলো batching ব্যবহার করে এই সীমাবদ্ধতা কমায়। অনেক request একসঙ্গে decode হয়। ফলে weights একবার পড়ে batch-এর প্রতিটি request-এর জন্য একটি করে token তৈরি করা যায়। Decoding মোটামুটি সাশ্রয়ী হওয়ার কারণ এটাই। আবার সীমা memory-তেই ফিরে আসে। In-flight প্রতিটি request নিজের KV cache ধরে রাখে। তৈরি হওয়া প্রতিটি token-এর সঙ্গে সেই cache বড় হয়। Accelerator পূর্ণ হয়ে গেলে batch আর বড় করা যায় না।

এসব থেকে কোনো নির্ভুল সংখ্যা পাওয়া যায় না। 5x-কে measured hardware ratio হিসেবেও দেখা উচিত নয়। এটি Anthropic নির্ধারিত একটি মূল্য, যা এই অসমতার ভিত্তিতে নির্ধারিত। আপনি নিজে যে বিষয়টি যাচাই করতে পারেন, তা হলো প্রবণতার দিক। এতে প্রায় এক মিনিট সময় লাগে।

নিজে input ও output gap পরিমাপ করুন

যেকোনো Ubuntu কম্পিউটারে টুলগুলো ইনস্টল করুন:

sudo apt update && sudo apt install -y curl jq moreutils

এখন এমন একটি সংক্ষিপ্ত prompt stream করুন, যেখানে দীর্ঘ উত্তরের অনুরোধ থাকবে। প্রতিটি লাইনে সেটি আসার সময় যোগ করুন।

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s প্রতিটি লাইনের শুরুতে command শুরু হওয়ার পর থেকে পার হওয়া সেকেন্ডের সংখ্যা যোগ করে। ওই output থেকে দুটি বিষয় দেখা গুরুত্বপূর্ণ। প্রথম content_block_delta line-টি হলো আপনার first token পেতে সময়, এবং পুরো prefill এই সময়ের মধ্যেই হয়েছে। এরপরের প্রতিটি line decoding-এর একটি ছোট ধাপ। message_stop আসা পর্যন্ত timestamp ক্রমেই বাড়তে থাকে।

এবার চিত্রটি উল্টে দিন। prompt-এ একটি দীর্ঘ document দিন এবং answer কয়েকটি token-এ সীমাবদ্ধ করুন।

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

প্রথম delta-টি সংক্ষিপ্ত prompt-এর তুলনায় বেশি সময় নেয়, কারণ prefill-কে পড়তে অনেক বেশি text হয়। এটি আসার পর response প্রায় সঙ্গে সঙ্গেই শেষ হয়, কারণ decode করার জন্য মাত্র কয়েকটি token বাকি থাকে। কয়েক দশ হাজার token input হিসেবে গেছে, কিন্তু clock প্রায় এগোয়নি। কয়েক শত token output হিসেবে এসেছে, কিন্তু clock পুরো সময় চলেছে।

প্রতিটি non-streaming response শেষে billing-এর জন্য ব্যবহৃত সংখ্যাগুলো থাকে।

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

প্রতিটি request-এর জন্য চারটি field-ই log করুন। output_tokens-এর মধ্যে thinking token-ও থাকে। তাই কোনো model উত্তর দেওয়ার আগে চিন্তা করলে, সেই thinking output rate-এ bill হয়। পাঠানোর আগে কোনো prompt-এর মূল্য নির্ধারণ করতে POST /v1/messages/count_tokens অধিকাংশ request-এর ক্ষেত্রে একই request body গ্রহণ করে, model চালানো ছাড়াই {"input_tokens": N} হিসেবে একটি estimate ফেরত দেয় এবং নিজস্ব rate limit-এর মধ্যে এটি free। Messages API যে কয়েকটি body গ্রহণ করে, এটি সেগুলোর কিছু প্রত্যাখ্যান করে: web search, MCP connector-এর মতো অধিকাংশ server tool, এবং url বা file source-সহ image বা document block। তাই এগুলো গণনা করার সময় image ও PDF-কে base64 হিসেবে পাঠান। API-এর একমাত্র বিনামূল্যের অংশ এটি নয়। প্রথম project-এর budget নির্ধারণের আগে Claude API-এর কোন কোন অংশের জন্য আপনাকে কখনো bill করা হয় না দেখে নেওয়া উপযোগী।

অক্টোবর 2026 অনুযায়ী প্রতি মিলিয়ন token-এ Claude-এর মূল্য

চার্টClaude API list rates, US dollars per million tokens, October 2026

label

input_usd

output_usd

output_multiple

Haiku 4.5

Sonnet 5

Opus 5

Fable 5

এই চার্টের পেছনের ডেটা

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

শেষ column-টি output-কে input দিয়ে ভাগ করা ফল, এবং প্রতিটি row-তে এটি 5 হিসেবে দেখানো হয়েছে। Haiku 4.5-এর ক্ষেত্রে input-এর জন্য $1 এবং output-এর জন্য $5 দিতে হয়। Opus 5-এর ক্ষেত্রে মূল্য $5 এবং $25। সবচেয়ে ব্যয়বহুল Fable 5-এর মূল্য $10 এবং $50; তাই সেটিকে সর্বোচ্চ row হিসেবে বাদ দেওয়ার আগে Fable 5-এর এই মূল্য আপনাকে কী সুবিধা দেয় তা পড়ে নেওয়া ভালো। এই range-এ উপরের দিকে গেলে উভয় দিক একই অনুপাতে বাড়ে। তাই মোট খরচ বদলালেও input ও output-এর অনুপাত অপরিবর্তিত থাকে।

Sonnet 5-এর input-এর মূল্য $2 এবং output-এর মূল্য $10। Anthropic 31 August 2026 পর্যন্ত introductory pricing হিসেবে এই মূল্য চালু করেছিল। 1 September-এ মূল্য $3 এবং $15-এ বাড়ানোর পরিকল্পনা ছিল। পরে standard price হিসেবে $2 এবং $10 নির্ধারণ করা হয়। মূল্যবৃদ্ধি কার্যকর হয়নি। তাই নিচের প্রতিটি worked example-এ আজকের প্রযোজ্য মূল্য ব্যবহার করা হয়েছে।

এই page প্রথম প্রকাশের পর Anthropic আরও নতুন model release করেছে। এখন claude.com/pricing-এ উপরের চারটি model-কে available থাকা legacy model হিসেবে দেখানো হয়। নতুন model-গুলোতেও একই 5x ratio রয়েছে। Opus 5.5-এর মূল্য $4 এবং $20, Sonnet 5.5-এর $2 এবং $10, Fable 5.1-এর $10 এবং $50। Haiku 5.5-এর ক্ষেত্রে 100,000 token পর্যন্ত মূল্য $0.10 এবং $0.50। এর বেশি হলে মূল্য $0.50 এবং $2.50। নিচে হিসাব করা 60,000 token-এর agent step এই সীমার নিচে পড়ে। তবে agent-এর history ক্রমাগত বড় হলে একসময় এই সীমা অতিক্রম করবে। বাস্তব কাজের ক্ষেত্রে Haiku 5.5-এর দুইটি price tier কীভাবে প্রযোজ্য হয় দেখায়, এই পরিবর্তনে bill কতটা বাড়ে। Opus 5.5-এর base input ও output rate, Opus 5-এর তুলনায় 20% কম। তাই নিচে দেওয়া প্রতিটি uncached Opus 5 figure, Opus 5.5-এ 20% কম হবে। Cached figure আরও কম হবে। কারণ Opus 5.5 cache hit পড়ার জন্য প্রতি মিলিয়ন token-এ $0.20 নেয়, যেখানে Opus 5-এ মূল্য $0.50। এটি 60% কম। নিচে Opus 5-এ যে cached agent step-এর খরচ $0.0725, Opus 5.5-এ তার খরচ প্রায় $0.047, অর্থাৎ প্রায় 35% কম।

মূল্য পরিবর্তিত হতে পারে। তাই মূল্য যাচাই করার জন্য এই page ব্যবহার করবেন না। claude.com/pricing হলো নির্ভরযোগ্য source। মূল্য পরিবর্তনের পরও হিসাবের পদ্ধতিটি অপরিবর্তিত থাকে।

একটি গুরুত্বপূর্ণ সতর্কতা Anthropic-এর price table-এর rates অংশে নয়, তার নিচের notes-এ আছে। Anthropic-এর pricing page অনুযায়ী Claude 4.7 এবং পরবর্তী model-গুলো নতুন tokenizer ব্যবহার করে। একই text-এর জন্য এই tokenizer Sonnet 4.6 এবং আগের model-গুলোর tokenizer-এর তুলনায় প্রায় 30% বেশি token তৈরি করে। শুধু প্রতি মিলিয়ন token-এর মূল্য তুলনা করলে নতুন model-টি বেশি সাশ্রয়ী বলে মনে হতে পারে। কারণ একই document-এ সেটি বেশি token গণনা করে। তাই finished task-এর খরচ তুলনা করুন। আপনি যে model ব্যবহার করবেন, তার বিরুদ্ধে আপনার প্রকৃত prompt-এর token count হিসাব করুন। Provider-গুলোর মধ্যেও একই সমস্যা আছে। তাদের tokenizer-ও একে অপরের থেকে আলাদা। তাই Claude এবং ChatGPT-তে একটি বাস্তব কাজের খরচ হিসাব করা দুইটি rate card পাশাপাশি রাখার চেয়ে বেশি তথ্য দেয়। বাস্তব text-এ এক মিলিয়ন Claude token-এর মূল্য কত এই পরিমাণ token বাস্তবে কেমন দেখায় তা ব্যাখ্যা করে।

আপনার বিলের প্রধান অংশ আউটপুট কখন হয়ে যায়?

ইনপুটের তুলনায় আউটপুটের মূল্য 5 গুণ হলে break-even হিসাবটি সহজেই মনে রাখা যায়। আপনার input token-কে I এবং output token-কে O ধরুন। ইনপুটের খরচ I। আউটপুটের খরচ O-এর 5 গুণ। 5 গুণ O, I-এর চেয়ে বড় হলেই আপনার মোট খরচের অর্ধেকের বেশি আউটপুটের জন্য যায়। এর token ratio হলো 5 input-এর বিপরীতে 1 output।

তাই আপনার prompt যদি reply-এর চেয়ে পাঁচ গুণেরও বেশি দীর্ঘ হয়, তাহলে খরচের বড় অংশ input-এর। এর নিচে হলে বড় অংশ output-এর।

চার্টShare of spend by input to output token ratio, at 5x output pricing

label

input_share_pct

output_share_pct

100:1

95.2

4.8

75:1

93.75

6.25

20:1

10:1

66.7

33.3

5:1

1:1

16.7

83.3

1:6

3.2

96.8

এই চার্টের পেছনের ডেটা

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

100 to 1 অনুপাতে আউটপুট মোট খরচের 4.8%, তাই prompt ছোট করাই একমাত্র কাজ, যা করা সার্থক। 5 to 1 অনুপাতে দুই দিকের খরচ সমান। 1 to 6 অনুপাতে আউটপুটের অংশ 96.8%, আর prompt-এর খরচ প্রায় উপেক্ষণীয়। অধিকাংশ মানুষ নিজেদের ratio ভুল অনুমান করে। তাই optimization করার আগে আপনার log থেকে প্রকৃত ratio বের করুন।

একটি agent workload: দীর্ঘ context, সংক্ষিপ্ত উত্তর

একটি retrieval agent step নিন: retrieved document এবং conversation history থেকে 60,000 input tokens, এবং 800 token-এর একটি উত্তর। অনুপাতটি 75 to 1। যে কোনো সিস্টেমের জন্য এটি স্বাভাবিক, যেখানে লেখার আগে পড়া হয়।

চার্টOne agent step, 60,000 input and 800 output tokens, US dollars per call

label

input_cost

output_cost

total_cost

Haiku 4.5

0.06

0.004

0.064

Sonnet 5

0.12

0.008

0.128

Opus 5

0.3

0.02

0.32

Fable 5

0.6

0.04

0.64

এই চার্টের পেছনের ডেটা

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

প্রতিটি model-এ এই call-এর 6.25% হলো output, কারণ পুরো price list জুড়ে অনুপাতটি অপরিবর্তিত। এই call-এর খরচ Opus 5-এ $0.32, Sonnet 5-এ $0.128, এবং Haiku 4.5-এ $0.064। Opus 5-এ প্রতিদিন এ ধরনের 200টি step-এর খরচ প্রতিদিন $64।

বিভাজনটি দেখলেই কোন দিকটিতে কাজ করা উচিত তা স্পষ্ট হয়। উত্তর 800 tokens থেকে 400 tokens-এ কমালে call-এর খরচ প্রায় 3% কমে। Prompt থেকে 20,000 tokens-এর পুরোনো context বাদ দিলে খরচ প্রায় এক-তৃতীয়াংশ কমে। Read-heavy agent-এ output length কমানোর চেষ্টা প্রায় অপচয়। coding agent-এর tokens আসলে কোথায় যায় prompt-এ প্রথমে কী কী যোগ হয়, তা বিশ্লেষণ করে।

একটি generation workload: সংক্ষিপ্ত prompt, দীর্ঘ draft

এবার অনুপাতটি উল্টে দেখুন। 2,000 token-এর brief এবং 12,000 token-এর draft; অনুপাত 1 থেকে 6।

চার্টOne draft, 2,000 input and 12,000 output tokens, US dollars per draft

label

input_cost

output_cost

total_cost

batch_total_cost

Haiku 4.5

0.002

0.06

0.062

0.031

Sonnet 5

0.004

0.12

0.124

0.062

Opus 5

0.01

0.3

0.31

0.155

Fable 5

0.02

0.6

0.62

0.31

এই চার্টের পেছনের ডেটা

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

এই bill-এর 96.8% হলো output। Haiku 4.5-এ প্রতি draft-এর খরচ $0.062, যেখানে Opus 5-এ খরচ $0.31। এই পাঁচ গুণ পার্থক্য প্রায় সম্পূর্ণভাবে output অংশ থেকে আসে। আর সস্তা model আপনাকে সবচেয়ে বেশি সাশ্রয় দেয় ঠিক এখানেই।

শেষের column-এ একই কাজ Batch API-এর মাধ্যমে দেখানো হয়েছে, যেখানে input ও output—উভয় ক্ষেত্রেই 50% ছাড় পাওয়া যায়। Opus 5-এ প্রতি draft-এর খরচ কমে হয় $0.155। Batch তাৎক্ষণিক নয়; এটি asynchronous। Anthropic বলছে, অধিকাংশ batch এক ঘণ্টার মধ্যে সম্পন্ন হয়। তবে 24 ঘণ্টা পরও processing চললে batch-টির মেয়াদ শেষ হয়ে যায়। ততক্ষণে যেসব request প্রক্রিয়ায় পৌঁছায়নি, সেগুলোও expired হিসেবে ফেরত আসে; সেগুলোর জন্য bill করা হয় না এবং কোনো message-ও থাকে না। তাই overnight report generation এবং bulk classification-এর জন্য এটি উপযোগী। তবে মেয়াদ শেষ হওয়া request-এর জন্য resubmit করতে হবে। যে কাজের ফলাফলের জন্য কোনো ব্যক্তি বসে অপেক্ষা করছেন, তার জন্য এটি উপযোগী নয়।

Agent ধাপে routing যে সুবিধা দেয় না, এখানে model routing সেই সুবিধা দেয়। কাজের verbose অংশ যদি যান্ত্রিক হয়—যেমন text reformat করা বা ইতিমধ্যে অনুমোদিত outline বিস্তৃত করা—তাহলে সস্তা model এক-পঞ্চমাংশ খরচে সেই token তৈরি করে। Opus, Sonnet এবং Haiku-এর মধ্যে নির্বাচন অংশে quality-এর সীমাটি বাস্তবে কোথায় রয়েছে তা ব্যাখ্যা করা হয়েছে।

Caching কেবল input-এর খরচ কমায়

Prompt caching আপনার prompt-এর একটি prefix server-এ সংরক্ষণ করে। পরে সেটি আবার পড়ার জন্য input rate-এর একটি অংশ নেওয়া হয়। 27 October 2026 অনুযায়ী, এই page-এ দামের মডেলগুলোর ক্ষেত্রে 5 minute cache লিখতে base input rate-এর 1.25x, 1 hour cache লিখতে 2x এবং cache hit পড়তে 0.1x multiplier প্রযোজ্য। নতুন মডেলগুলোতে cache hit পড়ার খরচ আরও কম: Opus 5.5 এবং Sonnet 5.5-এ 0.05x, আর Fable 5.1-এ 0.025x।

Output এই সুবিধার অন্তর্ভুক্ত নয়। Cached output বলে কিছু নেই। Model যত token লিখবে, প্রতিবারই পুরো output rate অনুযায়ী তার billing হবে। Prompt-এর যত অংশই cache hit হিসেবে ফিরে আসুক, এতে output-এর খরচ বদলাবে না।

Opus 5-এ একই agent step নিন, যেখানে 60,000 input token-এর মধ্যে 55,000টি warm cache থেকে পরিবেশিত হয়েছে।

চার্টThe same Opus 5 agent step, with and without a warm 55,000 token cache, US dollars

label

input_cost

output_cost

total_cost

No cache

0.3

0.02

0.32

55k prefix cache read

0.0525

0.02

0.0725

এই চার্টের পেছনের ডেটা

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

Call-এর খরচ $0.32 থেকে কমে $0.0725 হয়। Output-এর খরচ বদলায় না: আগে $0.02, পরে $0.02। Caching মোট bill কমায় এবং bill-এর গঠনও পরিবর্তন করে। এই call-এ Output ছিল মোট খরচের 6.25%। এখন এটি মোট খরচের এক-চতুর্থাংশের বেশি, তাই পরবর্তী কোন খরচের উপাদান কমানো সবচেয়ে কার্যকর হবে, তা বদলে যায়।

প্রথম call-এ cache write-এর খরচ দিতে হয়। 5 minute cache লিখতে base input-এর 1.25x খরচ হয়, তাই একটি hit হলেই সেই খরচ উঠে আসে। 1 hour cache লিখতে 2x খরচ হয়, তাই এর জন্য দুইটি hit দরকার। write ও read multiplier এবং caching কখন আর সাশ্রয়ী থাকে না-এ এই হিসাবটি বিস্তারিত দেখানো হয়েছে।

আপনার নিয়ন্ত্রণে থাকা চারটি উপায়

max_tokens মডেলের সর্বোচ্চ সীমায় নয়, আপনার p95 output length অনুযায়ী নির্ধারণ করুন।
বেশি output তৈরি করা ধাপগুলো কম খরচের মডেলে পাঠান।
যে কাজের জন্য কেউ অপেক্ষা করছে না, সেগুলো batch করুন।
যে নির্দেশনাগুলো উত্তর বড় করে, সেগুলো বাদ দিন।

max_tokens একটি কঠোর সর্বোচ্চ সীমা। এটি বেশি নির্ধারণ করলেই আলাদা খরচ হয় না, কারণ আপনার কাছ থেকে তৈরি হওয়া token-এর জন্যই বিল নেওয়া হয়; ceiling-এর জন্য কখনো নয়। উদার cap যা করে, তা হলো ভুল পথে যাওয়া কোনো উত্তরের ওপর থাকা সীমা সরিয়ে দেয়। আপনার log থেকে output_tokens distribution বের করুন, cap-টি 95th percentile-এর সামান্য ওপরে রাখুন, এবং code-এ stop_reason: "max_tokens" সামলান—উত্তর চালিয়ে যান অথবা retry করুন। শনাক্ত করা truncation-এর খরচ আপনি যে 4,000 token-এর অপ্রয়োজনীয় দীর্ঘ উত্তর তৈরি করে বাতিল করেন, তার চেয়ে কম। Thinking-ও output_tokens-এ যায় এবং max_tokens-এর বিপরীতে গণনা হয়। তাই একই প্রমাণের ভিত্তিতে cap নির্ধারণ করুন। Adaptive thinking-সমর্থিত মডেলে thinking যদি বারবার উত্তরের জায়গা দখল করে, effort level কমিয়ে দিন।

কোনো ধাপের ব্যয়বহুল অংশ যদি বিচার নয়, volume হয়, তাহলে routing কার্যকর হয়। সিদ্ধান্তের জন্য শক্তিশালী মডেলটি রাখুন, আর লেখার কাজ কম খরচের মডেলে দিন। প্রথমে নিজের evaluation set-এ routed version মাপুন, কারণ গুরুত্বপূর্ণ পরিমাপ হলো প্রতি সম্পূর্ণ task-এর খরচ। উপরের agent ধাপে, দুটি Haiku 4.5 attempt-এর খরচ $0.128, যেখানে একটি Opus 5 attempt-এর খরচ $0.32। তাই এই দামের পার্থক্য এক বা দুটি retry-এর খরচ মেটাতে পারে। তবে এটি এমন ভুল উত্তর সামলাতে পারে না, যা কেউ শনাক্ত করে না।

Batching-ই একমাত্র উপায় যা output-এর ওপর discount দেয়। উভয় দিকেই 50% ছাড় পাওয়া যায়, অধিকাংশ batch এক ঘণ্টার মধ্যে সম্পন্ন হয়, এবং schedule-এ থাকা কাজও এর আওতায় পড়ে—তবে job-কে 24 hour সীমায় expire হওয়া কাজগুলো আবার submit করতে হবে।

শেষ উপায়টি মানুষ প্রায়ই এড়িয়ে যায়। "be thorough" এবং "explain your reasoning"-এর মতো phrase আপনার প্রতিটি call-এর output length নির্ধারণ করে। এগুলোর বদলে আপনার পছন্দের কাঠামো নির্দিষ্ট করুন: "Answer in at most three sentences", অথবা "Return only the JSON object, with no preamble"। প্রতি উত্তরে 300 token যোগ করে এমন একটি system prompt-এর খরচ prompt-এ একই 300 token থাকার খরচের পাঁচ গুণ। চলমান agent-এর খরচ নিয়ন্ত্রণে রাখা monitoring-এর দিকটি ব্যাখ্যা করে, আর আপনার ব্যবহারের ধরন অনুযায়ী API নাকি flat subscription সস্তা—সেটি আগে নির্ধারণ করা ভালো; এতে subscription যে per-token খরচ মিটিয়ে দিত, তা কমাতে এক সপ্তাহ ব্যয় করে tuning করতে হয় না। একজন developer-এর ক্ষেত্রে বিষয়টি মূলত নির্ভর করে Claude Pro-এর মাসিক $20 এবং এর সঙ্গে থাকা usage limit আপনি যে কাজের জন্য অন্যথায় metering করতেন, তা সামলাতে পারে কি না। আপনি যদি ইতিমধ্যেই session-এর মাঝামাঝি ওই limit-এ পৌঁছে যান, তাহলে প্রথমে কোন window-এর জন্য আপনি অপেক্ষা করছেন তা নির্ধারণ করা দরকার। এরপর সমাধান হতে পারে ছোট মডেল ব্যবহার করা, context হালকা করা, অতিরিক্ত usage credit নেওয়া, অথবা কাজটি metered API-তে সরিয়ে নেওয়া। Metered API যদি ওই কাজের জন্য সস্তা বিকল্প হয়, তাহলে ছোট plan-এ নামা বা plan বাতিল করা—আপনি যে মাসের জন্য ইতিমধ্যে অর্থ দিয়েছেন, সেটি অক্ষত রাখে। তাই পরিবর্তন করতে অতিরিক্ত কোনো খরচ হয় না। আপনি যদি metered API-এর বদলে ChatGPT-এর plan-এর সঙ্গে Pro-এর তুলনা করেন, তাহলে পাশাপাশি দেখানো দুই subscription tier-এর দাম coding কাজের জন্য কোনটি সস্তা তা দেখায়। এই প্রশ্নটি যদি একজন developer-এর বদলে কোনো team-এর জন্য হয়, মনে রাখুন যে Claude Enterprise প্রতি seat fee-এর সঙ্গে একই API rate-এ metered token যুক্ত করে। তাই এই পৃষ্ঠার প্রতিটি উপায় ওই bill-এর metered অংশের ক্ষেত্রেও প্রযোজ্য।

FAQ

Output token-এর খরচ input token-এর চেয়ে বেশি কেন?

এগুলো তৈরি করতে প্রতি token-এ accelerator-এর সময় অনেক বেশি লাগে। Prompt পুরোটা নিয়ে একবারে forward pass চালিয়ে প্রক্রিয়া করা হয়। তাই model weights একবার পড়েই হাজার হাজার token কভার করা যায়, এবং hardware সাধারণত multiply throughput দ্বারা সীমাবদ্ধ থাকে। সাধারণ decoding-এ reply একবারে একটি token করে তৈরি হয়। প্রতিটি token-এর জন্য আলাদা forward pass চালাতে হয়, যেখানে model weights এবং ক্রমশ বড় হওয়া KV cache আবার পড়তে হয়। তাই hardware সাধারণত memory bandwidth দ্বারা সীমাবদ্ধ থাকে। Speculative decoding-এর মতো কৌশল এই ব্যবধান কমায়, কিন্তু পুরোপুরি দূর করে না। Haiku 5.5 থেকে Fable 5.1 পর্যন্ত বর্তমান সম্পূর্ণ catalogue-এ Anthropic output-এর দাম input-এর 5 গুণ নির্ধারণ করেছে।

Prompt caching কি output token-এর খরচ কমায়?

না। Prompt caching শুধু input-এর ক্ষেত্রে প্রযোজ্য। 27 October 2026 অনুযায়ী অধিকাংশ model-এ cache read-এর খরচ base input rate-এর 0.1x। Opus 5.5 এবং Sonnet 5.5-এ এটি 0.05x, আর Fable 5.1-এ 0.025x। 5 minute duration-এর জন্য cache write-এর খরচ 1.25x এবং 1 hour duration-এর জন্য 2x। Cache যা-ই করুক, প্রতিটি call-এ output-এর জন্য full rate নেওয়া হয়। তাই caching আপনার bill-এর আকারের পাশাপাশি তার বিন্যাসও বদলে দেয়। Input-এর খরচ কমে গেলে output-ই এমন অংশ হয়ে ওঠে, যেটি কমানো সবচেয়ে বেশি সাশ্রয়ী।

উচ্চ `max_tokens` থাকলেও reply ছোট হলে কি আমাকে টাকা দিতে হবে?

না। Model বাস্তবে যত token তৈরি করে, আপনাকে তার জন্যই bill করা হয়। তাই max_tokens হলো সর্বোচ্চ সীমা, কোনো পূর্বনির্ধারিত বরাদ্দ নয়। তবু এটি গুরুত্বপূর্ণ, কারণ নিয়ন্ত্রণের বাইরে চলে যাওয়া reply-এর একমাত্র কঠোর সীমা এটিই। আপনার পর্যবেক্ষণ করা output_tokens-এর 95th percentile-এর সামান্য ওপরে এটি নির্ধারণ করুন। এরপর নীরবে কেটে যাওয়া answer পাঠানোর বদলে code-এ stop_reason: "max_tokens" পরিচালনা করুন।

নিজের input-to-output token ratio কীভাবে বের করব?

প্রতিটি response-এর usage object থেকে input_tokens, output_tokens, cache_read_input_tokens এবং cache_creation_input_tokens log করুন। এরপর এক সপ্তাহের মোট মান ভাগ করুন। Input-to-output অনুপাত 5 to 1-এর বেশি হলে আপনার খরচ prompt-এ বেশি হচ্ছে। তাই স্থিতিশীল অংশ cache করুন এবং বাকি অংশ সংক্ষিপ্ত করুন। এর চেয়ে কম হলে খরচ reply-এ বেশি হচ্ছে। তাই reply-এর দৈর্ঘ্য সীমিত করুন এবং যেসব ধাপ সবচেয়ে বেশি output তৈরি করে, সেগুলো কম খরচের model বা Batch API-তে স্থানান্তর করুন।

এই লেখাটি কি কাজে লেগেছে?

#claude #pricing #tokens #api #cost-control

Output token-এর খরচ input token-এর চেয়ে বেশি কেন

Prefill একবার চলে, decoding প্রতিটি token-এর জন্য একবার চলে

নিজে input ও output gap পরিমাপ করুন

অক্টোবর 2026 অনুযায়ী প্রতি মিলিয়ন token-এ Claude-এর মূল্য

আপনার বিলের প্রধান অংশ আউটপুট কখন হয়ে যায়?

একটি agent workload: দীর্ঘ context, সংক্ষিপ্ত উত্তর

একটি generation workload: সংক্ষিপ্ত prompt, দীর্ঘ draft

Caching কেবল input-এর খরচ কমায়

আপনার নিয়ন্ত্রণে থাকা চারটি উপায়

FAQ

Output token-এর খরচ input token-এর চেয়ে বেশি কেন?

Prompt caching কি output token-এর খরচ কমায়?

উচ্চ max_tokens থাকলেও reply ছোট হলে কি আমাকে টাকা দিতে হবে?

নিজের input-to-output token ratio কীভাবে বের করব?

এই লেখাটি কি কাজে লেগেছে?

উচ্চ `max_tokens` থাকলেও reply ছোট হলে কি আমাকে টাকা দিতে হবে?