مقایسه ابزارهای ردیابی هزینه Claude Code

ردیاب‌های هزینه Claude Code دقیقاً چه چیزی را می‌خوانند

هر ردیاب هزینه Claude Code یکی از سه منبع داده را می‌خواند و همین منبع تعیین می‌کند که ردیاب به چه پرسشی می‌تواند پاسخ دهد. یک تحلیل‌گر لاگ (log parser)، فایل‌های رونوشت نشست (session transcript) را روی دیسک خودتان می‌خواند. یک داشبورد، سوابق استفاده‌ای را می‌خواند که Anthropic برای حساب کاربری یا سازمان شما نگهداری می‌کند. یک بک‌اند متریک، جریان OpenTelemetry (OTel) را می‌خواند که Claude Code هنگام فعال‌سازی منتشر می‌کند. هر سه منبع می‌توانند همزمان درست باشند و در عین حال با هم اختلاف داشته باشند، زیرا هر کدام چیزهای متفاوتی را شمارش می‌کنند.

این راهنما دوباره توکن‌ها را توضیح نمی‌دهد. نحوه شمارش استفاده از توکن توسط Claude Code ورودی، خروجی، نوشتن در حافظه پنهان و خواندن از حافظه پنهان را پوشش می‌دهد و تا زمانی که آن بخش شفاف نباشد، هیچ داشبوردی معنای چندانی نخواهد داشت. پرسش در اینجا محدودتر است: برای هر نوع ابزار، چه چیزی قابل مشاهده است و چه چیزی هرگز قابل مشاهده نخواهد بود.

چرا سه ابزار ردیابی هزینه Claude Code در یک روز ظاهر شدند

سه ابزار ردیابی هزینه مجزا برای Claude Code در یک روز منتشر شدند. این‌ها سه نسخه از یک ابزار واحد نبودند و همین نکته، بخش مفید ماجراست. یکی از آن‌ها فایل‌های نشست محلی را تحلیل می‌کرد. دیگری صفحات استفاده از حساب کاربری را بسته‌بندی (wrap) می‌کرد. سومی یک backend ردیابی میزبانی‌شده بود که خودتان آن را اجرا می‌کنید.

دلیل هم‌زمانی انتشار آن‌ها این است که هزینه یک نشست عامل (agent session) دیگر شفاف نیست. هزینه یک چت تقریباً همان چیزی است که روی صفحه می‌بینید. اما یک عامل، بیست فایل را می‌خواند، مجموعه تست‌ها را اجرا می‌کند و در هر مرحله کل گفتگو را دوباره ارسال می‌کند؛ بنابراین صورت‌حساب توسط متنی که شما هرگز تایپ نکرده‌اید، افزایش می‌یابد. در اشتراک‌ها هیچ مبلغ دلاری مشخصی وجود ندارد و تنها یک نوار میزان استفاده دیده می‌شود که در برخی روزها سریع‌تر از روزهای دیگر خالی می‌شود. هر یک از این سه ابزار، بخش متفاوتی از این خلأ اطلاعاتی را پر می‌کنند.

شکل 1: یک تحلیل‌گر لاگ محلی هزینه امروز را به شما می‌گوید

Claude Code هر گفتگو را به صورت JSON Lines در مسیر ~/.claude/projects/<project>/<session-id>.jsonl ذخیره می‌کند، که در آن <project> مسیر دایرکتوری کاری شماست که کاراکترهای غیرالفبایی آن با - جایگزین شده‌اند. هر نوبت پاسخ دستیار در آن فایل، شامل تعداد توکن‌های درخواست مربوطه است. یک تحلیل‌گر لاگ این مقادیر را جمع زده و قیمت‌گذاری می‌کند.

ccusage گزینه‌ای است که اکثر کاربران از آن استفاده می‌کنند. این ابزار نیازی به نصب ندارد:

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

