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 আবার পাঠায়। তাই আপনি নিজে type না করা context-ও bill-এর পরিমাণ নির্ধারণ করে। Subscription-এ আবার কোনো dollar figure থাকে না; শুধু একটি usage bar থাকে, যা কিছু দিনে অন্য দিনের তুলনায় দ্রুত কমে যায়। তিনটি tool-এর প্রতিটিই এই ঘাটতির আলাদা অংশ পূরণ করে।

আকৃতি 1: একটি স্থানীয় log parser আজকের ব্যবহারের খরচ জানায়

Claude Code প্রতিটি conversation JSON Lines (JSONL) হিসেবে ~/.claude/projects/<project>/<session-id>.jsonl-এ সংরক্ষণ করে, যেখানে <project> হলো আপনার working directory path; এতে alphanumeric নয় এমন অক্ষরগুলো - দিয়ে প্রতিস্থাপিত থাকে। ওই ফাইলের প্রতিটি 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 তারিখ অনুযায়ী মোট হিসাব দেখায়। --breakdown প্রতিটি row-কে model অনুযায়ী ভাগ করে। এর মাধ্যমে বোঝা যায়, সপ্তাহের বেশির ভাগ খরচ হয়তো এক বিকেলের Opus ব্যবহারে হয়েছে। blocks subscription reset হওয়া পাঁচ ঘণ্টার window অনুযায়ী group করে। session conversation অনুযায়ী মোট হিসাব দেখায়, আর --instances project অনুযায়ী group করে; এতে কোন repository বেশি খরচ করছে তা বোঝা যায়। পরিসর নির্ধারণ করতে --since এবং --until যোগ করুন। আপনার version যে date format প্রত্যাশা করে, তার জন্য npx ccusage@latest daily --help চালান। August 2026 অনুযায়ী এটি Codex ও OpenCode-সহ অন্যান্য agent CLI-ও পড়তে পারে। আপনি এগুলোর তুলনা করলে এই সুবিধাটি গুরুত্বপূর্ণ।

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

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

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

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

সবশেষে, subscription-এর ক্ষেত্রে dollar figure-টি একটি সতর্কতা সহকারে বিবেচনা করতে হবে। Pro বা Max-এ আপনাকে token অনুযায়ী বিল করা হয় না। তাই এই সংখ্যা list API rate অনুযায়ী আপনার token ব্যবহারের সম্ভাব্য খরচ দেখায়। এটি আপনার ব্যবহারের মাত্রা পরিমাপ করে। এটি আপনার প্রকৃত bill নয়। আসল প্রশ্ন যদি হয় কোন plan ব্যবহার করবেন, তাহলে সেটি আলাদা একটি তুলনা। দেখুন API billing এবং Claude subscription-এর তুলনা।

পদ্ধতি 2: বিল্ট-ইন usage screen দেখেই বোঝা যায় কোন model বাজেট বেশি ব্যবহার করেছে

Claude Code নিজস্ব reporting ব্যবস্থা সরবরাহ করে, কিন্তু অধিকাংশ ব্যবহারকারী সেটি খোলেন না। একটি session-এর মধ্যে /usage চালান। উপরের Session block-এ model অনুযায়ী token-এর সংখ্যা এবং বর্তমান session-এর dollar amount দেখা যায়। এই হিসাব token count এবং standard list rate ব্যবহার করে স্থানীয়ভাবে করা হয়। এতে discount বা promotional pricing ধরা হয় না, তাই এটি আপনার invoice-এর সঙ্গে ভিন্ন হতে পারে। /clear শুরু করে নতুন conversation চালু করলে total আবার শূন্য থেকে গণনা হয়।

Pro, Max, Team বা Enterprise plan-এ একই screen-এ আপনার plan limit-এর কতটা ব্যবহার হয়েছে তা দেখা যায়। সাম্প্রতিক usage-এর কত শতাংশ skills, subagents, plugins এবং পৃথক MCP server থেকে এসেছে, সেটিও দেখানো হয়। দীর্ঘ context বা cache miss-এর মতো যেসব আচরণ সাম্প্রতিক usage-এর 10% বা তার বেশি তৈরি করে, সেগুলো চিহ্নিত করা হয়। গত 24 hours এবং গত 7 days-এর মধ্যে বদলাতে d বা w চাপুন। এই সংখ্যা আনুমানিক এবং এই machine-এর স্থানীয় session history থেকে গণনা করা হয়, তাই দ্বিতীয় device-এর usage এতে ধরা হয় না। bar একেবারে খালি থাকলে, শুধু কম থাকলে নয়, 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 পাওয়া যায়। Teams এবং Enterprise plan-এ admin console-এ spend report পাওয়া যায়। এতে CSV export আছে এবং report প্রতিদিন update হয়। Enterprise-এ analytics API-ও যোগ হয়। কোনটি দেখতে পাবেন তা নির্ভর করে প্রতিটি developer কীভাবে sign in করেছেন তার ওপর। তাই mixed organisation-এ দুটি report পড়ে হাতে যোগ করতে হয়।

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

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

