Claude Code spend tracker তুলনা: কোনটি বেছে নেবেন?

Claude Code spend tracker আসলে কী পড়ে

প্রতিটি Claude Code spend tracker তিন ধরনের data source-এর একটি পড়ে। কোন প্রশ্নের উত্তর এটি দিতে পারবে, তা source-এর ওপর নির্ভর করে। একটি log parser আপনার নিজের disk-এ থাকা session transcript file পড়ে। একটি dashboard আপনার account বা organisation-এর জন্য Anthropic সংরক্ষণ করা usage record পড়ে। আপনি এটি চালু করলে একটি metrics backend Claude Code যে OpenTelemetry (OTel) stream পাঠায়, তা পড়ে। তিনটিই একই সময়ে সঠিক হতে পারে, তবু তাদের ফল আলাদা হতে পারে, কারণ তারা ভিন্ন বিষয় গণনা করে।

এই guide-এ tokens সম্পর্কে আবার ব্যাখ্যা করা হবে না। Claude Code কীভাবে token usage গণনা করে অংশে input, output, cache writes এবং cache reads ব্যাখ্যা করা হয়েছে। এই বিষয়টি পরিষ্কার না হলে কোনো dashboard-এর ফল বোঝা কঠিন। এখানে প্রশ্নটি আরও নির্দিষ্ট: প্রতিটি ধরনের tool কী দেখতে পারে এবং কোন বিষয়টি কখনোই দেখতে পারে না।

একই দিনে Claude Code-এর তিনটি spend tracker কেন দেখা গেল

একই দিনে Claude Code-এর জন্য তিনটি আলাদা spend tracker প্রকাশিত হয়েছিল। এগুলো একই tool-এর তিনটি version ছিল না, এবং গুরুত্বপূর্ণ বিষয়টিও এটাই। একটি local session file parse করত। একটি account usage screen-এর চারপাশে wrapper হিসেবে কাজ করত। অন্যটি ছিল এমন একটি hosted tracing backend, যেটি আপনি নিজেই চালান।

এগুলো একই সময়ে প্রকাশিত হয়েছিল, কারণ agent session-এর খরচ আর সরাসরি বোঝা যাচ্ছিল না। chat-এর খরচ সাধারণত screen-এ দেখা তথ্য থেকেই অনুমান করা যায়। কিন্তু একটি agent বিশটি file পড়ে, test suite চালায় এবং প্রতিটি turn-এ পুরো conversation আবার পাঠায়। তাই আপনি নিজে যে context টাইপ করেননি, সেটিও bill-এর পরিমাণ নির্ধারণ করে। subscription-এ Claude Code যে session dollar figure দেখায়, Anthropic-এর মতে সেটি billing-এর জন্য প্রাসঙ্গিক নয়। প্রাসঙ্গিক হলো usage bar, যা কিছু দিনে অন্য দিনের তুলনায় দ্রুত কমে যায়। তিনটি tool-ই এই ঘাটতির আলাদা অংশ পূরণ করে।

Shape 1: একটি local log parser জানায় আজকের খরচ কত

Claude Code প্রতিটি conversation JSON Lines (JSONL) হিসেবে ~/.claude/projects/<project>/<session-id>.jsonl-এ সংরক্ষণ করে, যেখানে <project> হলো আপনার working directory-এর path, যার non-alphanumeric character-গুলো - দিয়ে প্রতিস্থাপিত। ওই file-এর প্রতিটি assistant turn-এ request-এর token count থাকে। একটি log parser এগুলো যোগ করে এবং মূল্য হিসাব করে।

ccusage-ই সাধারণত অধিকাংশ মানুষ ব্যবহার করে। এটি install করার প্রয়োজন নেই:

npx ccusage@latest daily
npx ccusage@latest daily --breakdown
npx ccusage@latest blocks
npx ccusage@latest session --json

