Claude Code spend tracking tools کا موازنہ

Claude Code کا spend tracker اصل میں کیا پڑھتا ہے

ہر Claude Code spend tracker تین میں سے کسی ایک data source کو پڑھتا ہے، اور source یہ طے کرتا ہے کہ وہ کس سوال کا جواب دے سکتا ہے۔ log parser آپ کی اپنی disk پر موجود session transcript files پڑھتا ہے۔ dashboard وہ usage records پڑھتا ہے جو Anthropic آپ کے account یا organisation کے لیے محفوظ رکھتا ہے۔ metrics backend وہ OpenTelemetry (OTel) stream پڑھتا ہے جو آپ اسے فعال کرنے پر Claude Code خارج کرتا ہے۔ یہ تینوں بیک وقت درست ہو سکتے ہیں اور پھر بھی ایک دوسرے سے مختلف نتائج دے سکتے ہیں، کیونکہ یہ مختلف چیزیں شمار کر رہے ہوتے ہیں۔

یہ guide tokens کی دوبارہ وضاحت نہیں کرتی۔ Claude Code token usage کیسے شمار کرتا ہے میں input، output، cache writes اور cache reads کا احاطہ کیا گیا ہے، اور اس حصے کے واضح ہونے تک کوئی dashboard زیادہ مفید نہیں ہوتا۔ یہاں سوال زیادہ محدود ہے: ہر قسم کا tool کیا دیکھ سکتا ہے، اور وہ کیا کبھی نہیں دیکھ سکتا۔

ایک ہی دن میں Claude Code کے خرچ کو track کرنے والے تین ٹولز کیوں سامنے آئے

ایک ہی دن Claude Code کے خرچ کو track کرنے والے تین الگ ٹولز جاری ہوئے۔ یہ ایک ہی ٹول کے تین ورژن نہیں تھے، اور یہی بات اہم ہے۔ ایک ٹول مقامی session files کو parse کرتا تھا۔ دوسرا account usage screens کو wrap کرتا تھا۔ تیسرا hosted tracing backend تھا جسے آپ خود چلاتے ہیں۔

یہ تینوں اس لیے ایک ساتھ سامنے آئے کہ agent session کی لاگت اب واضح نہیں رہی تھی۔ عام chat کی لاگت تقریباً اتنی ہی ہوتی ہے جتنی اسکرین پر دکھائی دیتی ہے۔ ایک agent بیس files پڑھتا ہے، test suite چلاتا ہے، اور ہر turn پر پوری conversation دوبارہ بھیجتا ہے؛ اس لیے bill ایسے context سے بڑھتا ہے جو آپ نے خود type نہیں کیا ہوتا۔ Subscription میں dollar figure بالکل نہیں ہوتا، صرف usage bar ہوتی ہے جو بعض دنوں میں دوسرے دنوں کے مقابلے میں زیادہ تیزی سے ختم ہوتی ہے۔ ان تینوں میں سے ہر ٹول اس غیر واضح حصے کے ایک مختلف پہلو کو پُر کرتا ہے۔

شکل 1: مقامی log parser بتاتا ہے کہ آج کتنا خرچ ہوا

Claude Code ہر conversation کو ~/.claude/projects/<project>/<session-id>.jsonl پر JSON Lines (JSONL) کی صورت میں محفوظ کرتا ہے، جہاں <project> آپ کی working directory کا path ہے اور اس میں موجود non-alphanumeric characters کو - سے replace کیا جاتا ہے۔ اس file میں ہر assistant turn اپنی request کے token counts رکھتا ہے۔ log parser ان counts کو جمع کرکے ان کی قیمت نکالتا ہے۔

ccusage وہ tool ہے جسے زیادہ تر لوگ استعمال کرتے ہیں۔ اسے install کرنے کی ضرورت نہیں:

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