পদ্ধতি 3: আপনার নিজস্ব OpenTelemetry stack দেখায় কোন prompt-এর কর্মক্ষমতা খারাপ হয়েছে

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

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

এ বিষয়ে একটি সংশোধন করা দরকার, কারণ প্রায় প্রতিটি আলোচনায় এই প্রশ্ন ওঠে। Langfuse একটি ভালো self-hosted tracing backend, এবং VPS-এ এটি চালানোর পদ্ধতি agent tracing-এর জন্য Langfuse self-host করা-এ দেখানো হয়েছে। এর OTLP endpoint শুধু traces গ্রহণ করে। Claude Code metrics এবং log events export করে, spans নয়। তাই OTEL_EXPORTER_OTLP_ENDPOINT-কে Langfuse-এর দিকে নির্দেশ করলে project ফাঁকা থাকবে এবং পড়ার মতো কোনো error পাবেন না। API ব্যবহার করে নিজে তৈরি করা agent-এর জন্য Langfuse উপযুক্ত tool, কারণ সেখানে আপনার নিজের code প্রতিটি span-এ prompt, model এবং cost যোগ করে। Claude Code CLI-এর ক্ষেত্রে metrics store-ই উপযুক্ত।

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

দুটি service যথেষ্ট: metrics গ্রহণ করার জন্য একটি collector এবং সেগুলো সংরক্ষণের জন্য Prometheus। দুটিকেই public Internet থেকে বিচ্ছিন্ন রাখুন, কারণ কোনো open 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 Compose network-এর মাধ্যমে service name ব্যবহার করে 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. থাকা উচিত। Configuration 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_ দিয়ে শুরু হওয়া কয়েকটি name পাওয়ার কথা। Exporter dot-গুলোকে underscore-এ রূপান্তর করে এবং unit যোগ করে, তাই সঠিক string আপনার collector version-এর ওপর নির্ভর করে। ফলাফল খালি হলে কোনো data পৌঁছায়নি। Protocol এবং port পরস্পরের সঙ্গে মিলে কি না পরীক্ষা করুন, কারণ http/protobuf 4318-এ যায় এবং grpc 4317-এ যায়; mismatch হলে কোনো স্পষ্ট error ছাড়াই কাজ ব্যর্থ হয়। claude --debug চালান; debug log-এ OTel export error দেখা যাবে।

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

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

স্ক্রিপ্ট এবং CI run-এর খরচ ট্র্যাক করা

Non-interactive run-গুলোই সাধারণত ব্যবহারকারীদের অবাক করে, কারণ কেউ স্ক্রিন দেখছে না। 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 থাকে। তাই কোনো dashboard ছাড়াই একটি CI job নিজের খরচ record করতে পারে। মানটি একটি file-এ append করুন, অথবা উপরের collector-এ metric হিসেবে পাঠান। এটিই ব্যবহারযোগ্য spend tracking-এর সবচেয়ে কম খরচের পদ্ধতি। প্রতি run-এ একটি jq call লাগে।

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

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

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

Local total invoice-এর সঙ্গে মেলে না। Local figure standard list rate অনুযায়ী token count থেকে গণনা করা হয়। এতে promotional pricing বা contracted discount সম্পর্কে কোনো তথ্য থাকে না। Subscription ব্যবহার করলে token আলাদাভাবে bill-ও করা হয় না। API billing-এর জন্য Console usage page-ই authoritative।

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

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

FAQ

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

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

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

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

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

সরাসরি নয়। Langfuse OTLP endpoint trace গ্রহণ করে। Claude Code span-এর পরিবর্তে metric এবং log event export করে। তাই এই data সংরক্ষণের উপযুক্ত স্থান থাকে না। Claude Code metric একটি OpenTelemetry collector-এ পাঠিয়ে Prometheus-এ সংরক্ষণ করুন। API-এর ওপর নিজে তৈরি করা agent-এর জন্য Langfuse ব্যবহার করুন। সেখানে আপনার নিজের code prompt, model এবং cost বহনকারী span তৈরি করতে পারে।

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

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

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

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