daily তারিখ অনুযায়ী total দেখায়। --breakdown প্রতিটি row model অনুযায়ী ভাগ করে। এভাবেই বোঝা যায়, এক বিকেলের Opus ব্যবহার পুরো সপ্তাহের বড় অংশ কিনা। blocks subscription reset হওয়া পাঁচ ঘণ্টার window অনুযায়ী group করে। session conversation অনুযায়ী total দেখায়, আর daily --instances project অনুযায়ী group করে। এতে কোন repository বেশি ব্যয়বহুল তা দেখা যায়। range সীমিত করতে --since এবং --until যোগ করুন। আপনার version যে date format প্রত্যাশা করে, তার জন্য npx ccusage@latest daily --help চালান। October 2026 অনুযায়ী এটি Codex এবং OpenCode-সহ অন্যান্য agent CLI-ও পড়তে পারে। তুলনা করার সময় এটি গুরুত্বপূর্ণ।

মূল্য একটি model price table থেকে নেওয়া হয়। Tool-টির তিনটি cost mode আছে। --mode auto উপস্থিত থাকলে file-এ Claude Code লিখে রাখা costUSD value ব্যবহার করে। তা না থাকলে token count থেকে হিসাব করে। --mode calculate সবসময় token থেকে হিসাব করে এবং recorded cost উপেক্ষা করে। --mode display শুধু recorded cost দেখায়। যেসব row-তে তা নেই, সেগুলোর জন্য $0.00 print করে। কোনো total ভুল মনে হলে একই report প্রথমে calculate-এর অধীনে এবং পরে display-এর অধীনে চালান। দুটির মধ্যে বড় পার্থক্য থাকলে বুঝতে হবে, অধিকাংশ entry-তে recorded cost নেই। তাই আপনি যে সব সংখ্যা দেখছেন, সেগুলো estimate। Contracted rate-এ অর্থ পরিশোধ করলে ccusage.json config file-এ defaults-এর অধীনে pricingOverrides ব্যবহার করে individual model-এর price প্রতিস্থাপন করা যায়।

একই data আপনার prompt-এও ব্যবহার করা যায়। ccusage statusline Claude Code status bar-এর জন্য একটি সংক্ষিপ্ত line print করে। অন্য status line command-এর মতো এটিকে ~/.claude/settings.json-এ যুক্ত করা যায়। settings block এবং এটি যে field-গুলো পায়, সেগুলোর জন্য Claude Code statusline তৈরি করা দেখুন।

এই machine-এ যা ঘটেনি, log parser তা দেখতে পারে না। দ্বিতীয় laptop, claude.ai-এ session, অথবা কোনো teammate-এর কাজ—এসব transcript সংশ্লিষ্ট disk-এ থাকে। পুরোনো data-ও অনুপস্থিত থাকতে পারে। cleanupPeriodDays setting-এর অধীনে default হিসেবে 30 দিন পর transcript cleanup করা হয়। তাই archive না করলে গত quarter-এর data আর থাকবে না।

আরও একটি risk আছে। এটি কাঠামোগত। Anthropic-এর documentation অনুযায়ী entry format Claude Code-এর internal format এবং version পরিবর্তনের সঙ্গে এটি বদলাতে পারে। তাই এই file-গুলো সরাসরি parse করা script যেকোনো release-এ নষ্ট হতে পারে। এই ধরনের প্রতিটি tool-এর ক্ষেত্রেই একই কথা প্রযোজ্য। এ কারণেই JSONL-এর ওপর হাতে লেখা jq one-liner দেখতে যতটা ভালো মনে হয়, বাস্তবে তা খারাপ ধারণা। রক্ষণাবেক্ষণ করা parser-গুলো format-এর পরিবর্তন অনুসরণ করে। কোনো field-এর নাম বদলানোর দিন আপনার one-liner আত্মবিশ্বাসের সঙ্গে ভুল সংখ্যা দেখাতে পারে।