daily تاریخ کے لحاظ سے totals دکھاتا ہے۔ --breakdown ہر row کو model کے لحاظ سے تقسیم کرتا ہے۔ اس طرح معلوم ہوتا ہے کہ ایک Opus afternoon ہفتے کے زیادہ تر استعمال کے برابر ہے۔ blocks ان پانچ گھنٹے کی windows کے لحاظ سے grouping کرتا ہے جن پر subscription reset ہوتی ہے۔ session ہر conversation کا total دکھاتا ہے، جبکہ --instances project کے لحاظ سے grouping کرتا ہے تاکہ معلوم ہو سکے کہ کون سا repository زیادہ مہنگا ہے۔ range محدود کرنے کے لیے --since اور --until شامل کریں، اور اپنی version کے مطلوبہ date format کے لیے npx ccusage@latest daily --help چلائیں۔ August 2026 تک یہ Codex اور OpenCode سمیت دیگر agent CLIs بھی پڑھتا ہے۔ اگر آپ ان کا موازنہ کر رہے ہیں تو یہ اہم ہے۔

قیمت model price table سے حاصل ہوتی ہے، اور tool میں cost کے تین modes ہیں۔ --mode auto اس وقت file میں Claude Code کی لکھی ہوئی costUSD value استعمال کرتا ہے جب وہ موجود ہو، اور موجود نہ ہونے پر token counts سے حساب کرتا ہے۔ --mode calculate ہمیشہ tokens سے حساب کرتا ہے اور recorded cost کو نظرانداز کرتا ہے۔ --mode display صرف recorded costs دکھاتا ہے اور جن rows میں cost موجود نہ ہو ان کے لیے $0.00 print کرتا ہے۔ اگر کوئی total غلط معلوم ہو تو اسی report کو پہلے calculate کے ساتھ اور پھر display کے ساتھ چلائیں۔ دونوں کے درمیان بڑا فرق اس بات کی علامت ہے کہ زیادہ تر entries میں recorded cost موجود نہیں، اس لیے آپ جو کچھ پڑھ رہے ہیں وہ estimate ہے۔

یہی data آپ کے prompt کو بھی فراہم کیا جا سکتا ہے۔ ccusage statusline Claude Code status bar کے لیے ایک مختصر line print کرتا ہے، جسے ~/.claude/settings.json میں کسی بھی دوسری status line command کی طرح شامل کیا جا سکتا ہے۔ settings block اور اسے ملنے والے fields کے لیے Claude Code statusline بنانا دیکھیں۔

log parser وہ data نہیں دیکھ سکتا جو اس machine پر موجود ہی نہ ہو۔ دوسرا laptop، claude.ai پر session، یا کسی teammate کا کام: ان کے transcripts ان machines کی disks پر محفوظ ہوتے ہیں۔ پرانا data بھی موجود نہیں رہتا، کیونکہ cleanupPeriodDays setting کے تحت transcripts کو default طور پر 30 days بعد clean up کر دیا جاتا ہے۔ اس لیے last quarter کا data موجود نہیں ہوگا، جب تک آپ نے اسے archive نہ کیا ہو۔

ایک اور risk ہے، اور یہ ساخت سے متعلق ہے۔ Anthropic کی documentation کے مطابق entry format Claude Code کے اندرونی استعمال کے لیے ہے اور versions کے درمیان تبدیل ہو سکتا ہے۔ اس لیے جو scripts ان files کو براہ راست parse کرتی ہیں، وہ کسی بھی release میں break ہو سکتی ہیں۔ یہ risk اس نوعیت کے ہر tool پر لاگو ہوتا ہے۔ اسی وجہ سے JSONL پر مبنی خود تیار کردہ jq one-liner جتنا مناسب نظر آتا ہے، حقیقت میں اس سے بدتر انتخاب ہے۔ maintained parsers format میں ہونے والی تبدیلیوں کو آپ کے لیے track کرتے ہیں، جبکہ field کا نام تبدیل ہوتے ہی آپ کا one-liner اعتماد کے ساتھ غلط number report کرے گا۔

آخر میں subscription کے معاملے میں dollar figure کی ایک وضاحت ضروری ہے۔ Pro یا Max پر آپ سے فی token billing نہیں کی جاتی، اس لیے یہ number اس لاگت کو ظاہر کرتا ہے جو list API rates کے مطابق آپ کے tokens کی بنتی۔ یہ آپ کے استعمال کی شدت ناپتا ہے۔ یہ آپ کا bill نہیں ہے۔ اگر اصل سوال یہ ہے کہ کون سا plan اختیار کرنا چاہیے، تو اس کا موازنہ الگ exercise ہے: API billing اور Claude subscription کا موازنہ دیکھیں۔

