Claude Code spend tracking tools: কোনটি বেছে নেবেন

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

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

এই guide-এ token সম্পর্কে আবার ব্যাখ্যা করা হয়নি। 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 থাকলে কোনো dollar figure-ই দেখা যায় না; শুধু একটি usage bar থাকে, যা কোনো দিন দ্রুত এবং কোনো দিন ধীরে কমে। তিনটি tool-এর প্রতিটি এই অদৃশ্য ব্যবধানের আলাদা একটি অংশ পূরণ করে।

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

Claude Code প্রতিটি conversation-কে JSON Lines (JSONL) হিসেবে ~/.claude/projects/<project>/<session-id>.jsonl-এ সংরক্ষণ করে। এখানে <project> হলো আপনার working directory path, যেখানে alphanumeric নয় এমন অক্ষরগুলো - দিয়ে প্রতিস্থাপিত হয়। ওই 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 তারিখ অনুযায়ী মোট হিসাব করে। --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-ও পড়তে পারে। আপনি এগুলোর তুলনা করলে এই সুবিধাটি গুরুত্বপূর্ণ।

Pricing একটি 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 প্রিন্ট করে। কোনো total ভুল মনে হলে একই report প্রথমে calculate দিয়ে এবং পরে display দিয়ে চালান। দুই ফলাফলের মধ্যে বড় পার্থক্য থাকলে বুঝবেন অধিকাংশ 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 ওই device-গুলোতেই থাকে। পুরোনো data-ও অনুপস্থিত থাকতে পারে। কারণ cleanupPeriodDays setting অনুযায়ী defaultভাবে 30 দিন পর transcript পরিষ্কার করা হয়। তাই archive না করলে গত quarter-এর data আর থাকবে না।

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

সবশেষে, subscription-এর ক্ষেত্রে dollar figure-টি একটি সতর্কতা সহ দেখতে হবে। Pro বা Max-এ আপনি token অনুযায়ী bill পান না। তাই এই সংখ্যা হলো 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 দেখা যায়। এটি standard list rate-এ token count ব্যবহার করে locally হিসাব করা হয়। এই amount-এ discount বা promotional pricing ধরা হয় না। তাই এটি আপনার invoice-এর amount থেকে আলাদা হতে পারে। /clear চালিয়ে নতুন conversation শুরু হলে total আবার শূন্য থেকে গণনা হয়।

Pro, Max, Team বা Enterprise plan-এ একই screen-এ plan limit-এর কতটা ব্যবহার করেছেন তা দেখা যায়। Recent usage-এর কত শতাংশ skills, subagents, plugins এবং পৃথক MCP server-এর জন্য হয়েছে, সেটিও দেখায়। Long context বা cache miss-এর মতো যেসব আচরণ recent usage-এর 10% বা তার বেশি তৈরি করে, সেগুলো চিহ্নিত করা হয়। গত 24 ঘণ্টা এবং গত 7 দিনের মধ্যে পরিবর্তন করতে d অথবা w চাপুন। এই পরিসংখ্যান আনুমানিক। এগুলো এই machine-এর local session history থেকে হিসাব করা হয়, তাই দ্বিতীয় device-এর ব্যবহার এতে অন্তর্ভুক্ত হয় না।

একজনের বেশি 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 পাওয়া যায়। Enterprise-এ analytics API-ও থাকে। প্রতিটি developer কীভাবে sign in করেছেন, তার ওপর নির্ভর করে আপনি কোন report দেখতে পাবেন। তাই mixed organisation-এ দুটি report পড়ে হাতে করে যোগ করতে হয়।

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

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

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

একটি environment variable সেট করলেই Claude Code OpenTelemetry metrics এবং events পাঠায়। আপনার নিয়ন্ত্রণাধীন কোনো system-এ per-user token ও cost data প্রায় real time-এ stream করার এটিই একমাত্র উপায়। Metrics-এর মধ্যে রয়েছে claude_code.cost.usage USD-তে, claude_code.token.usage token-এ, 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-এর কতটা subagent-এর কারণে হয়েছে, আপনার নিজের turn-এর কারণে নয়; একটি 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 থেকে আড়ালে রাখুন, কারণ উন্মুক্ত 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-টি এখানে কার্যকর ভূমিকা রাখে, কারণ প্রকাশিত Docker port-এ ufw filter প্রয়োগ করে না: দেখুন কেন Docker প্রকাশিত 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-এ প্রকাশ করা হয় না, কারণ 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 বারবার restart হতে থাকবে।

এখন Claude Code-কে এই endpoint ব্যবহার করতে বলুন। 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-এর ওপর নির্ভর করে। ফলাফল খালি হলে কোনো 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 রান-এর ব্যয় ট্র্যাক করা

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

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

এই payload-এ total_cost_usd এবং প্রতিটি model অনুযায়ী ব্যয়ের বিভাজন থাকে। তাই কোনো dashboard ছাড়াই একটি CI job নিজের ব্যয় রেকর্ড করতে পারে। মানটি একটি ফাইলে যোগ করুন, অথবা উপরের collector-এ metric হিসেবে পাঠান। ব্যবহারযোগ্য ব্যয় ট্র্যাকিংয়ের মধ্যে এটি সবচেয়ে কম খরচের পদ্ধতি, এবং প্রতি রান-এ একটি jq call লাগে।

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

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

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

স্থানীয় total invoice-এর সঙ্গে মেলে না। স্থানীয় পরিসংখ্যান standard list rate অনুযায়ী token count থেকে হিসাব করা হয়। এতে promotional pricing বা চুক্তিভিত্তিক 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-সহ একটি দিনের usage অসম্ভব মনে হয়। প্রতিটি subagent নিজস্ব context window চালায়। তাই কতগুলো subagent চলেছে এবং প্রতিটি কতক্ষণ চলেছে, তার সঙ্গে token use বাড়ে। শুধু 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-এর খরচ তুলনা করতেও এটি উপযোগী। আপনাকে প্রকৃতপক্ষে কত বিল দিতে হবে, তা জানতে API billing-এর জন্য Console usage page এবং subscription billing-এর জন্য plan billing page দেখুন।

এই tool-গুলো যে 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 পরিবর্তনের সঙ্গে পরিবর্তনশীল হিসেবে document করেছে। তাই নিজের 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 প্রয়োগের পর, প্রতিটি machine এবং প্রতিটি key মিলিয়ে আপনার organisation-কে প্রকৃতপক্ষে যে অর্থ বিল করা হয়েছে, তা দেখায়। তাই অমিল স্বাভাবিক। অমিল খুব বড় হলে সাধারণত দ্বিতীয় কোনো 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 পাওয়া যাবে।