শেষে subscription-এর ক্ষেত্রে dollar figure সম্পর্কে একটি সতর্কতা দরকার। আপনার Pro বা Max plan limit-এর মধ্যে ব্যবহার token অনুযায়ী bill করা হয় না। তাই এই সংখ্যা list API rate অনুযায়ী আপনার token-এর সম্ভাব্য খরচ দেখায়। এটি আপনার ব্যবহারের পরিমাণ বোঝায়। এটি আপনার bill নয়। ব্যতিক্রম হলো usage credits। এগুলো চালু করলে plan limit অতিক্রমের ব্যবহার standard API rate-এ আলাদা charge হিসেবে bill করা হয়। claude.ai-এ সেই মাসের খরচ Settings > Usage-এর অধীনে দেখা যায়। আসল প্রশ্ন যদি হয় কোন plan বেছে নেবেন, তাহলে সেটি আলাদা তুলনা। দেখুন Claude subscription-এর সঙ্গে API billing তুলনা করা।

আকৃতি 2: বিল্ট-ইন usage screen আপনাকে জানায় কোন model বাজেট বেশি খরচ করেছে

Claude Code নিজস্ব reporting দেয়, কিন্তু অধিকাংশ মানুষ সেটি কখনো খোলে না। একটি session-এর ভিতরে /usage চালান। উপরের Session block-এ বর্তমান session-এর model অনুযায়ী token সংখ্যা এবং dollar amount দেখা যায়। এটি সাধারণ list rate অনুযায়ী token count থেকে locally হিসাব করা estimate, যদি না কোনো administrator managed settings-এ modelPricing table সেট করে থাকেন। সে ক্ষেত্রে Total cost line-এ at your organization's configured rates লেখা থাকে। যেকোনো ক্ষেত্রেই এই amount একটি estimate। এটি আপনার invoice-এর সঙ্গে ভিন্ন হতে পারে। Pro বা Max-এ Anthropic বলছে billing-এর জন্য এই amount প্রাসঙ্গিক নয়, কারণ ওই usage plan-এর অন্তর্ভুক্ত। /clear নতুন conversation শুরু হলে total আবার শূন্য হয়।

Pro, Max, Team বা seat-based Enterprise plan-এ একই screen-এ plan limit-এর কতটা ব্যবহার করেছেন তা দেখা যায়। Usage-based Enterprise-এ শেষ হয়ে যাওয়ার মতো কোনো included allowance নেই, কারণ প্রতিটি token API rate অনুযায়ী billed হয়। এই plan-গুলোতে screen-এ সাম্প্রতিক usage-এর কত শতাংশ skills, subagents, plugins এবং পৃথক MCP server থেকে এসেছে তাও দেখানো হয়। সাম্প্রতিক usage-এর 10% বা তার বেশি হওয়া আচরণগুলোও চিহ্নিত করা হয়, যেমন দীর্ঘ context বা cache miss। শেষ 24 hours এবং শেষ 7 days-এর মধ্যে পরিবর্তন করতে d অথবা w চাপুন। এই figure-গুলো approximate এবং এই machine-এর local session history থেকে হিসাব করা হয়। তাই দ্বিতীয় কোনো device-এর usage এতে ধরা পড়ে না। Bar শুধু কম নয়, পুরো empty হলে screen জানায় যে window বন্ধ হয়ে গেছে। তবে কীভাবে কাজ চালিয়ে যাবেন তা জানায় না। limit-এ পৌঁছে গেলে কী করবেন—এটি model, context এবং plan নিয়ে আলাদা সিদ্ধান্ত।

