দ্বারা Matt Connor 2026-08-04 · আপডেট করা হয়েছে 2026-08-07

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-এর বেশি হলে আপনার খরচ মূলত prompt-এ হচ্ছে। তাই স্থিতিশীল অংশ cache করুন এবং বাকি অংশ সংক্ষিপ্ত করুন। অনুপাত এর চেয়ে কম হলে আপনার খরচ মূলত reply-এ হচ্ছে। তাই reply-এর দৈর্ঘ্য সীমিত করুন এবং যেসব ধাপে সবচেয়ে বেশি output তৈরি হয়, সেগুলো কম খরচের model বা Batch API-তে স্থানান্তর করুন।

Claude-এ output token-এর দাম input-এর 5 গুণ। Prefill ও decoding-এর গতি কেন আলাদা এবং এই অনুপাত agent-এর মাসিক bill-এ কী প্রভাব ফেলে, তা জানুন।

ইনপুট টোকেনের তুলনায় আউটপুট টোকেনের খরচ বেশি কেন

বর্তমান catalogue-এর প্রতিটি Claude model-এ আউটপুট টোকেনের খরচ ইনপুট টোকেনের খরচের পাঁচ গুণ। এর কারণ 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 প্রকাশিত August 2026-এর rates অনুযায়ী নিচে উভয় ক্ষেত্রের হিসাব দেখানো হয়েছে।

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

একটি inference server একটি request-কে ভিন্ন খরচের 2টি ধাপে পরিচালনা করে। Prefill prompt পড়ে। Decoding reply তৈরি করে।

Prefill পুরো prompt একসঙ্গে প্রক্রিয়া করে। একই forward pass-এ prompt-এর প্রতিটি token network-এ প্রবেশ করে। তাই attention এবং feed-forward-এর কাজ একসঙ্গে হাজার হাজার token নিয়ে অল্পসংখ্যক বড় matrix multiplication-এ রূপ নেয়। Model weights একবার memory থেকে পড়লেই পুরো prompt প্রক্রিয়া করা যায়। Accelerator-এর matrix unit-গুলো ব্যস্ত থাকে। তাই prefill compute-bound: সীমা নির্ধারিত হয় chip কত দ্রুত গুণ করতে পারে তার ওপর।

Decoding এভাবে কাজ করতে পারে না, কারণ token 2, token 1-এর ওপর নির্ভর করে। Model সদ্য যে token তৈরি করেছে, সেটিই পরবর্তী ধাপের input-এর অংশ হয়। তাই ধাপগুলো একই সময়ে চালানো যায় না। প্রতিটি output token-এর জন্য আলাদা forward pass চলে। প্রতিটি pass একটি token তৈরি করতে high-bandwidth memory থেকে model weights-এর সম্পূর্ণ সেট পড়ে। তাই decoding memory-bound: সীমা নির্ধারিত হয় weights কত দ্রুত স্থানান্তর করা যায় তার ওপর, কত দ্রুত গুণ করা যায় তার ওপর নয়। Prefill-এর সময় যে একই weight traffic দিয়ে পুরো prompt প্রক্রিয়া করা হয়, decoding-এর সময় তা দিয়ে মাত্র 1টি token তৈরি হয়।

Serving system-গুলো batching ব্যবহার করে এই সীমাবদ্ধতা কমায়। অনেক request একসঙ্গে decode হয়। ফলে weights একবার পড়ে batch-এর প্রতিটি request-এর জন্য 1টি করে token তৈরি করা যায়। Decoding আদৌ ব্যবহারযোগ্য হওয়ার এটিই কারণ। সীমা আবার memory-তেই। In-flight প্রতিটি request একটি KV cache ধরে রাখে (key/value cache, অর্থাৎ এখন পর্যন্ত প্রতিটি token-এর জন্য সংরক্ষিত attention state)। প্রতিটি নতুন token তৈরি হলে এই cache বড় হয়। Cache accelerator-এর memory পূর্ণ করে ফেললে batch আর বড় করা যায় না।

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

