Claude-এ input বনাম output token-এর খরচ কেন 5 গুণ

Input token-এর চেয়ে output token-এর খরচ বেশি কেন

বর্তমান catalogue-এর প্রতিটি Claude model-এ output token-এর খরচ input token-এর চেয়ে পাঁচ গুণ বেশি। এর কারণ computation-এর ধরন। Model একটি prompt একবারে পড়ে। কিন্তু 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 দুটি পর্যায়ে পরিচালনা করে। এই পর্যায় দুটির খরচের ধরন ভিন্ন। 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 কত দ্রুত multiplication করতে পারে তার দ্বারা।

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

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

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

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

যেকোনো Ubuntu সিস্টেমে tools ইনস্টল করুন:

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 শুরু হওয়ার পর কেটে যাওয়া seconds লিখে। ওই output থেকে দুটি বিষয় পড়া গুরুত্বপূর্ণ। প্রথম content_block_delta লাইনটি হলো first 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 হয়। পাঠানোর আগে prompt-এর মূল্য নির্ধারণ করতে POST /v1/messages/count_tokens একই request body গ্রহণ করে, model চালানো ছাড়াই {"input_tokens": N} ফেরত দেয়, এবং এর জন্য কোনো খরচ নেই। API-এর একমাত্র বিনামূল্যের অংশ এটি নয়। প্রথম project-এর budget নির্ধারণের আগে Claude API-এর কোন অংশগুলোর জন্য কখনো billing হয় না দেখে নেওয়া ভালো।

2026 সালের August মাসে প্রতি million token-এর জন্য Claude-এর চার্জ

[
  {
    "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
  }
]

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

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

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

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

কখন output আপনার বিলের প্রধান অংশ হয়ে দাঁড়ায়?

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

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

[
  {
    "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 করার আগে logs থেকে প্রকৃত ratio বের করুন।

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

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

[
  {
    "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টি ধাপের খরচ প্রতিদিন $64।

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

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

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

[
  {
    "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 ঘণ্টার মধ্যে ফল দেয়। তাই রাতভর report generation এবং bulk classification-এর জন্য এটি উপযুক্ত। কোনো ব্যক্তি বসে ফলাফলের জন্য অপেক্ষা করলে এটি উপযুক্ত নয়।

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

ক্যাশিং শুধু input-এর খরচ কমায়

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

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

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

[
  {
    "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
  }
]

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

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

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

1. max_tokens আপনার p95 output length অনুযায়ী নির্ধারণ করুন, model maximum অনুযায়ী নয়।
2. বেশি output তৈরি করা ধাপগুলো সস্তা model-এ পাঠান।
3. যেসব কাজের ফলাফলের জন্য কেউ অপেক্ষা করছে না, সেগুলো batch করুন।
4. যেসব instruction reply দীর্ঘ করে, সেগুলো মুছে দিন।

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

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

Batching-ই একমাত্র উপায় যা output-এর খরচ কমায়। উভয় দিকেই 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 সস্তা—এই সিদ্ধান্তটি নেওয়া ভালো, subscription যে per-token খরচ বহন করে নিত, এমন খরচ fine-tune করতে এক সপ্তাহ ব্যয় করার আগে। একজন developer-এর ক্ষেত্রে বিষয়টি মূলত নির্ভর করে Claude Pro-এর মাসিক $20 এবং এর সঙ্গে থাকা usage limit এমন কাজের জন্য যথেষ্ট কি না, যে কাজের token usage আপনি অন্যথায় metering-এর আওতায় রাখতেন। আপনি যদি session-এর মাঝেই ওই limit-এ পৌঁছে যান, তাহলে আপনি কোন window-এর জন্য অপেক্ষা করছেন তা নির্ধারণ করা আগে করতে হবে। কারণ এরপর সমাধান হতে পারে ছোট model, হালকা context, অতিরিক্ত usage credit, অথবা সেই কাজ metered API-তে সরিয়ে নেওয়া। যদি metered API-ই ওই কাজের জন্য সস্তা মাধ্যম হয়, তাহলে ছোট plan-এ নামা বা plan বাতিল করা ইতিমধ্যে পরিশোধ করা মাসটি অক্ষত রাখে; তাই পরিবর্তন করতে যাওয়ার সময় আপনার কোনো অতিরিক্ত খরচ হয় না। আপনি যে plan-টির সঙ্গে Pro-এর তুলনা করছেন সেটি যদি metered API নয়, ChatGPT-এর plan হয়, তাহলে দুটি subscription স্তরের পাশাপাশি মূল্য তুলনা coding কাজের জন্য কোনটি সস্তা তা দেখায়। এই প্রশ্নটি যদি একজন developer-এর বদলে একটি team-এর জন্য করা হয়, মনে রাখুন যে Claude Enterprise প্রতি seat-এর fee-র সঙ্গে একই API rate-এ মাপা token-এর খরচ যোগ করে। তাই এই পৃষ্ঠার প্রতিটি উপায় ওই bill-এর metered অংশের ক্ষেত্রেও প্রযোজ্য।

FAQ

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

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

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-এর জন্য full rate নেওয়া হয়। তাই caching আপনার bill-এর আকারের পাশাপাশি তার গঠনও বদলে দেয়। Input-এর খরচ কমে গেলে output-ই বিল কমানোর প্রধান ক্ষেত্র হয়ে ওঠে।

Reply ছোট হলে উচ্চ max_tokens কি আমার খরচ বাড়ায়?

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