একজনের বেশি developer হলে এই সংখ্যা account পর্যায়ে চলে যায়। একটি API organisation-এ Console usage page, member-ভিত্তিক spend এবং accepted lines-সহ Claude Code dashboard, এবং admin key দিয়ে একই daily per-user metric ফেরত দেওয়া Claude Code Analytics API পাওয়া যায়। Team এবং Enterprise plan-এ admin console-এ CSV export-সহ daily updated spend report থাকে। তবে এটি usage-credit spend দেখায়। Seat allowance-এর ভিতরের usage dollar-এ metered হয় না। Enterprise-এ analytics API-ও থাকে। কোনটি দেখতে পাবেন তা প্রতিটি developer কীভাবে sign in করেছেন তার ওপর নির্ভর করে। তাই mixed organisation-কে দুটি report দেখে হাতে যোগ করতে হয়।

Budget নির্ধারণের জন্য Anthropic-এর cost documentation-এ October 2026 পর্যন্ত প্রকাশিত figure অনুযায়ী, প্রতি active day-এ developer-পিছু average প্রায় $13 এবং প্রতি month-এ $150 থেকে $250। 90% user-এর প্রতি active day-এ খরচ $30-এর নিচে। এটিকে আপনার team-এর prediction হিসেবে নয়, enterprise deployment থেকে প্রকাশিত benchmark হিসেবে বিবেচনা করুন। Extrapolate করার আগে একটি pilot group চালিয়ে measurement নিন।

Dashboard day এবং person-এর চেয়ে ছোট স্তরের কিছু দেখতে পারে না। এগুলো জানাতে পারে যে Tuesday-এর অধিকাংশ সময় Opus ব্যবহার হয়েছে। কিন্তু কোন prompt, কোন repository বা কোন CI job এটি করেছে তা জানাতে পারে না। এগুলোতে delay-ও থাকে, কারণ organisation report daily update হয়। তাই এগুলো review tool, আজ বিকেলে runaway agent শনাক্ত করার উপায় নয়। Runaway agent ধরতে report নয়, limit দরকার। এটাই VPS-এ agent-এর খরচ সীমার মধ্যে রাখা-এর বিষয়।

ধরণ 3: নিজের OpenTelemetry stack জানায় কোন prompt-এ regression হয়েছে

একটি environment variable সেট করার পর Claude Code OpenTelemetry metrics এবং events তৈরি করে। আপনার নিয়ন্ত্রণাধীন কোনো system-এ প্রায় real time-এ প্রতিটি user-এর token ও cost data পাঠানোর এটিই একমাত্র option। Metrics-এ claude_code.cost.usage USD-তে, claude_code.token.usage token-এ, claude_code.session.count এবং claude_code.active_time.total অন্তর্ভুক্ত থাকে।

Token metric-টিই বেশি গুরুত্বপূর্ণ, কারণ এতে বিভিন্ন attribute থাকে। প্রতিটি data point-এ type থাকে, যা input, output, cacheRead অথবা cacheCreation; এছাড়া model এবং query_source থাকে, যা main, subagent অথবা auxiliary। এতে agent.name, skill.name, mcp_server.name এবং mcp_tool.name-ও থাকে। আপনি নিজে configure করা MCP server এবং নিজের custom subagent-এর নাম custom হিসেবে আসে, যদি না OTEL_LOG_TOOL_DETAILS=1 সেট করেন; এটি tool event-এ Bash command এবং tool input-ও যোগ করে। এর মাধ্যমে এমন প্রশ্নের উত্তর পাওয়া যায়, যেগুলোর উত্তর কোনো dashboard দিতে পারে না: bill-এর কত অংশ আপনার নিজের turn-এর বদলে subagent ব্যবহার করেছে, কোনো একটি MCP server আপনার input token দ্বিগুণ করেছে কি না, অথবা কেউ CLAUDE.md সম্পাদনা করার পর cache read কমে গেছে কি না। সাধারণত cache behavior-এই অপ্রত্যাশিত বিষয়টি থাকে, এবং কখন prompt caching নিজস্ব খরচ তুলে আনে-এ আপনি যে data দেখছেন তার ব্যাখ্যা দেওয়া হয়েছে।