شکل 2: built-in usage screens بتاتی ہیں کہ budget کس model نے خرچ کیا

Claude Code اپنی reporting فراہم کرتا ہے، لیکن زیادہ تر لوگ اسے کبھی نہیں کھولتے۔ کسی session کے اندر /usage چلائیں۔ اوپر موجود Session block موجودہ session کے لیے model کے لحاظ سے tokens اور dollar figure دکھاتا ہے۔ یہ figure standard list rates پر مقامی طور پر token counts سے calculate ہوتی ہے۔ اس میں discount یا promotional pricing شامل نہیں ہوتی، اس لیے یہ آپ کے invoice سے مختلف ہو سکتی ہے۔ /clear نئی conversation شروع کرنے پر totals reset ہو جاتے ہیں۔

Pro، Max، Team یا Enterprise plan میں یہی screen یہ بھی دکھاتی ہے کہ آپ نے plan limit کا کتنا حصہ استعمال کیا ہے۔ یہ حالیہ usage کو skills، subagents، plugins اور انفرادی MCP servers سے total کے percentage کے طور پر منسوب کرتی ہے۔ یہ ان behaviours کی نشاندہی کرتی ہے جو حالیہ usage کا 10% یا اس سے زیادہ حصہ بنتے ہیں، مثلاً long context یا cache misses۔ آخری 24 hours اور آخری 7 days کے درمیان تبدیل ہونے کے لیے d یا w دبائیں۔ یہ figures approximate ہیں اور اس machine کی local session history سے calculate ہوتی ہیں، اس لیے دوسرے device کا usage شامل نہیں ہوتا۔ جب bar صرف کم ہونے کے بجائے خالی ہو، تو screen بتاتی ہے کہ window بند ہو گئی ہے، لیکن یہ نہیں بتاتی کہ کام کیسے جاری رکھنا ہے۔ limit تک پہنچنے کے بعد کیا کرنا ہے model، context اور plan سے متعلق ایک الگ فیصلہ ہے۔

ایک developer سے زیادہ ہونے پر یہ numbers account کی سطح پر منتقل ہو جاتے ہیں۔ API organisation کو Console usage page، spend اور ہر member کی accepted lines کے ساتھ Claude Code dashboard، اور admin key کے ذریعے وہی روزانہ کے per-user metrics واپس کرنے والی Claude Code Analytics API ملتی ہے۔ Teams اور Enterprise plans میں admin console کے اندر CSV export کے ساتھ spend report ملتی ہے، جو روزانہ update ہوتی ہے۔ Enterprise میں analytics API بھی شامل ہے۔ آپ کو ان میں سے کون سی معلومات نظر آتی ہے، یہ اس بات پر منحصر ہے کہ ہر developer نے sign in کیسے کیا۔ اس لیے mixed organisation میں دو reports دیکھ کر totals دستی طور پر جمع کرنے پڑتے ہیں۔

Budget کا حجم مقرر کرتے وقت Anthropic کی cost documentation میں August 2026 تک شائع شدہ figure یہ ہے کہ فی developer فی active day اوسط تقریباً $13، اور فی developer فی month $150 سے $250 ہے۔ 90% users کی لاگت فی active day $30 سے کم رہتی ہے۔ اسے enterprise deployments سے حاصل شدہ published benchmark سمجھیں، اپنی team کے لیے prediction نہیں۔ Pilot group چلائیں اور extrapolate کرنے سے پہلے پیمائش کریں۔

Dashboards day اور person سے کم سطح کی کوئی چیز نہیں دیکھ سکتے۔ وہ بتا دیں گے کہ Tuesday کے زیادہ تر وقت Opus استعمال ہوا۔ لیکن یہ نہیں بتائیں گے کہ اسے کس prompt، repository یا CI job نے استعمال کیا۔ ان میں تاخیر بھی ہوتی ہے، کیونکہ organisation reports روزانہ update ہوتی ہیں۔ اس لیے یہ review tool ہیں، آج دوپہر runaway agent پکڑنے کا طریقہ نہیں۔ Runaway agent کو پکڑنے کے لیے reports نہیں بلکہ limits درکار ہیں۔ اسی موضوع پر VPS پر agent costs کو محدود رکھنا ہے۔