daily مجموع هزینه‌ها را بر اساس تاریخ محاسبه می‌کند. --breakdown هر ردیف را بر اساس مدل تفکیک می‌کند؛ این همان روشی است که متوجه می‌شوید یک بعدازظهر کار با Opus، بخش بزرگی از هزینه هفته را تشکیل می‌دهد. blocks داده‌ها را بر اساس بازه پنج‌ساعته‌ای که اشتراک در آن ریست می‌شود، گروه‌بندی می‌کند. session مجموع هزینه‌ها را به تفکیک هر گفتگو ارائه می‌دهد و --instances داده‌ها را بر اساس پروژه گروه‌بندی می‌کند تا بتوانید ببینید کدام مخزن (repository) پرهزینه است. برای محدود کردن بازه زمانی از --since و --until استفاده کنید و برای فرمت تاریخ مورد انتظار نسخه خود، npx ccusage@latest daily --help را اجرا کنید. از اوت 2026، این ابزار سایر CLIهای عامل (agent) از جمله Codex و OpenCode را نیز می‌خواند که در صورت مقایسه آن‌ها با یکدیگر اهمیت دارد.

قیمت‌گذاری از یک جدول قیمت مدل‌ها استخراج می‌شود و این ابزار سه حالت هزینه دارد. --mode auto از مقدار costUSD که Claude Code در زمان حضور در فایل نوشته است استفاده می‌کند و در صورت عدم وجود، محاسبات را بر اساس تعداد توکن‌ها انجام می‌دهد. --mode calculate همیشه محاسبات را بر اساس توکن‌ها انجام داده و هرگونه هزینه ثبت‌شده را نادیده می‌گیرد. --mode display فقط هزینه‌های ثبت‌شده را نمایش می‌دهد و برای ردیف‌هایی که هزینه‌ای ندارند، $0.00 چاپ می‌کند. اگر مجموع هزینه‌ها اشتباه به نظر می‌رسد، همان گزارش را یک بار با calculate و بار دیگر با display اجرا کنید. شکاف بزرگ بین این دو به این معنی است که اکثر ورودی‌ها فاقد هزینه ثبت‌شده هستند، بنابراین تمام اعدادی که می‌خوانید صرفاً یک تخمین است.

همین داده‌ها می‌توانند به پرامپت شما تزریق شوند. ccusage statusline یک خط فشرده برای نوار وضعیت Claude Code چاپ می‌کند که مانند هر دستور خط وضعیت دیگری به ~/.claude/settings.json متصل می‌شود. برای مشاهده بلوک تنظیمات و فیلدهایی که دریافت می‌کند، به ساخت خط وضعیت Claude Code مراجعه کنید.

آنچه یک تحلیل‌گر لاگ نمی‌تواند ببیند، هر اتفاقی است که روی این دستگاه رخ نداده باشد. لپ‌تاپ دوم، یک نشست در claude.ai، یا کار همکارتان: آن رونوشت‌ها روی همان دیسک‌ها باقی می‌مانند. داده‌های قدیمی نیز در دسترس نیستند، زیرا رونوشت‌ها به‌طور پیش‌فرض پس از 30 روز تحت تنظیمات cleanupPeriodDays پاکسازی می‌شوند، بنابراین داده‌های فصل گذشته از بین رفته‌اند مگر اینکه آن‌ها را آرشیو کرده باشید.

یک ریسک دیگر نیز وجود دارد که ساختاری است. مستندات Anthropic بیان می‌کند که فرمت ورودی داخلی Claude Code است و بین نسخه‌ها تغییر می‌کند، بنابراین اسکریپت‌هایی که مستقیماً این فایل‌ها را تجزیه می‌کنند ممکن است با هر نسخه جدید از کار بیفتند. این موضوع در مورد تمام ابزارهای این چنینی صدق می‌کند. به همین دلیل است که یک دستور یک‌خطی jq که به‌صورت دستی روی فایل‌های JSONL نوشته شده، ایده بدتری نسبت به آنچه به نظر می‌رسد است: تحلیل‌گرهای نگهداری‌شده، تغییرات فرمت را برای شما دنبال می‌کنند، اما دستور یک‌خطی شما در روزی که یک فیلد تغییر نام یابد، با اطمینان یک عدد غلط گزارش خواهد کرد.

در نهایت، عدد دلاری در یک اشتراک نیاز به یک تذکر دارد. شما در طرح‌های Pro یا Max به ازای هر توکن صورت‌حساب دریافت نمی‌کنید، بنابراین این عدد نشان‌دهنده هزینه‌ای است که توکن‌های شما با نرخ‌های لیست API داشتند. این عدد میزان سنگینی استفاده شما را اندازه‌گیری می‌کند. این مبلغ صورت‌حساب شما نیست. اگر سوال اصلی این است که در کدام طرح عضو باشید، آن مقایسه خود یک تمرین جداگانه است: به صورت‌حساب API در برابر اشتراک Claude مراجعه کنید.

