খরচ কমানোর উপায়

একটা request-এর খরচ হলো আপনি যত token পাঠান আর model যত token লেখে, প্রতিটা model-এর প্রতি million token-এর দামে। এই পেজের সবকিছু তিনটার একটা বদলায়: কোন দামে দিচ্ছেন, কত token ঢুকছে, আর কত token বেরোচ্ছে। সেকশনগুলো সাজানো মোটামুটি এই ক্রমে: আগে সেই সিদ্ধান্তগুলো, যা সাধারণত বিলে সবচেয়ে বেশি তফাত আনে; শেষে সেগুলো, যা মূলত হঠাৎ চমক ঠেকায়। আপনার ব্যবহার আলাদা হবে, তাই এই ক্রম বা অন্য কোনো ক্রমের ওপর ভরসা না করে প্রতিটা বদলের আগে আর পরে মেপে দেখুন।

আগে মাপুন#

যা দেখতে পান না, তা কমানো যায় না। একটা request-এর খরচ তিন জায়গায় দেখা যায়:

• প্রতিটা response-এ একটা usage object থাকে, তাতে input আর output token-এর সংখ্যা আছে। এটা log করে রাখুন।
• Dashboard-এর Usage পেজে সাম্প্রতিক request-এর তালিকা আছে model, token আর খরচ সহ, আর আছে দৈনিক খরচের chart, সঙ্গে খরচ অনুযায়ী সাজানো ভাগ-ভাগ হিসাব। যে model সবার ওপরে, সেটা দিয়ে শুরু করুন।
• CSV export-এ প্রতি request-এ এক সারি, তাতে input, output ও cache-read token আর USD-তে খরচ থাকে। দেখুন usage, limit আর alert।

দুই ধরনের নমুনা খুঁজুন: একটা model, যে বেশিরভাগ খরচ টানছে; আর যে request-এর input output-এর চেয়ে অনেক বড়। প্রথমটা মানে model বাছাই, দ্বিতীয়টা মানে context-এর আকার।

1. কাজের জন্য ঠিক model বাছুন#

সবচেয়ে বড় তফাত সাধারণত model-টার প্রতি token-এর দামেই। Tokens-এ model-এর দাম অনেক বড় পরিসরে ছড়ানো, আর রোজকার অনেক কাজে (commit message, classification, test-এর কাঠামো, ছোট edit) সবচেয়ে দামি model লাগে না।

• কঠিন, লম্বা কাজে শক্তিশালী model নিন, আর bulk বা সহজ কাজে সস্তা model।
• একই সত্যিকারের কাজ দুটো model-এ চালিয়ে তুলনা করুন একটা কাজ শেষ করার খরচ, প্রতি token-এর দাম নয়। দামি model কম turn-এ কাজ সারলে মোট খরচ কমও হতে পারে।
• যে model উত্তর দেওয়ার আগে সবসময় ভাবে, সে প্রতিটা call-এ output token বাড়ায়।

কোন model বেছে নেবেন-এ কয়েকটা উল্লেখযোগ্য model-এর list price আছে, আর /models-এ প্রতিটার জন্য আপনার আসল দাম। আপনার plan যে model-গুলো ধরে, সেগুলো pay-as-you-go-র চেয়ে আপনার জন্য সস্তাও হতে পারে, 5 নম্বর সেকশন দেখুন।

2. max_tokens ঠিক করে দিন#

max_tokens হলো model সর্বোচ্চ কত token লিখতে পারবে তার সীমা। বেশিরভাগ model-এ output token-এর দাম input-এর চেয়ে বেশি, আর বেহিসেবি লম্বা উত্তরই সবচেয়ে সহজে খরচ বাড়ায়।

• model যে সর্বোচ্চ মান দেয় সেটা নয়, একটা ভালো উত্তরের যতটা লাগে ততটাই দিন। একটা classification label-এ লাগে কয়েক দশ token, একটা code review-এ কয়েক হাজার।
• না দিলে Tokens ব্যালান্স, key-র cap আর plan-এর limit মেলানোর সময় ধরে নেয় 8,192 output token। ছোট মান দিলে cap-এর কাছাকাছি থেকেও request পার হয়ে যেতে পারে, বড় মানে যেটা আটকে যেত।
• Responses API-তে field-টার নাম max_output_tokens। Chat Completions-এ OpenAI-র কিছু নতুন model max_completion_tokens ব্যবহার করে। Gateway তিনটাই পড়ে।
• finish_reason যদি length হয়, তাহলে উত্তর আপনার সীমায় কেটে গেছে। এমন প্রায়ই হলে কাজের জন্য সীমাটা কম পড়ছে। তাই বলে সব জায়গায় শুধু দ্বিগুণ করে দেবেন না।
• আপনি যে max_tokens চেয়েছেন, Wallet তা পুরো ধরতে না পারলে Tokens সেটা ব্যালান্সে যতটা কুলায় ততটা কমিয়ে দিতে পারে, 16-এর নিচে কখনো নয়। তখন উত্তর ছোট আসে। দেখুন plan, credit আর Wallet।

