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

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

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

Price list-এর প্রতিটি row-তে এই অনুপাত একই। তাই আপনি কোন model বেছে নিলেন, তা আপনার bill-এর কতটা অংশ output-এর জন্য যাচ্ছে সেটি পরিবর্তন করে না। এটি নির্ধারণ করে আপনার workload-এর ধরন। 60,000 token পড়ে 800 token-এর উত্তর দেওয়া একটি agent step-এ output-এর খরচ প্রায় নেই। 2,000 token পড়ে 12,000 token লেখা একটি drafting job-এ 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-এ সম্পন্ন হয়। Memory থেকে model weights একবার পড়েই পুরো prompt প্রক্রিয়া করা যায়। Accelerator-এর matrix unit-গুলো ব্যস্ত থাকে। তাই prefill compute-bound: সীমা হলো chip কত দ্রুত গুণ করতে পারে।

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

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

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

নিজেই input ও output-এর ব্যবধান পরিমাপ করুন

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

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

Claude প্রতি 1 মিলিয়ন token-এর জন্য কত চার্জ করে, August 2026 অনুযায়ী

[
  {
    "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, এবং Fable 5-এর এই rate-এ আপনি কী পান—উপরের row-টি বাদ দেওয়ার আগে তা পড়া উপযোগী। তালিকায় উপরের দিকে গেলে উভয় দিক একই factor দিয়ে গুণ হয়। তাই মোট খরচ বদলালেও 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 list-এ একটি গুরুত্বপূর্ণ বিষয় দেখানো হয় না। Anthropic-এর documentation অনুযায়ী, Claude 4.7 এবং পরবর্তী model-গুলো একটি নতুন tokenizer ব্যবহার করে। এই tokenizer Sonnet 4.6 এবং তার আগের version-গুলোর tokenizer-এর তুলনায় একই text-এর জন্য প্রায় 30% বেশি token তৈরি করে। শুধু প্রতি 1 মিলিয়ন token-এর দাম তুলনা করলে নতুন model-টি অযথা বেশি সুবিধাজনক মনে হবে, কারণ একই document-এ সেটিতে বেশি token গণনা হয়। সম্পূর্ণ task শেষ করতে প্রকৃত খরচ তুলনা করুন এবং যে model ব্যবহার করার পরিকল্পনা করছেন, তার বিরুদ্ধে আপনার বাস্তব prompt-এর token গণনা করুন। Provider-গুলোর মধ্যেও একই সমস্যা আছে, কারণ তাদের tokenizer একে অপরের থেকে এর চেয়েও বেশি ভিন্ন। তাই Claude এবং ChatGPT-তে একই বাস্তব কাজের খরচ নির্ণয় করা দুইটি rate card পাশাপাশি রাখার চেয়ে বেশি তথ্য দেয়। বাস্তব text-এ Claude-এর 1 মিলিয়ন 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-এর।

[
  {
    "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-এর একটি ধাপ নিন: retrieved document এবং conversation history মিলিয়ে 60,000 input token, এবং 800 token-এর একটি উত্তর। অনুপাতটি 75 to 1। যে workload আগে পড়ে, পরে লেখে, তার জন্য এটি স্বাভাবিক।

[
  {
    "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 থেকে stale 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 ধাপে যেমন কার্যকর নয়। কাজের verbose অংশটি যদি যান্ত্রিক হয়—যেমন text reformat করা বা ইতিমধ্যে অনুমোদিত outline সম্প্রসারণ করা—তাহলে সাশ্রয়ী model এক-পঞ্চমাংশ খরচে ওই token তৈরি করতে পারে। Opus, Sonnet এবং Haiku-এর মধ্যে নির্বাচন-এ quality-এর বাস্তব সীমা কোথায়, তা ব্যাখ্যা করা হয়েছে।

Caching খরচ কমায়, তবে শুধু 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-এর জন্য full output rate প্রযোজ্য হবে, prompt-এর যত অংশ cache hit হিসেবে ফিরে আসুক না কেন।

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
  }
]

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

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

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

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

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

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

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

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

FAQ

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

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

Prompt caching কি আউটপুট টোকেনের খরচ কমায়?

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

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

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