এখানে একটি সংশোধন করা দরকার, কারণ প্রতিটি আলোচনায় এই বিষয়টি উঠে আসে। Langfuse একটি ভালো self-hosted tracing backend, এবং VPS-এ এটি চালানোর পদ্ধতি agent tracing-এর জন্য Langfuse self-host করা-এ দেখানো হয়েছে। এর OTLP endpoint শুধু trace গ্রহণ করে। ডিফল্টভাবে Claude Code span নয়, metrics এবং log event export করে। তাই OTEL_EXPORTER_OTLP_ENDPOINT-কে Langfuse-এর দিকে পাঠালে project খালি থাকে এবং পড়ার মতো কোনো error-ও পাওয়া যায় না। Span export আছে, তবে এটি beta হিসেবে default-এ বন্ধ থাকে, যতক্ষণ না CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 এবং OTEL_TRACES_EXPORTER সেট করেন। Langfuse-এর নিজস্ব Claude Code integration ভিন্ন পদ্ধতি ব্যবহার করে: একটি Stop hook, অথবা এমন একটি plugin যা Stop hook ইনস্টল করে, প্রতিটি response-এর পরে session transcript পড়ে সেগুলোকে trace-এ রূপান্তর করে। তাই log parser-এর মতো এটিও local-only সীমাবদ্ধতার মধ্যে থাকে। API ব্যবহার করে নিজে তৈরি করা agent-এর জন্য Langfuse উপযুক্ত tool, কারণ সেখানে আপনার নিজের code প্রতিটি span-এর সঙ্গে prompt, model এবং cost তৈরি করে। Claude Code CLI-এর spend total-এর জন্য metrics store-ই উপযুক্ত।

নিজের VPS-এ Claude Code-এর খরচ পর্যবেক্ষণ সেট আপ করুন

দুটি service যথেষ্ট: metrics গ্রহণ করার জন্য একটি collector এবং সেগুলো সংরক্ষণের জন্য Prometheus। দুটিকেই public Internet থেকে বিচ্ছিন্ন রাখুন, কারণ উন্মুক্ত OTLP port খুঁজে পাওয়া যে কেউ সেখানে write করতে পারে। /opt/ccmetrics/compose.yaml লিখুন:

services:
  collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: ["--config=/etc/otel/config.yaml"]
    volumes:
      - ./collector.yaml:/etc/otel/config.yaml:ro
    ports:
      - "10.8.0.1:4318:4318"
    restart: unless-stopped
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - prom-data:/prometheus
    ports:
      - "127.0.0.1:9090:9090"
    restart: unless-stopped

volumes:
  prom-data:

10.8.0.1 হলো WireGuard tunnel-এর ভেতরে server-এর address। তাই collector আপনার machine-গুলো থেকে reachable হবে, অন্য কোথাও থেকে নয়। port-এর আগে দেওয়া address এখানে গুরুত্বপূর্ণ, কারণ published Docker port-গুলো ufw দিয়ে filter হয় না: দেখুন Docker published port কেন ufw bypass করে। tunnel নিজে সেট আপ করার নির্দেশনা রয়েছে নিজের VPS-এ একটি WireGuard VPN-এ।

/opt/ccmetrics/collector.yaml:

receivers:
  otlp:
    protocols:
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]

/opt/ccmetrics/prometheus.yml। Port 8889 host-এ কখনো publish করা হয় না, কারণ Prometheus service name ব্যবহার করে Compose network-এর মাধ্যমে collector-এ পৌঁছায়:

global:
  scrape_interval: 30s

scrape_configs:
  - job_name: claude-code
    static_configs:
      - targets: ["collector:8889"]

cd /opt/ccmetrics
docker compose up -d
docker compose logs collector

Collector log-এর শেষে Everything is ready. Begin running and processing data. থাকা উচিত। Config error-এ log থেমে গেলে বুঝবেন YAML parse হয়নি এবং container একটি loop-এর মধ্যে restart হতে থাকবে।