import os
from openai import OpenAI

client = OpenAI(base_url="https://tokens.bd/v1", api_key=os.environ["TOKENS_API_KEY"])

resp = client.chat.completions.create(
    model="deepseek/deepseek-v4.1-flash",
    messages=[{"role": "user", "content": "Label this commit message as fix, feat or chore: 'handle empty cart'"}],
    max_tokens=10,
)
print(resp.choices[0].message.content, resp.usage.completion_tokens)

3. Context ছোট করুন#

Chat API-র কোনো স্মৃতি নেই। প্রতিটা request-এ পুরো কথোপকথন যায়, তাই লম্বা session প্রতি turn-এ একই পুরোনো message-এর দাম আবার দেয়। Coding agent তার ওপর জুড়ে দেয় file-এর লেখা আর tool-এর output। এ কারণেই লম্বা agent session-এ input token-ই বেশিরভাগ।

কী কাজে লাগে:

• প্রতি turn-এ কম পাঠান। model-এর আর যে tool result লাগে না তা বাদ দিন, পুরো tree-র বদলে দরকারি file বা function পাঠান, system prompt ছোট রাখুন।
• নতুন কাজে নতুন কথোপকথন শুরু করুন, পুরোনোটা টেনে নিয়ে নয়।
• পুরোনো turn-এর সারাংশ বানান। লম্বা কথোপকথনের প্রথম অংশের জায়গায় একটা ছোট সারাংশ বসান, আর শেষ কয়েকটা message যেমন আছে তেমন রাখুন।
• যা tool নিজে এনে দিতে পারে, তা paste করবেন না। যে agent বেছে বেছে খুঁজে পড়ে, সে সাধারণত শুরুতেই সব হাতে পাওয়া agent-এর চেয়ে কম পাঠায়।
• বড় window-র দাম মনে রাখুন। অনেক model-এ 1M-token context আছে, কিন্তু যত token ভরবেন, প্রতিটা request-এ তার সবটার বিল হবে। কিছু provider একটা আকারের সীমা পেরোলে বেশি rate নেয়। সেটা লেখা আছে model বাছাইয়ের পেজে।

আপনার input আসলে কত বড় দেখতে response-এর usage.prompt_tokens পড়ুন, অথবা পাঠানোর আগে token গোনা ব্যবহার করুন।

def trim_history(messages, keep_last=6):
    """Keep the system prompt and the most recent messages."""
    system = [m for m in messages if m["role"] == "system"]
    rest = [m for m in messages if m["role"] != "system"]
    return system + rest[-keep_last:]

এটা ভোঁতা হাতিয়ার: turn কেটে দিলে model-এর দরকারি তথ্যও চলে যেতে পারে। শুরুর turn-গুলো জরুরি হলে ফেলে না দিয়ে সারাংশ করুন।

4. Prompt caching কাজে লাগান#

আপনার prompt-এর শুরুর অংশ request থেকে request একই থাকলে (system prompt, tool definition, একটা বড় file), provider সেটা কম দামে cache থেকে পড়তে পারে। Cached input usage record-এ cache-read token হিসেবে দেখায়, আর যে model-এর cache-read rate আছে সেই rate-এ দাম ধরা হয়। এর জন্য prompt কীভাবে সাজাবেন তা আছে prompt caching-এ। কত বাঁচবে তা নির্ভর করে model আর আপনার traffic-এর ওপর, তাই usage-এর সারিগুলোতে cache-read token দেখে নিন।

5. Plan-এর allowance আর ফ্রি model কাজে লাগান#

Plan কোন model-কে কীভাবে ধরে, তাতে একটা request আপনার কত পড়ে তা বদলে যায়। plan, credit আর Wallet থেকে:

• একটা plan কোনো model-কে নিজস্ব allowance দিতে পারে। এটা plan-এর usage-এর ভেতরের একটা সীমা, বাড়তি কিছু নয়: ওই model চালালে একই সঙ্গে plan-এর credit আর model-এর allowance, দুটো থেকেই কাটে।
• ফ্রি model-এ কোনো খরচ নেই, আপনার credit বা কোনো allowance লাগে না, আর plan-এর credit ফুরোলেও চলতে থাকে। কোনো কাজে ফ্রি model যথেষ্ট ভালো হলে (plan-এর pricing পেজ দেখুন), সেই কাজ ওটাকে দিন।
• Deal plan-এর usage-এ model-এর দাম কমায়, ফলে একই credit-এ বেশি চলে।
• Model-এর allowance ফুরিয়ে গেলে reset পর্যন্ত 429 model_limit_reached পাবেন। যে plan-এ pay-as-you-go fallback আছে, সেখানে ওই model-এর request তার বদলে Wallet থেকে পুরো catalog-দামে কাটে, কোনো deal ছাড়াই। পরিকল্পনার চেয়ে বেশি খরচ হওয়ার এটা একটা নিঃশব্দ রাস্তা, তাই নজর রাখুন।

6. Background call-এ সস্তা model দিন#

অনেক tool মূল কথোপকথনের পাশাপাশি পেছনে ছোট ছোট call করে (title, সারাংশ, ছোট edit)। এগুলোও আপনার মূল কাজের দামি model-এ চললে জমে অনেক হয়। যে tool-এ দ্বিতীয় একটা model ঠিক করে দেওয়া যায়, সেখানে একটা সস্তা model দিন:

• Claude Code: ANTHROPIC_DEFAULT_HAIKU_MODEL ঠিক করে haiku alias-এর পেছনে কোন model থাকবে, আর background task-ও এটাই চালায়। এটা unset থাকলে background task মূল model-এ চলে। CLAUDE_CODE_SUBAGENT_MODEL ঠিক করে subagent কোন model নেবে। দেখুন Claude Code।
• OpenCode: small_model-এ হালকা কাজের জন্য সস্তা model দেওয়া যায়। দেখুন OpenCode।
• Crush: আপনি একটা large আর একটা small model বেছে নেন। দেখুন Crush।

Session-এর পর Usage পেজ দেখুন। যে model আপনি বেছে নেননি তার নাম চোখে পড়লে, সাধারণত কারণ কোনো background setting।

7. যে stream আর লাগবে না তা cancel করুন#

Connection বন্ধ করলে Tokens-এর দিকে request শেষ হয়ে যায়, আর ততক্ষণ পর্যন্ত যা তৈরি হয়েছে তার বিল আসে। Tokens এভাবে request-এর হিসাব ধরে (gateway-এর কোডে দেখা, October 2026):

• Connection বন্ধ করলে gateway cancel-টা provider-কে জানিয়ে দেয়, আর এ পর্যন্ত গোনা token ধরে request-এর হিসাব মিটিয়ে দেয়।
• Provider আগেই usage জানিয়ে থাকলে সেটাই ধরা হয়। না জানালে (অনেক provider usage পাঠায় stream-এর একেবারে শেষে), Tokens ততক্ষণে পাঠানো লেখার দৈর্ঘ্য থেকে আন্দাজ করে। এমন record-এ estimated চিহ্ন থাকে।
• Input token ফেরত পাওয়া যায় না। Prompt আগেই পড়া হয়ে গেছে।
• যে stream ছেড়ে দেওয়া হলো কিন্তু বন্ধ করা হলো না, সেটা শেষ না হওয়া পর্যন্ত আপনার একটা concurrency slot ধরে রাখে। তাই শেষ পর্যন্ত না পড়লে stream বন্ধ করে দিন। দেখুন rate limit।

কাজের কথা: কোনো user response থামিয়ে দিলে বাকি chunk উপেক্ষা না করে HTTP request-টাই abort করুন।

import os
from openai import OpenAI

client = OpenAI(base_url="https://tokens.bd/v1", api_key=os.environ["TOKENS_API_KEY"])

stream = client.chat.completions.create(
    model="deepseek/deepseek-v4.1-flash",
    messages=[{"role": "user", "content": "Explain how HTTP caching works."}],
    max_tokens=800,
    stream=True,
)
text = ""
for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content:
        text += chunk.choices[0].delta.content
    if len(text) > 400:  # enough, stop paying for more
        stream.close()
        break
print(text)

8. Window, plan আর Wallet বুঝে নিন#

Plan আর Wallet আলাদা আলাদা ভাবে খরচ আটকায়। এখন কোনটা চলছে জানলে বোঝা যায় কিসের ওপর নজর রাখতে হবে।