شکل 2: صفحات استفاده داخلی به شما می‌گویند کدام مدل بودجه را مصرف کرده است

Claude Code گزارش‌گیری داخلی خود را دارد و اکثر کاربران هرگز آن را باز نمی‌کنند. دستور /usage را در یک نشست اجرا کنید. بلوک Session در بالا، توکن‌ها را به تفکیک مدل و مبلغ دلاری نشست فعلی نشان می‌دهد که به‌صورت محلی و بر اساس نرخ‌های استاندارد لیست توکن‌ها محاسبه شده است. این رقم شامل تخفیف‌ها یا قیمت‌های تبلیغاتی نمی‌شود، بنابراین ممکن است با صورت‌حساب شما متفاوت باشد. مجموع‌ها با شروع یک گفتگوی جدید توسط /clear بازنشانی می‌شوند.

در طرح‌های Pro، Max، Team یا Enterprise، همین صفحه نشان می‌دهد که چه مقدار از سقف طرح خود را مصرف کرده‌اید و استفاده‌های اخیر را به تفکیک مهارت‌ها، زیر-عامل‌ها (subagents)، افزونه‌ها و سرورهای MCP به صورت درصدی از کل تخصیص می‌دهد. این صفحه رفتارهایی را که 10٪ یا بیشتر از استفاده اخیر را شامل می‌شوند، مانند context طولانی یا cache miss، علامت‌گذاری می‌کند. برای جابه‌جایی بین 24 ساعت گذشته و 7 روز گذشته، d یا w را فشار دهید. این ارقام تقریبی هستند و از تاریخچه نشست‌های محلی روی این دستگاه محاسبه می‌شوند، بنابراین دستگاه دوم در این آمار لحاظ نمی‌شود.

برای تیم‌های بیش از یک توسعه‌دهنده، اعداد به سطح حساب کاربری منتقل می‌شوند. یک سازمان API به صفحه استفاده در Console دسترسی دارد، که یک داشبورد Claude Code با آمار هزینه‌ها و خطوط پذیرفته‌شده به ازای هر عضو است، و همچنین یک API تحلیل Claude Code که همان معیارهای روزانه به ازای هر کاربر را با یک کلید مدیریتی بازمی‌گرداند. طرح‌های Team و Enterprise یک گزارش هزینه در کنسول مدیریت با قابلیت خروجی CSV دریافت می‌کنند که روزانه به‌روزرسانی می‌شود و طرح Enterprise یک API تحلیل نیز اضافه می‌کند. اینکه کدام‌یک از این موارد را می‌بینید به نحوه ورود هر توسعه‌دهنده بستگی دارد، بنابراین در یک سازمان ترکیبی باید دو گزارش را خوانده و به‌صورت دستی با هم جمع کنید.

برای برآورد بودجه، رقم منتشرشده در مستندات هزینه Anthropic تا اوت 2026، میانگینی نزدیک به 13 دلار به ازای هر توسعه‌دهنده در هر روز فعال و 150 تا 250 دلار به ازای هر توسعه‌دهنده در ماه است، که 90٪ کاربران زیر 30 دلار در هر روز فعال هزینه دارند. این را به‌عنوان یک معیار منتشرشده از پیاده‌سازی‌های سازمانی در نظر بگیرید، نه به‌عنوان پیش‌بینی برای تیم خودتان. یک گروه آزمایشی تشکیل دهید و پیش از تعمیم، اندازه‌گیری کنید.

آنچه داشبوردها نمی‌توانند ببینند، جزئیات کمتر از یک روز و یک شخص است. آن‌ها به شما می‌گویند که Opus بیشترین سهم را در سه‌شنبه داشته است. آن‌ها به شما نمی‌گویند که کدام پرامپت، کدام مخزن یا کدام job در CI عامل آن بوده است. این گزارش‌ها همچنین دارای تأخیر هستند، زیرا گزارش‌های سازمانی روزانه به‌روز می‌شوند؛ بنابراین آن‌ها ابزاری برای بازبینی هستند، نه راهی برای متوقف کردن یک عامل سرکش در همین بعدازظهر. متوقف کردن عامل سرکش نیازمند محدودیت است، نه گزارش، که موضوع محدود کردن هزینه‌های عامل روی یک VPS است.