شکل 3: آپ کا اپنا OpenTelemetry stack بتاتا ہے کہ کون سا prompt regression کا سبب بنا

ایک environment variable set کرنے کے بعد Claude Code، OpenTelemetry metrics اور events جاری کرتا ہے۔ یہ واحد آپشن ہے جو فی صارف token اور cost data کو تقریباً real time میں آپ کے زیر انتظام system تک پہنچاتا ہے۔ 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 کا کتنا حصہ subagents کا ہے، آپ کی اپنی turns کا نہیں؛ کیا کسی ایک MCP server نے آپ کے input tokens دگنے کر دیے؛ اور کیا کسی نے CLAUDE.md میں ترمیم کرنے کے بعد cache reads کم ہو گئے۔ عموماً اصل حیرت cache behavior میں چھپی ہوتی ہے، اور prompt caching کب اپنے اخراجات پورے کرتی ہے میں بتایا گیا ہے کہ آپ کس چیز کا جائزہ لے رہے ہیں۔

ایک تصحیح ضروری ہے، کیونکہ اس موضوع پر ہونے والی ہر گفتگو میں یہ بات سامنے آتی ہے۔ Langfuse ایک اچھا self-hosted tracing backend ہے، اور اسے VPS پر چلانے کا طریقہ agent tracing کے لیے Langfuse کو self-host کرنے میں دیا گیا ہے۔ اس کا OTLP endpoint صرف traces قبول کرتا ہے۔ Claude Code، spans کے بجائے metrics اور log events export کرتا ہے۔ اس لیے OTEL_EXPORTER_OTLP_ENDPOINT کو Langfuse کی طرف point کرنے سے project خالی رہتا ہے اور آپ کو پڑھنے کے قابل کوئی error نہیں ملتا۔ Langfuse ان agents کے لیے درست tool ہے جو آپ خود API پر بناتے ہیں، جہاں آپ کا اپنا code ہر span کو اس کے prompt، model اور cost کے ساتھ create کرتا ہے۔ Claude Code CLI کے لیے metrics store زیادہ موزوں ہے۔

اپنے VPS پر Claude Code کے اخراجات کی tracking ترتیب دیں

دو services کافی ہیں: metrics وصول کرنے کے لیے ایک collector، اور انہیں محفوظ کرنے کے لیے Prometheus۔ دونوں کو public internet سے دور رکھیں، کیونکہ کھلا OTLP port اسے تلاش کرنے والے ہر شخص سے writes قبول کرتا ہے۔ /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 آپ کی machines سے قابلِ رسائی ہے اور کسی دوسرے مقام سے نہیں۔ port کے سامنے دیا گیا address یہاں اہم کام کرتا ہے، کیونکہ published Docker ports کو ufw filter نہیں کرتا: دیکھیں Docker کے published ports 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. پر ہونا چاہیے۔ Config error پر رک جانے والا log بتاتا ہے کہ YAML parse نہیں ہوئی، اور container مسلسل restart loop میں چلا جائے گا۔

اب 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_ سے شروع ہونے والے کئی names ملنے چاہییں۔ Exporter dots کو underscores میں تبدیل کرتا ہے اور unit شامل کرتا ہے، اس لیے exact strings آپ کے collector version پر منحصر ہوتی ہیں۔ خالی result کا مطلب ہے کہ کچھ بھی نہیں پہنچا۔ تصدیق کریں کہ protocol اور port ایک دوسرے سے مطابقت رکھتے ہیں، کیونکہ http/protobuf 4318 پر جاتا ہے اور grpc 4317 پر، اور عدم مطابقت خاموشی سے failure کا سبب بنتی ہے۔ claude --debug چلائیں؛ debug log OTel export errors رپورٹ کرے گا۔