এখন Claude Code-কে এর দিকে নির্দেশ করুন। Claude Code চালায় এমন প্রতিটি machine-এ ~/.claude/settings.json-এ এটি যোগ করুন:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "none",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://10.8.0.1:4318",
    "OTEL_METRIC_EXPORT_INTERVAL": "10000"
  }
}

একটি session শুরু করুন, একটি prompt পাঠান, export interval-এর জন্য অপেক্ষা করুন (এখানে 10 seconds, default হিসেবে 60 seconds), তারপর Prometheus-কে জিজ্ঞেস করুন সে কী পেয়েছে:

curl -s http://localhost:9090/api/v1/label/__name__/values | grep -o 'claude_code[a-z_]*'

claude_code_ দিয়ে শুরু হওয়া একাধিক নাম পাওয়ার কথা। Exporter dot-গুলোকে underscore-এ রূপান্তর করে এবং unit যোগ করে, তাই exact string আপনার collector version-এর ওপর নির্ভর করবে। কোনো ফল না এলে কিছু পৌঁছায়নি। Protocol এবং port পরস্পরের সঙ্গে মেলে কি না পরীক্ষা করুন, কারণ http/protobuf 4318-এ যায় এবং grpc 4317-এ যায়; অমিল হলে কোনো স্পষ্ট error ছাড়াই export ব্যর্থ হয়। claude --debug-file /tmp/claude-debug.log চালান এবং সেই file-এ [3P telemetry] line খুঁজুন; Claude Code OTel export error এখানেই জানায়।

শুধু একটি machine থাকলে এবং server না থাকলে, ওপরের সব ধাপ বাদ দিন। OTEL_METRICS_EXPORTER=prometheus সেট করুন, এবং Claude Code নিজেই http://localhost:9464/metrics-এ একটি scrape endpoint প্রকাশ করবে। যখন prometheus-ই একমাত্র exporter হিসেবে তালিকাভুক্ত থাকে, Claude Code exported metrics থেকে USD, tokens এবং s unit বাদ দেয়, যাতে scrape বৈধ Prometheus text format বজায় রাখে। Metric name পরিবর্তন হয় না। তবে otlp,prometheus-এর মতো exporters একত্র করে এমন setting unit-গুলো রেখে দেয়।

এই কাঠামোর সঙ্গে একটি privacy সিদ্ধান্তও জড়িত। Default হিসেবে machine থেকে শুধু count এবং metadata বের হয়; prompt text বা tool output বের হয় না। OTEL_LOG_USER_PROMPTS=1 exported event-এ prompt text যোগ করে এবং OTEL_LOG_TOOL_CONTENT=1 trace span-এ tool output যোগ করে। তাই যেকোনো একটি signal export করলে আপনার telemetry box-এ source code এবং context-এ থাকা অন্যান্য তথ্যও সংরক্ষিত হবে। এগুলো ইচ্ছাকৃতভাবে চালু করুন এবং আগে agent context-এ secret রাখা এড়িয়ে চলা পড়ুন।

স্ক্রিপ্ট এবং CI রানগুলোর খরচ ট্র্যাক করা

Non-interactive run-গুলো বেশি চমক দেয়, কারণ কেউ screen দেখছে না। claude -p-এর সঙ্গে --output-format json ব্যবহার করলে result payload-এ সেই run-এর খরচ পাওয়া যায়:

claude -p "summarise the failing tests" --output-format json | jq '.total_cost_usd'

Payload-এ total_cost_usd এবং প্রতিটি model-এর আলাদা breakdown থাকে। তাই কোনো CI job dashboard ছাড়াই নিজের খরচ record করতে পারে। প্রতিটি local figure-এর মতো এটিও client-side estimate। --continue বা --resume দিয়ে কোনো run conversation চালিয়ে গেলে, আগের run-সহ পুরো conversation-এর মোট খরচ report হয়। এই value কোনো file-এ append করুন, অথবা উপরের collector-এ metric হিসেবে পাঠান। কার্যকর spend tracking-এর মধ্যে এটিই সবচেয়ে কম খরচের পদ্ধতি। প্রতি run-এ একটি jq call লাগে।