• Plan একটা credit allowance দেয়, আর কিছু plan সেটা ভাগ করে দেয় 5 ঘণ্টার session, এক সপ্তাহ বা এক মাসের ওপর। কোনো window ফুরিয়ে গেলে, Wallet-এ যা-ই থাকুক, reset পর্যন্ত request-এ 429 window_exhausted আসে। ভারী একটা দিনে এটা নিজে থেকে লেগে যাওয়া ব্রেক।
• Wallet হলো আগে টাকা দিয়ে রাখা pay-as-you-go। কোনো usage window একে আটকায় না, শুধু ব্যালান্স আটকায়। Fallback আছে এমন plan-এ credit ফুরোলে Wallet-এ চলে যায়, পুরো দামে।
• Key-র monthly spend cap শুধু ওই একটা key-কে সীমা দেয়, 9 নম্বর সেকশন দেখুন।

কোথায় দাঁড়িয়ে আছেন, GET /v1/tokens/usage থেকে দেখে নিন। এটা ফ্রি, এর জন্য কোনো খরচ ধরা হয় না, আর আপনার প্রতি মিনিটের limit-এও গোনা হয় না।

curl -s https://tokens.bd/v1/tokens/usage -H "Authorization: Bearer $TOKENS_API_KEY" \
  | jq -r '.windows[] | "\(.label): \(.percentUsed)% used, resets \(.resetsAt)"'

কোনো window তার বর্তমান সময়কালে এখনও ব্যবহার না হয়ে থাকলে সেটা response থেকে বাদ থাকে, তাই reset-এর পর ফাঁকা তালিকা আসা স্বাভাবিক। কোনো window-তে ধাক্কা খাওয়ার আগেই batch job থামিয়ে দিতে এই response কাজে লাগান:

import os
import sys
import requests

resp = requests.get(
    "https://tokens.bd/v1/tokens/usage",
    headers={"Authorization": f"Bearer {os.environ['TOKENS_API_KEY']}"},
    timeout=10,
)
resp.raise_for_status()
usage = resp.json()

for window in usage["windows"]:
    if window["percentUsed"] >= 80:
        sys.exit(f"{window['label']} is {window['percentUsed']}% used, resets {window['resetsAt']}")

balance = (usage.get("wallet") or {}).get("balanceUsd")
if balance is not None and balance < 5:
    sys.exit(f"Wallet balance is ${balance:.2f}")
print("OK to start the job")

80 আর 5 শুধু উদাহরণের সীমা। নিজেরটা ঠিক করে নিন।

9. Cap আর alert#

Limit থাকলে একটা ভুল বিল না হয়ে error হয়ে ধরা পড়ে।

• প্রতি key-তে monthly spend cap। Key বানানোর সময় দিন, পরে edit করা যায় না। CI, script বা কেউ না দেখে চলা agent যে key ব্যবহার করে, তাতে সবসময় cap থাকা উচিত। যে request key-কে cap পার করিয়ে দেবে, সেটা 403 monthly_spend_cap_exceeded দিয়ে ফিরিয়ে দেওয়া হয়। দেখুন API key, আর একাধিক key-র জন্য customer প্রতি একটা key।
• প্রতি key-তে allowed model। একটা সস্তা model-এ বেঁধে দেওয়া key ভুল করে দামি model call করতে পারে না।
• ইমেইল alert। Notifications-এ plan-এর limit-এর 50%, 75% আর 90%-এ সতর্কতা পেতে পারেন, আর Wallet $5-এর নিচে নামলে low-balance alert। এগুলো চালু আছে কি না দেখে নিন।

চেকলিস্ট#

1. Usage পেজে দেখুন কোন model আপনার বেশিরভাগ খরচ টানছে।
2. ভেবে দেখুন ওই কাজ কোনো সস্তা বা ফ্রি model দিয়ে হয় কি না, আর সত্যিকারের কাজে পরীক্ষা করুন।
3. প্রতিটা request-এ max_tokens দিন।
4. usage.prompt_tokens দিয়ে input-এর আকার দেখুন, তারপর যা বারবার আসে তা ছাঁটুন, সারাংশ করুন বা cache করুন।
5. আপনার tool-এ background আর ছোট কাজের জন্য সস্তা model ঠিক করে দিন।
6. যে stream আর লাগবে না তা cancel করুন।
7. যে key কেউ না দেখে চলে, তাতে monthly cap বসান, আর alert চালু রাখুন।