ایک machine اور کسی server کے بغیر استعمال کے لیے اوپر کے تمام مراحل چھوڑ دیں۔ OTEL_METRICS_EXPORTER=prometheus set کریں؛ Claude Code خود http://localhost:9464/metrics پر scrape endpoint فراہم کرے گا۔ جب prometheus واحد listed exporter ہو، تو Claude Code metrics names سے USD، tokens اور s units نکال دیتا ہے، تاکہ scrape درست Prometheus text format میں رہے۔

اس configuration کے ساتھ privacy کا ایک فیصلہ بھی شامل ہے۔ Default طور پر machine سے صرف counts باہر جاتے ہیں؛ prompt text اور tool output نہیں جاتے۔ OTEL_LOG_USER_PROMPTS=1 اور OTEL_LOG_TOOL_CONTENT=1 اس رویے کو تبدیل کرتے ہیں، جس کے بعد آپ کے metrics box میں source code اور context میں موجود دیگر تمام مواد شامل ہو سکتا ہے۔ انہیں سوچ سمجھ کر فعال کریں، اور پہلے agent context میں secrets رکھنے سے گریز پڑھیں۔

اسکرپٹ شدہ اور CI رنز کے اخراجات کا سراغ رکھنا

غیر تعاملی رنز لوگوں کو اس لیے حیران کرتے ہیں کہ اسکرین کی نگرانی کرنے والا کوئی موجود نہیں ہوتا۔ claude -p کو --output-format json کے ساتھ استعمال کرنے سے اس رن کی لاگت اس کے نتیجے کے payload میں مل جاتی ہے:

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

اس payload میں total_cost_usd اور ہر model کے حساب سے تفصیل شامل ہوتی ہے، اس لیے CI job کسی dashboard کے بغیر اپنے اخراجات ریکارڈ کر سکتی ہے۔ اس قدر کو کسی file میں شامل کریں، یا اسے اوپر موجود collector کو metric کے طور پر بھیجیں۔ یہ دستیاب اخراجات کی نگرانی کا سب سے کم لاگت والا مفید طریقہ ہے، اور اس کے لیے ہر run پر ایک jq call درکار ہوتی ہے۔

خرابی کی صورتیں اور آپ کو کیا نظر آئے گا

رپورٹ خالی ہے۔ npx ccusage@latest daily کا کوئی row نہ دکھانا اس بات کی علامت ہے کہ یہ اس مقام سے data نہیں پڑھ رہا جہاں Claude Code اسے لکھتا ہے۔ CLAUDE_CONFIG_DIR اس مقام کو تبدیل کرتا ہے، اور parser کو اس مقام کے بارے میں بتانا ضروری ہے۔ اگر rows موجود ہوں لیکن تقریباً ایک ماہ پر رک جائیں تو یہ cleanupPeriodDays کا متوقع طریقۂ کار ہے: transcripts کو default طور پر 30 دن بعد حذف کر دیا جاتا ہے۔

دو machines مختلف totals دکھاتی ہیں۔ یہ متوقع ہے اور bug نہیں ہے۔ /usage اور کوئی بھی log parser صرف local session history پڑھتے ہیں، اس لیے کسی دوسرے device یا claude.ai کا usage دونوں میں شامل نہیں ہوتا۔

local total invoice سے مطابقت نہیں رکھتا۔ local figures standard list rates پر token counts سے calculate کیے جاتے ہیں۔ ان میں promotional pricing یا contracted discount کا علم نہیں ہوتا، اور subscription میں tokens کی الگ الگ billing ہوتی ہی نہیں۔ API billing کے لیے Console usage page مستند ذریعہ ہے۔

ایک ہی کام کرنے کے باوجود cost بڑھ گئی۔ سب سے پہلے cache columns دیکھیں۔ ایک طویل session ہر turn پر اپنی پوری history دوبارہ بھیجتا ہے۔ cache گرم ہونے تک اس پر cached rate لاگو ہوتا ہے، اور cache ٹھنڈا ہونے کے بعد full input rate لاگو ہوتا ہے۔ اس لیے ایک طویل وقفے کے بعد پوری conversation دوبارہ process ہوتی ہے۔ یہ بڑے input number اور چھوٹے output number کی صورت میں ظاہر ہوتا ہے، اور input اور output token pricing کا تقابل واضح کرتا ہے کہ دونوں الگ الگ کیوں تبدیل ہوتے ہیں۔