Shape 3: your own OpenTelemetry stack tells you which prompt regressed

Claude Code emits OpenTelemetry metrics and events once you set one environment variable, and this is the only option that streams per-user token and cost data into a system you control in near real time. The metrics include claude_code.cost.usage in USD, claude_code.token.usage in tokens, claude_code.session.count and claude_code.active_time.total.

The token metric is the interesting one, because of its attributes. Each data point carries type, which is input, output, cacheRead or cacheCreation, plus model and query_source, which is main, subagent or auxiliary. It also carries agent.name, skill.name, mcp_server.name and mcp_tool.name. That is enough to answer questions no dashboard can reach: how much of the bill is subagents rather than your own turns, whether one MCP server doubled your input tokens, whether cache reads collapsed after someone edited CLAUDE.md. Cache behaviour is usually where the surprise hides, and when prompt caching pays for itself explains what you are looking at.

One correction worth making, because it comes up in every thread on this. Langfuse is a good self-hosted tracing backend, and running it on a VPS is covered in self-hosting Langfuse for agent tracing. Its OTLP endpoint accepts traces only. Claude Code exports metrics and log events, not spans, so pointing OTEL_EXPORTER_OTLP_ENDPOINT at Langfuse leaves the project empty and gives you no error worth reading. Langfuse is the right tool for agents you build on the API yourself, where your own code creates each span with its prompt, model and cost. For the Claude Code CLI, a metrics store is the match.

راه‌اندازی ردیابی هزینه‌های Claude Code روی VPS شخصی

دو سرویس برای این کار کافی است: یک collector برای دریافت معیارها (metrics) و Prometheus برای ذخیره‌سازی آن‌ها. هر دو را از دسترس اینترنت عمومی خارج کنید، زیرا پورت OTLP باز، داده‌های ارسالی از سوی هر کسی که آن را پیدا کند را می‌پذیرد. فایل /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 است، بنابراین collector فقط از ماشین‌های شما قابل دسترسی است و نه از هیچ جای دیگر. آدرس قبل از پورت در اینجا نقش حیاتی دارد، زیرا پورت‌های منتشر شده توسط Docker توسط ufw فیلتر نمی‌شوند: به دلیل عبور پورت‌های منتشر شده Docker از ufw مراجعه کنید. راه‌اندازی خود تونل در یک VPN WireGuard روی VPS شخصی توضیح داده شده است.

فایل /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. پورت 8889 هرگز روی host منتشر نمی‌شود، زیرا Prometheus از طریق شبکه Compose و با استفاده از نام سرویس به 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 باید با Everything is ready. Begin running and processing data. پایان یابد. لاگی که روی خطای پیکربندی متوقف می‌شود به این معنی است که YAML تجزیه نشده است و container در یک حلقه بازراه‌اندازی (restart loop) قرار می‌گیرد.

اکنون Claude Code را به آن متصل کنید. روی هر ماشینی که Claude Code را اجرا می‌کند، این مورد را به ~/.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 (در اینجا 10 ثانیه، به‌طور پیش‌فرض 60 ثانیه) صبر کنید، سپس از Prometheus بپرسید چه چیزی دریافت کرده است:

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

شما باید چندین نام که با claude_code_ شروع می‌شوند را دریافت کنید. exporter نقاط را به زیرخط (underscore) تبدیل کرده و واحد را به انتهای آن اضافه می‌کند، بنابراین رشته‌های دقیق به نسخه collector شما بستگی دارند. نتیجه خالی به این معنی است که هیچ داده‌ای دریافت نشده است. بررسی کنید که پروتکل و پورت با هم مطابقت داشته باشند، زیرا http/protobuf به پورت 4318 و grpc به پورت 4317 متصل می‌شود و عدم تطابق باعث شکست بی‌سروصدا می‌شود. دستور claude --debug را اجرا کنید تا لاگ دیباگ، خطاهای export مربوط به OTel را گزارش کند.

برای یک ماشین و بدون سرور، از تمام مراحل بالا صرف‌نظر کنید. مقدار OTEL_METRICS_EXPORTER=prometheus را تنظیم کنید تا Claude Code یک scrape endpoint را در http://localhost:9464/metrics توسط خود برنامه در دسترس قرار دهد. وقتی prometheus تنها exporter لیست شده باشد، Claude Code واحدهای USD، tokens و s را از نام معیارها حذف می‌کند تا scrape با فرمت متنی استاندارد Prometheus سازگار باقی بماند.