নিজেই 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 লাইনটি হলো প্রথম token পাওয়া পর্যন্ত সময়; prefill-এর পুরো অংশ এই সময়ের মধ্যেই সম্পন্ন হয়েছে। এরপরের প্রতিটি লাইন decoding-এর একটি ছোট ধাপ, এবং message_stop আসা পর্যন্ত সময়ের stamp ক্রমশ বাড়তে থাকে।

এবার চিত্রটি উল্টে দিন। prompt-এ একটি দীর্ঘ document দিন এবং উত্তর কয়েকটি 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 বাকি থাকে। Tens of thousands 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-এর মধ্যে extended thinking-ও অন্তর্ভুক্ত থাকে। তাই কোনো model উত্তর দেওয়ার আগে চিন্তা করলে সেই thinking output rate-এ bill হয়। Request পাঠানোর আগে prompt-এর মূল্য নির্ধারণ করতে POST /v1/messages/count_tokens একই request body গ্রহণ করে, model চালানো ছাড়াই {"input_tokens": N} ফেরত দেয়, এবং এটি বিনামূল্যে।

2026 সালের August অনুযায়ী প্রতি million token-এ Claude-এর মূল্য

ChartClaude API list rates, US dollars per million tokens, August 2026

label

input_usd

output_usd

output_multiple

Haiku 4.5

Sonnet 5 (to 31 Aug)

Sonnet 5 (from 1 Sep)

Opus 5

Fable 5

The data behind this chart

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "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
  }
]

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

Sonnet 5 দুইবার দেখা যাচ্ছে, কারণ এর introductory rate-এর মেয়াদ শেষ হয়। 31 August 2026 পর্যন্ত এর input-এর মূল্য $2 এবং output-এর মূল্য $10। 1 September 2026 থেকে $3 input এবং $15 output-এর standard rate প্রযোজ্য হবে। উভয় দিকেই এই মূল্য 50% বেশি। নিচের প্রতিটি worked example-এ August-এর rate ব্যবহার করা হয়েছে।

Rate পরিবর্তিত হয়। তাই rate যাচাই করার জন্য এই page ব্যবহার করবেন না। claude.com/pricing হলো নির্ভরযোগ্য উৎস। মূল্য পরিবর্তনের পরেও যে পদ্ধতিটি কার্যকর থাকে, সেটিই গুরুত্বপূর্ণ।

মূল্যতালিকায় একটি বিষয় দেখানো হয় না। Anthropic-এর documentation অনুযায়ী Claude 4.7 এবং পরবর্তী model-গুলো নতুন tokenizer ব্যবহার করে। এতে Sonnet 4.6 এবং তার আগের model-গুলোর tokenizer-এর তুলনায় একই text-এর জন্য প্রায় 30% বেশি token তৈরি হয়। শুধু প্রতি million token-এর মূল্য তুলনা করলে নতুন model-টি অযথা সুবিধাজনক মনে হবে, কারণ একই document-এ সেটিতে বেশি token লাগে। প্রতিটি সম্পূর্ণ task-এর খরচ দিয়ে তুলনা করুন। আপনি যে model ব্যবহার করার পরিকল্পনা করছেন, তার বিরুদ্ধে আপনার প্রকৃত prompt-এর token গণনা করুন। বাস্তব text-এ এক million Claude token-এর মূল্য-এ এই পরিমাণ token বাস্তবে কতটা text তৈরি করে তা ব্যাখ্যা করা হয়েছে।

আপনার বিলের কতটা অংশ আউটপুট থেকে আসতে শুরু করে?

ইনপুটের তুলনায় আউটপুটের দাম 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 বড় খরচের অংশ।

ChartShare 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

The data behind this chart