subagents والے دن کا usage ناممکن معلوم ہوتا ہے۔ ہر subagent اپنی context window چلاتا ہے، اس لیے token use اس بات کے ساتھ بڑھتا ہے کہ کتنے subagents چلے اور ہر ایک کتنی دیر چلا۔ صرف OTel data انہیں الگ دکھاتا ہے، اور یہ query_source attribute کے ذریعے claude_code.token.usage میں ہوتا ہے۔ log parser آپ کو total دکھائے گا اور باقی وجہ کا اندازہ آپ کو خود لگانا ہوگا۔

FAQ

کیا ccusage یہ دکھاتا ہے کہ Max plan پر مجھ سے اصل میں کتنی رقم وصول کی جائے گی؟

نہیں۔ Subscription میں آپ سے فی token رقم وصول نہیں کی جاتی، اس لیے log parser آپ کے tokens کی قیمت standard list API rates کے مطابق لگاتا ہے اور دکھاتا ہے کہ یہی کام API کے ذریعے کرنے پر کتنی لاگت آتی۔ یہ اس بات کی اچھی نسبتی پیمائش ہے کہ کوئی دن کتنا زیادہ مصروف رہا، اور projects یا models کا باہمی موازنہ کرنے میں مفید ہے۔ آپ سے واجب الادا رقم کے لیے Console usage page API billing کا احاطہ کرتا ہے، جبکہ plan billing page subscription کی billing دکھاتا ہے۔

یہ tools جن session files کو پڑھتے ہیں، Claude Code انہیں کہاں محفوظ کرتا ہے؟

~/.claude/projects/<project>/<session-id>.jsonl میں، جہاں <project> working directory path ہے اور اس میں موجود non-alphanumeric characters کو - سے بدل دیا جاتا ہے۔ ہر line ایک message، tool use یا metadata entry کے لیے ایک JSON object ہوتی ہے۔ CLAUDE_CONFIG_DIR پوری directory منتقل کرتا ہے، جبکہ cleanupPeriodDays، settings.json میں 30-day retention کو control کرتا ہے۔ Anthropic entry format کو internal اور versions کے درمیان تبدیل ہونے کے قابل قرار دیتا ہے، اس لیے اسے اپنی script کے بجائے maintained tool سے parse کریں۔

کیا میں Claude Code telemetry کو Langfuse پر بھیج سکتا ہوں؟

براہ راست نہیں۔ Langfuse OTLP endpoint traces قبول کرتا ہے، جبکہ Claude Code spans کے بجائے metrics اور log events export کرتا ہے، اس لیے اس data کے لیے کوئی مناسب destination نہیں ہوتا۔ Claude Code metrics کو OpenTelemetry collector پر بھیجیں اور انہیں Prometheus میں محفوظ کریں۔ Langfuse ان agents کے لیے استعمال کریں جو آپ API پر خود بناتے ہیں، جہاں آپ کا اپنا code ایسے spans خارج کرتا ہے جن میں prompt، model اور cost شامل ہوتے ہیں۔

میرے local numbers Console usage page سے کیوں نہیں ملتے؟

کیونکہ دونوں کا حساب مختلف طریقے سے ہوتا ہے۔ /usage اور log parsers آپ کے موجودہ machine پر session files سے token counts جمع کرتے ہیں، پھر ان کی قیمت standard list rates کے مطابق لگاتے ہیں۔ Console آپ کی organisation سے حقیقت میں وصول کی گئی رقم دکھاتا ہے، جس میں ہر machine اور ہر key شامل ہوتی ہے، اور کسی بھی discount کے بعد حساب کیا جاتا ہے۔ فرق ہونا معمول ہے۔ بہت بڑا فرق عموماً اس بات کی نشاندہی کرتا ہے کہ کوئی دوسرا 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 میں ہر model کی breakdown اور session ID بھی شامل ہوتی ہے۔ اس value کو ہر job کے لیے record کریں؛ اس طرح کسی agent، dashboard یا اضافی service کے بغیر ہر pipeline کا خرچ معلوم ہو جائے گا۔