یک تصمیم حریم خصوصی با این ساختار همراه است. به‌طور پیش‌فرض فقط شمارنده‌ها از ماشین خارج می‌شوند، نه متن prompt و نه خروجی ابزارها. OTEL_LOG_USER_PROMPTS=1 و OTEL_LOG_TOOL_CONTENT=1 این وضعیت را تغییر می‌دهند و در آن صورت، جعبه معیارهای شما حاوی سورس‌کد و هر چیز دیگری که در context بوده است خواهد بود. این گزینه‌ها را آگاهانه فعال کنید و ابتدا دور نگه داشتن اسرار از context عامل را مطالعه کنید.

ردیابی هزینه‌ها برای اجراهای اسکریپتی و CI

اجراهای غیرتعاملی (Non-interactive) همان مواردی هستند که کاربران را غافلگیر می‌کنند، زیرا کسی صفحه نمایش را مشاهده نمی‌کند. claude -p به همراه --output-format json هزینه آن اجرا را در payload نتیجه گزارش می‌دهد:

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

این payload شامل total_cost_usd به همراه تفکیک هزینه به ازای هر مدل است، بنابراین یک job در CI می‌تواند بدون نیاز به داشبورد، هزینه مصرفی خود را ثبت کند. مقدار را به یک فایل ضمیمه کنید یا آن را به عنوان یک متریک به collector ذکر شده در بالا ارسال کنید. این ارزان‌ترین روش کاربردی برای ردیابی هزینه‌ها است و تنها یک فراخوانی jq به ازای هر اجرا هزینه دارد.

حالت‌های شکست و آنچه مشاهده خواهید کرد

گزارش خالی است. npx ccusage@latest daily عدم نمایش هیچ سطری به این معنی است که برنامه از مسیری که Claude Code در آن می‌نویسد، داده‌ای نمی‌خواند. CLAUDE_CONFIG_DIR آن مسیر را تغییر می‌دهد و باید به parser اطلاع داده شود. اگر سطرها وجود دارند اما از حدود یک ماه پیش متوقف شده‌اند، این رفتارِ طراحی‌شدهٔ cleanupPeriodDays است: رونوشت‌ها به‌صورت پیش‌فرض پس از 30 روز حذف می‌شوند.

دو دستگاه مجموع‌های متفاوتی را گزارش می‌کنند. این مورد انتظار است و باگ محسوب نمی‌شود. هم /usage و هم هر parser لاگ دیگری، فقط تاریخچهٔ نشست‌های محلی را می‌خوانند؛ بنابراین استفاده از دستگاه دیگر یا از طریق claude.ai در هیچ‌کدام لحاظ نمی‌شود.

مجموع محلی با صورت‌حساب مطابقت ندارد. ارقام محلی بر اساس تعداد توکن‌ها با نرخ‌های استاندارد لیست محاسبه می‌شوند. این ارقام از قیمت‌گذاری‌های تبلیغاتی یا تخفیف‌های قراردادی بی‌اطلاع هستند و در اشتراک‌ها، توکن‌های شما اصلاً به‌صورت جداگانه صورت‌حساب نمی‌شوند. صفحهٔ استفاده در Console مرجع اصلی برای صورت‌حساب API است.

هزینه با وجود انجام کار مشابه افزایش یافته است. پیش از هر چیز، ستون‌های cache را بررسی کنید. یک نشست طولانی در هر نوبت کل تاریخچهٔ خود را دوباره ارسال می‌کند؛ اگر cache فعال باشد با نرخ cache و اگر غیرفعال شود با نرخ کامل ورودی محاسبه می‌شود، بنابراین یک وقفهٔ طولانی باعث پردازش مجدد کل گفتگو می‌گردد. این وضعیت به‌صورت عدد ورودی بزرگ در کنار عدد خروجی کوچک نمایش داده می‌شود و قیمت‌گذاری توکن ورودی در برابر خروجی توضیح می‌دهد که چرا این دو به‌طور مستقل تغییر می‌کنند.