[
  {
    "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:1 অনুপাতে output মোট খরচের 4.8% এবং prompt ছোট করাই একমাত্র কার্যকর কাজ। 5:1 অনুপাতে দুই দিকের খরচ সমান। 1:6 অনুপাতে output-এর অংশ 96.8% এবং prompt-এর খরচ rounding error-এর মতো সামান্য। বেশিরভাগ মানুষ নিজেদের ratio ভুল অনুমান করেন। তাই optimization করার আগে আপনার log থেকে অনুপাতটি বের করুন।

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

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

ChartOne 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 (Aug)

0.12

0.008

0.128

Opus 5

0.3

0.02

0.32

Fable 5

0.6

0.04

0.64

The data behind this chart

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "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 জুড়ে অনুপাতটি অপরিবর্তিত। August rate অনুযায়ী Opus 5-এ call-টির খরচ $0.32, Sonnet 5-এ $0.128, এবং Haiku 4.5-এ $0.064। Opus 5-এ প্রতিদিন এমন 200টি step-এর খরচ প্রতিদিন $64।

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

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

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

ChartOne 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 (Aug)

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

The data behind this chart

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "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 তাৎক্ষণিকভাবে নয়, 24 ঘণ্টার মধ্যে ফলাফল দেয়। তাই overnight report generation এবং bulk classification-এর জন্য এটি উপযোগী। তবে এমন কোনো কাজে এটি উপযোগী নয়, যেখানে কেউ বসে ফলাফলের জন্য অপেক্ষা করছে।

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

Caching input-এর খরচ কমায়, শুধু input-এর

Prompt caching আপনার prompt-এর একটি prefix server-এ সংরক্ষণ করে। পরে সেটি আবার পড়ার জন্য input rate-এর একটি অংশ বিল করা হয়। August 2026 অনুযায়ী multiplier হলো 5 minute cache লিখতে base input rate-এর 1.25x, 1 hour cache লিখতে 2x এবং cache hit পড়তে 0.1x।

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

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

ChartThe 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

The data behind this chart

[
  {
    "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 মোট বিল কমায় এবং বিলের গঠনও বদলে দেয়। ওই 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 অনুযায়ী নির্ধারণ করুন।
বেশি verbose ধাপগুলো কম খরচের মডেলে পাঠান।
যেসব কাজের ফলাফলের জন্য কেউ অপেক্ষা করছে না, সেগুলো batch করুন।
যে নির্দেশনাগুলো reply অপ্রয়োজনীয়ভাবে দীর্ঘ করে, সেগুলো বাদ দিন।

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

কোনো ধাপের ব্যয়বহুল অংশ যদি judgement নয়, volume হয়, তাহলে routing কার্যকর হয়। সিদ্ধান্ত নেওয়ার কাজটি শক্তিশালী মডেলের কাছে রাখুন, আর typing-এর কাজ কম খরচের মডেলে দিন। আগে নিজের evaluation set-এ routed version পরিমাপ করুন, কারণ দুইবার চেষ্টা করতে হয় এমন সস্তা মডেলের খরচ একবারের ব্যয়বহুল প্রচেষ্টার চেয়ে বেশি হতে পারে।

Output-এর ওপর discount পাওয়ার একমাত্র উপায় হলো batching। উভয় দিকেই 50% ছাড়, ফলাফল 24 ঘণ্টার মধ্যে, এবং নির্ধারিত schedule-এ চলা যেকোনো কাজ এর আওতায় পড়ে।

শেষের উপায়টি মানুষ প্রায়ই বাদ দেয়। "be thorough" এবং "explain your reasoning"-এর মতো বাক্য আপনি ভবিষ্যতে করা প্রতিটি call-এর output length বাড়ায়। এগুলোর বদলে পছন্দের কাঠামো নির্দিষ্ট করুন: "Answer in at most three sentences", অথবা "Return only the JSON object, with no preamble"। প্রতিটি reply-এ 300 token যোগ করা একটি system prompt-এর খরচ prompt-এ একই 300 token যোগ করার খরচের পাঁচ গুণ। চলমান agent-এর খরচ নিয়ন্ত্রণে রাখা monitoring-এর দিকটি ব্যাখ্যা করে, এবং আপনার ব্যবহারের ধরনে API নাকি flat subscription বেশি সাশ্রয়ী—per-token খরচ কমানোর কাজে এক সপ্তাহ ব্যয় করার আগে এটি নির্ধারণ করা ভালো, কারণ subscription সেই খরচ বহন করতে পারত।

FAQ

আউটপুট token-এর খরচ input token-এর চেয়ে বেশি কেন?

প্রতি token তৈরি করতে accelerator-এর অনেক বেশি সময় লাগে। Prompt একবারে পুরোটা নিয়ে একটি forward pass-এ প্রক্রিয়া করা হয়। তাই model weights একবার পড়েই হাজার হাজার token process করা যায়, এবং hardware-এর সীমা মূলত multiply throughput-এ থাকে। Reply একবারে একটি token করে তৈরি হয়। প্রতিটি token-এর জন্য আলাদা forward pass চালাতে হয় এবং প্রতিবার পুরো model weights আবার পড়তে হয়। ফলে hardware-এর সীমা memory bandwidth-এ চলে যায়। Anthropic-এর বর্তমান সম্পূর্ণ catalogue-এ Haiku 4.5 থেকে Fable 5 পর্যন্ত input-এর তুলনায় output-এর দাম 5 গুণ।

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

না। Prompt caching শুধু input-এর ক্ষেত্রে প্রযোজ্য। August 2026 অনুযায়ী, cache read-এর খরচ base input rate-এর 0.1x। 5 minute duration-এর cache write-এর খরচ 1.25x এবং 1 hour duration-এর জন্য 2x। Cache যাই করুক, প্রতিটি call-এ output-এর জন্য পূর্ণ rate নেওয়া হয়। তাই caching আপনার bill-এর আকারের পাশাপাশি তার গঠনও বদলে দেয়। Input-এর খরচ কমে গেলে output-ই এমন অংশ হয়ে দাঁড়ায়, যেটি কমানোর দিকে মনোযোগ দেওয়া উচিত।

Reply সংক্ষিপ্ত হলে উচ্চ `max_tokens` কি আমার খরচ বাড়ায়?

না। Model বাস্তবে যত token তৈরি করে, আপনাকে তার জন্যই bill করা হয়। তাই max_tokens হলো সর্বোচ্চ সীমা, কোনো আগাম সংরক্ষিত পরিমাণ নয়। তবু এটি গুরুত্বপূর্ণ, কারণ নিয়ন্ত্রণের বাইরে বেড়ে যাওয়া reply-এর একমাত্র কঠোর সীমা এটিই। আপনার পর্যবেক্ষণ করা output_tokens-এর 95th percentile-এর সামান্য ওপরে এটি নির্ধারণ করুন। এরপর নীরবে কেটে যাওয়া উত্তর পাঠানোর পরিবর্তে 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-এর বেশি হলে আপনার খরচ মূলত prompt-এ হচ্ছে। তাই স্থিতিশীল অংশ cache করুন এবং বাকি অংশ সংক্ষিপ্ত করুন। অনুপাত এর চেয়ে কম হলে আপনার খরচ মূলত reply-এ হচ্ছে। তাই reply-এর দৈর্ঘ্য সীমিত করুন এবং যেসব ধাপে সবচেয়ে বেশি output তৈরি হয়, সেগুলো কম খরচের model বা Batch API-তে স্থানান্তর করুন।

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

ইনপুট টোকেনের তুলনায় আউটপুট টোকেনের খরচ বেশি কেন

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

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

2026 সালের August অনুযায়ী প্রতি million token-এ Claude-এর মূল্য

আপনার বিলের কতটা অংশ আউটপুট থেকে আসতে শুরু করে?

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

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

Caching input-এর খরচ কমায়, শুধু input-এর

চারটি নিয়ন্ত্রণযোগ্য উপায়

FAQ

আউটপুট token-এর খরচ input token-এর চেয়ে বেশি কেন?

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

Reply সংক্ষিপ্ত হলে উচ্চ max_tokens কি আমার খরচ বাড়ায়?

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

Reply সংক্ষিপ্ত হলে উচ্চ `max_tokens` কি আমার খরচ বাড়ায়?