ব্যর্থতার ধরন এবং আপনি যা দেখতে পাবেন

রিপোর্টটি ফাঁকা। npx ccusage@latest daily কোনো row না দেখালে বোঝায়, এটি Claude Code যেখানে লেখে সেখানে পড়ছে না। CLAUDE_CONFIG_DIR সেই অবস্থান পরিবর্তন করে, এবং parser-কে নতুন অবস্থান সম্পর্কে জানাতে হয়। row থাকলেও যদি প্রায় এক মাস আগের জায়গায় থেমে যায়, তাহলে সেটি cleanupPeriodDays-এর প্রত্যাশিত আচরণ: default হিসেবে 30 দিন পরে transcript মুছে ফেলা হয়।

দুটি মেশিনে ভিন্ন total দেখায়। এটি প্রত্যাশিত এবং bug নয়। /usage breakdown এবং যেকোনো log parser শুধু স্থানীয় session history পড়ে। তাই অন্য device বা claude.ai-এর usage কোনোটিতেই অন্তর্ভুক্ত হয় না।

স্থানীয় total invoice-এর সঙ্গে মেলে না। Contracted rate configure না করলে স্থানীয় figure standard list rate-এ token count থেকে হিসাব করা হয়: /usage-এর জন্য managed settings-এ একটি modelPricing table, অথবা ccusage-এর জন্য pricingOverrides। Subscription-এ plan limit-এর মধ্যে usage-এর জন্য token-ভিত্তিক billing হয় না; শুধু usage credit-এর জন্য billing হয়। API billing-এর ক্ষেত্রে Console-এর usage page-ই authoritative।

একই কাজ করেও cost বেড়েছে। প্রথমে cache column পরীক্ষা করুন। দীর্ঘ session-এ প্রতিটি turn-এর সময় পুরো history আবার পাঠানো হয়। Cache সক্রিয় থাকলে cached rate এবং cache ঠান্ডা হয়ে গেলে full input rate প্রযোজ্য হয়। তাই দীর্ঘ বিরতির পরে পুরো conversation আবার process করা হয়। এর ফলে ছোট output number-এর পাশে বড় input number দেখা যায়। input এবং output token pricing-এর পার্থক্য ব্যাখ্যা করে কেন দুটি আলাদাভাবে পরিবর্তিত হয়।

Subagent থাকা কোনো দিন অসম্ভব রকমের বেশি দেখায়। প্রতিটি subagent নিজের context window চালায়। তাই token use নির্ভর করে কতগুলো subagent চলেছে এবং প্রতিটি কতক্ষণ চলেছে তার ওপর। Plan-এ /usage attribution এই মেশিনের subagent share percentage হিসেবে দেখায়। প্রতিটি request-এর বিস্তারিত তথ্যের জন্য OTel data claude_code.token.usage-এর query_source attribute ব্যবহার করে subagent-গুলোকে আলাদা করে। Log parser শুধু total দেখাবে, ফলে কারণ আপনাকেই অনুমান করতে হবে।

FAQ

ccusage কি Max plan-এ আমার প্রকৃত বিল কত হয়েছে তা দেখায়?

না। Subscription-এর plan limit-এর মধ্যে ব্যবহার করা token-ভিত্তিকভাবে বিল করা হয় না। তাই log parser আপনার token-গুলোর মূল্য standard list API rate অনুযায়ী হিসাব করে এবং একই কাজ API-এর মাধ্যমে করলে যত খরচ হতো তা দেখায়। কোনো দিন ব্যবহার কতটা বেশি ছিল, তার আপেক্ষিক তুলনার জন্য এটি কার্যকর। Project বা model একে অপরের সঙ্গে তুলনা করতেও এটি সাহায্য করে। আপনাকে প্রকৃতপক্ষে কত দিতে হবে তা জানতে API billing-এর জন্য Console usage page এবং subscription billing-এর জন্য plan billing page দেখুন। Usage credit চালু থাকলে limit অতিক্রম করা ব্যবহার standard API rate অনুযায়ী বিল করা হয়। claude.ai সেই খরচ Settings > Usage-এর অধীনে দেখায়।