یک روز با subagentها غیرممکن به نظر می‌رسد. هر subagent پنجرهٔ context خاص خود را اجرا می‌کند، بنابراین میزان استفاده از توکن با تعداد دفعات اجرا و مدت زمان فعالیت هر کدام مقیاس می‌شود. تنها داده‌های OTel آن‌ها را از طریق ویژگی query_source در claude_code.token.usage تفکیک می‌کند. یک parser لاگ فقط مجموع را به شما نشان می‌دهد و شما را در حدس زدن باقی می‌گذارد.

FAQ

آیا ccusage هزینه‌ای که در طرح Max برای آن صورت‌حساب دریافت می‌شود را نشان می‌دهد؟

خیر. در مدل اشتراکی، هزینه بر اساس تعداد توکن محاسبه نمی‌شود؛ بنابراین یک تحلیل‌گر لاگ، توکن‌های شما را با نرخ‌های استاندارد API قیمت‌گذاری می‌کند تا نشان دهد همان کار از طریق API چه هزینه‌ای داشته است. این ابزار یک معیار نسبی مناسب برای سنجش میزان فعالیت در یک روز است و برای مقایسه پروژه‌ها یا مدل‌ها با یکدیگر کاربرد دارد. برای مشاهده مبلغ بدهی، صفحه usage در Console هزینه‌های API و صفحه plan billing هزینه اشتراک را نمایش می‌دهد.

فایل‌های نشست که این ابزارها می‌خوانند، در کجا ذخیره می‌شوند؟

در ~/.claude/projects/<project>/<session-id>.jsonl، که در آن <project> مسیر دایرکتوری کاری است و کاراکترهای غیرالفبایی با - جایگزین شده‌اند. هر خط یک شیء JSON برای یک پیام، استفاده از ابزار یا ورودی متادیتا است. CLAUDE_CONFIG_DIR کل دایرکتوری را جابه‌جا می‌کند و cleanupPeriodDays در settings.json دوره نگهداری 30 روزه را کنترل می‌کند. Anthropic فرمت این ورودی‌ها را داخلی دانسته و اعلام کرده که ممکن است بین نسخه‌ها تغییر کند؛ بنابراین به جای نوشتن اسکریپت شخصی، از ابزارهای نگهداری‌شده برای تحلیل آن‌ها استفاده کنید.

آیا می‌توانم تله‌متری Claude Code را به Langfuse ارسال کنم؟

به‌طور مستقیم خیر. اندپوینت OTLP در Langfuse تریس‌ها (traces) را می‌پذیرد، اما Claude Code متریک‌ها و رویدادهای لاگ را صادر می‌کند و نه اسپن‌ها (spans)؛ بنابراین داده‌ها مقصد مناسبی ندارند. متریک‌های Claude Code را به یک OpenTelemetry collector ارسال کرده و در Prometheus ذخیره کنید. از Langfuse برای ایجنت‌هایی استفاده کنید که خودتان با استفاده از API می‌سازید؛ جایی که کد شما اسپن‌هایی تولید می‌کند که شامل پرامپت، مدل و هزینه هستند.

چرا اعداد محلی من با صفحه usage در Console مطابقت ندارند؟

زیرا روش محاسبه آن‌ها متفاوت است. /usage و تحلیل‌گرهای لاگ، تعداد توکن‌ها را از فایل‌های نشست روی دستگاهی که با آن کار می‌کنید جمع می‌زنند و سپس با نرخ‌های استاندارد لیست قیمت‌گذاری می‌کنند. Console هزینه‌ای که واقعاً برای سازمان شما، در تمام دستگاه‌ها و تمام کلیدها، پس از اعمال تخفیف‌ها ثبت شده است را گزارش می‌دهد. عدم تطابق طبیعی است. تفاوت بسیار زیاد معمولاً به معنای وجود دستگاه دوم، یک CI runner یا یکی دیگر از اعضای تیم است که از همان حساب استفاده می‌کند.

چگونه هزینه یک اجرای claude -p را در CI ردیابی کنم؟

آن را با --output-format json اجرا کنید و total_cost_usd را از خروجی بخوانید؛ برای مثال با استفاده از claude -p "..." --output-format json | jq '.total_cost_usd'. همان payload شامل تفکیک هزینه به تفکیک مدل و شناسه نشست (session ID) است. آن مقدار را برای هر job ثبت کنید تا بدون نیاز به ایجنت، داشبورد یا سرویس اضافی، هزینه هر پایپ‌لاین را در اختیار داشته باشید.