Claude Code যে session file পড়ে, সেগুলো কোথায় সংরক্ষণ করে?

~/.claude/projects/<project>/<session-id>.jsonl-এ। এখানে <project> হলো working directory path, যেখানে alphanumeric নয় এমন character-গুলো - দিয়ে প্রতিস্থাপিত হয়। প্রতিটি line একটি message, tool use বা metadata entry-এর জন্য একটি JSON object। CLAUDE_CONFIG_DIR পুরো directory সরিয়ে দেয়। settings.json-এর মধ্যে cleanupPeriodDays 30-day retention নিয়ন্ত্রণ করে। Anthropic entry format-কে internal এবং version পরিবর্তনের সঙ্গে পরিবর্তনশীল হিসেবে নথিবদ্ধ করেছে। তাই নিজের script না লিখে রক্ষণাবেক্ষণ করা কোনো tool দিয়ে এটি parse করুন।

আমি কি Claude Code telemetry Langfuse-এ পাঠাতে পারি?

Default telemetry দিয়ে নয়। Langfuse OTLP endpoint trace গ্রহণ করে। কিন্তু Claude Code defaultভাবে span-এর বদলে metrics এবং log event export করে। তাই সেই data সংরক্ষণের কোনো গন্তব্য থাকে না। Span export একটি beta feature, যা আপনাকে নিজে চালু করতে হবে। অন্যদিকে Langfuse-এর নিজস্ব Claude Code integration একটি Stop hook ব্যবহার করে session transcript-কে trace-এ রূপান্তর করে। Spend total-এর জন্য Claude Code metrics একটি OpenTelemetry collector-এ পাঠিয়ে Prometheus-এ সংরক্ষণ করুন। API-তে নিজের তৈরি agent-এর জন্য Langfuse ব্যবহার করুন। সেখানে আপনার code prompt, model এবং cost বহনকারী span তৈরি করতে পারে।

আমার local number Console usage page-এর সঙ্গে মেলে না কেন?

কারণ দুই জায়গায় হিসাবের পদ্ধতি আলাদা। /usage এবং log parser আপনার ব্যবহৃত machine-এর session file থেকে token count যোগ করে। Contracted rate configure করা না থাকলে তারা standard list rate ব্যবহার করে। Managed settings-এ /usage-এর জন্য modelPricing অথবা ccusage-এর জন্য pricingOverrides ব্যবহার করা হয়। Console discount প্রয়োগের পরে, সব machine এবং সব key মিলিয়ে আপনার organisation-কে প্রকৃতপক্ষে যে amount charge করা হয়েছে তা দেখায়। তাই অমিল স্বাভাবিক। অমিল খুব বড় হলে সাধারণত কারণ হয় দ্বিতীয় কোনো device, একটি CI runner অথবা একই account-এ billing করা অন্য কোনো team member।

CI-তে claude -p run-এর cost কীভাবে track করব?

--output-format json দিয়ে এটি চালান এবং result থেকে total_cost_usd পড়ুন। উদাহরণস্বরূপ, claude -p "..." --output-format json | jq '.total_cost_usd' ব্যবহার করতে পারেন। একই payload-এ প্রতি model-এর breakdown এবং session ID-ও থাকে। প্রতি job-এর জন্য ওই value record করলে কোনো agent, dashboard বা অতিরিক্ত service ছাড়াই প্রতি pipeline-এর spend হিসাব করতে পারবেন।