Paghahambing ng Claude Code Spend Tracker

Ano talaga ang binabasa ng Claude Code spend tracker

Ang bawat Claude Code spend tracker ay nagbabasa mula sa isa sa tatlong data source, at ang source ang nagtatakda kung aling tanong ang masasagot nito. Binabasa ng log parser ang session transcript files na nasa sarili mong disk. Binabasa ng dashboard ang usage records na iniingatan ng Anthropic para sa account o organization mo. Binabasa ng metrics backend ang OpenTelemetry (OTel) stream na inilalabas ng Claude Code kapag pinagana mo ito. Maaaring tama ang tatlo nang sabay-sabay ngunit magkakaiba pa rin ang resulta, dahil magkaibang bagay ang binibilang ng mga ito.

Hindi na muling ipinapaliwanag ng guide na ito ang tokens. Sinasaklaw ng kung paano binibilang ng Claude Code ang token usage ang input, output, cache writes, at cache reads, at kaunti ang magiging saysay ng anumang dashboard hangga't hindi malinaw ang bahaging iyon. Mas tiyak ang tanong dito: para sa bawat uri ng tool, ano ang nakikita nito, at ano ang hindi nito kailanman makikita.

Bakit lumitaw sa iisang araw ang tatlong spend tracker para sa Claude Code

Tatlong magkahiwalay na spend tracker para sa Claude Code ang na-post sa parehong araw. Hindi sila tatlong bersyon ng iisang tool, at iyon ang mahalagang bahagi. Ang isa ay nag-parse ng mga local session file. Ang isa ay nag-wrap sa mga screen ng account usage. Ang isa naman ay isang hosted tracing backend na ikaw mismo ang nagpapatakbo.

Sabay-sabay silang lumitaw dahil hindi na agad malinaw ang gastos ng isang agent session. Ang gastos ng isang chat ay humigit-kumulang sa nakikita mo sa screen. Nagbabasa ang isang agent ng 20 file, nagpapatakbo ng test suite, at muling ipinapadala ang buong conversation sa bawat turn. Dahil dito, ang bill ay nakabatay sa context na hindi mo naman tina-type. Sa isang subscription, wala ring dollar figure. Usage bar lang ang nakikita, at mas mabilis itong nauubos sa ilang araw kaysa sa iba. Bawat isa sa tatlong tool ay tumutugon sa magkakaibang bahagi ng kakulangang ito.

Hugis 1: ipinapakita ng local log parser kung magkano ang nagastos ngayong araw

Iniimbak ng Claude Code ang bawat conversation bilang JSON Lines (JSONL) sa ~/.claude/projects/<project>/<session-id>.jsonl, kung saan ang <project> ay path ng working directory na pinalitan ng - ang mga non-alphanumeric na character. May token count para sa request nito ang bawat assistant turn sa file na iyon. Pinagsasama-sama ng log parser ang mga ito at kinakalkula ang presyo.

ccusage ang karaniwang pinipili ng karamihan. Hindi nito kailangan ng install:

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

Nagbibigay ang daily ng totals ayon sa petsa. Hinahati ng --breakdown ang bawat row ayon sa model. Dito mo makikita kung ang isang hapon sa Opus ang kumonsumo ng malaking bahagi ng buong linggo. Pinagpapangkat ng blocks ang data ayon sa limang-oras na window kung kailan nagre-reset ang subscription. Nagbibigay ang session ng total bawat conversation, at pinapangkat ng --instances ayon sa project para makita kung aling repository ang magastos. Gamitin ang --since at --until para limitahan ang range, at patakbuhin ang npx ccusage@latest daily --help para makita ang date format na inaasahan ng iyong version. Noong August 2026, nakakabasa rin ito ng iba pang agent CLI, kabilang ang Codex at OpenCode. Mahalaga ito kung ikinukumpara mo ang mga ito.

Nagmula ang pricing sa model price table, at may tatlong cost mode ang tool. Ginagamit ng --mode auto ang value na costUSD na isinulat ng Claude Code sa file kapag mayroon nito, at kinakalkula ang cost mula sa token count kapag wala. Palaging kinakalkula ng --mode calculate ang cost mula sa tokens at binabalewala ang anumang recorded cost. Ipinapakita lamang ng --mode display ang recorded costs at nagpi-print ng $0.00 para sa mga row na walang recorded cost. Kung mukhang mali ang total, patakbuhin ang parehong report gamit ang calculate at pagkatapos ay gamit ang display. Ang malaking agwat sa pagitan ng mga ito ay nangangahulugang karamihan sa mga entry ay walang recorded cost, kaya estimate ang lahat ng binabasa mo.

Maaari ring gamitin ang parehong data para sa iyong prompt. Nagpi-print ang ccusage statusline ng compact line para sa Claude Code status bar, na kino-configure sa ~/.claude/settings.json gaya ng ibang status line command. Tingnan ang pagbuo ng Claude Code statusline para sa settings block at mga field na natatanggap nito.

Hindi nakikita ng log parser ang anumang hindi nangyari sa machine na ito. Ang pangalawang laptop, session sa claude.ai, at trabaho ng teammate ay nasa mga disk ng kani-kanilang machine. Nawawala rin ang lumang data dahil nililinis ang transcripts pagkalipas ng 30 days bilang default sa ilalim ng setting na cleanupPeriodDays. Kaya wala na ang data mula sa nakaraang quarter maliban kung na-archive mo ito.

May isa pang panganib, at structural ito. Nakasaad sa documentation ng Anthropic na internal sa Claude Code ang entry format at nagbabago ito sa pagitan ng mga version. Dahil dito, maaaring masira sa anumang release ang mga script na direktang nagpa-parse ng mga file na ito. Nalalapat ito sa lahat ng tool na ganito ang paraan ng pagproseso. Ito rin ang dahilan kung bakit mas masamang ideya kaysa sa inaakala ang isang sariling gawang jq one-liner sa JSONL: sinusubaybayan ng maintained parser ang mga pagbabago sa format para sa iyo, samantalang magbibigay ng mukhang siguradong maling numero ang iyong one-liner sa araw na palitan ang pangalan ng isang field.

Sa huli, kailangan ng caveat ang dollar figure kapag subscription ang gamit. Hindi ka sinisingil per token sa Pro o Max, kaya ipinapakita ng numerong ito kung magkano sana ang halaga ng tokens mo batay sa list API rates. Sinusukat nito kung gaano kabigat ang iyong paggamit. Hindi ito ang iyong bill. Kung ang tunay na tanong ay kung aling plan ang dapat mong gamitin, hiwalay na pagsusuri iyon: tingnan ang API billing kumpara sa Claude subscription.

Paraan 2: ipinapakita ng built-in usage screens kung aling model ang gumastos ng budget

May sarili nang reporting ang Claude Code, pero bihira itong buksan ng karamihan. Patakbuhin ang /usage sa loob ng isang session. Sa Session block sa itaas, makikita ang bilang ng tokens ayon sa model at ang halagang naka-dollar para sa kasalukuyang session. Lokal itong kinakalkula batay sa bilang ng tokens at standard list rates. Hindi nito isinasaalang-alang ang discount o promotional pricing, kaya maaaring iba ito sa iyong invoice. Nire-reset ang totals kapag nagsimula ng bagong conversation ang /clear.

Sa Pro, Max, Team, o Enterprise plan, ipinapakita rin ng parehong screen kung gaano kalaking bahagi ng plan limit mo ang nagamit. Iniuugnay din nito ang kamakailang usage sa skills, subagents, plugins, at indibidwal na MCP servers bilang porsyento ng total. Tina-tag nito ang mga behavior na bumubuo ng 10% o higit pa ng kamakailang usage, gaya ng mahabang context o cache misses. Pindutin ang d o w upang magpalipat-lipat sa huling 24 oras at huling 7 araw. Tinatantiya ang mga figure na ito at kinakalkula mula sa lokal na session history sa machine na ito, kaya hindi kasama ang paggamit sa pangalawang device. Kapag walang laman ang bar, sa halip na mababa lamang, ipinapaalam ng screen na nagsara na ang window ngunit hindi nito sinasabi kung paano magpapatuloy. Ang gagawin kapag naabot na ang limit ay hiwalay na desisyon tungkol sa model, context, at plan.

Kapag mahigit isang developer na ang sakop, napupunta sa account ang mga numero. Nakakakuha ang isang API organisation ng Console usage page, Claude Code dashboard na nagpapakita ng spend at accepted lines ng bawat member, at Claude Code Analytics API na nagbabalik ng parehong daily per-user metrics gamit ang admin key. Nakakakuha ang Teams at Enterprise plans ng spend report sa admin console na may CSV export at ina-update araw-araw. May analytics API din ang Enterprise. Depende sa paraan ng pag-sign in ng bawat developer kung alin sa mga ito ang makikita mo. Kaya kailangang basahin ng mixed organisation ang dalawang report at manu-manong pagsamahin ang mga ito.

Para sa pagtantiya ng budget, ang published figure sa cost documentation ng Anthropic noong August 2026 ay average na humigit-kumulang $13 bawat developer bawat active day at $150 hanggang $250 bawat developer bawat buwan. Nasa ilalim ng $30 bawat active day ang 90% ng users. Ituring ito bilang published benchmark mula sa enterprise deployments, hindi bilang prediction para sa team mo. Magpatakbo muna ng pilot group at magsukat bago mag-extrapolate.

Hindi nakikita ng dashboards ang anumang mas detalyado pa kaysa sa araw at tao. Sasabihin ng mga ito na ang Opus ang pinakamaraming ginamit noong Martes. Hindi nila sasabihin kung aling prompt, repository, o CI job ang gumamit nito. May delay din ang mga ito dahil araw-araw ina-update ang organisation reports. Kaya mga review tool ang mga ito, hindi paraan para mahuli ang runaway agent ngayong hapon. Kailangan ng limits, hindi reports, para mahuli ang runaway. Ito ang paksa ng pagpapanatiling kontrolado ng agent costs sa isang VPS.

Hugis 3: sinasabi sa iyo ng sarili mong OpenTelemetry stack kung aling prompt ang nag-regress

Naglalabas ang Claude Code ng OpenTelemetry metrics at events kapag nagtakda ka ng isang environment variable. Ito lang ang option na nag-i-stream ng per-user token at cost data papunta sa sistemang kontrolado mo, halos real time. Kasama sa metrics ang claude_code.cost.usage sa USD, claude_code.token.usage sa tokens, claude_code.session.count, at claude_code.active_time.total.

Ang token metric ang pinakamahalaga dahil sa mga attribute nito. May dalang type ang bawat data point, na maaaring input, output, cacheRead, o cacheCreation, pati model at query_source, na maaaring main, subagent, o auxiliary. May dala rin itong agent.name, skill.name, mcp_server.name, at mcp_tool.name. Sapat na ito para sagutin ang mga tanong na hindi kayang sagutin ng anumang dashboard: gaano kalaki sa bill ang mula sa subagents sa halip na sa sarili mong turns, kung dinoble ng isang MCP server ang input tokens mo, at kung bumagsak ang cache reads matapos may mag-edit ng CLAUDE.md. Karaniwang nasa cache behavior ang hindi inaasahang resulta, at ipinapaliwanag ng kung kailan sulit ang prompt caching kung ano ang tinitingnan mo.

May isang pagwawasto na mahalagang gawin dahil lumilitaw ito sa bawat thread tungkol dito. Magandang self-hosted tracing backend ang Langfuse, at saklaw ng self-hosting ng Langfuse para sa agent tracing ang pagpapatakbo nito sa isang VPS. Traces lamang ang tinatanggap ng OTLP endpoint nito. Metrics at log events, hindi spans, ang ine-export ng Claude Code. Kaya kung ituturo mo ang OTEL_EXPORTER_OTLP_ENDPOINT sa Langfuse, mananatiling walang laman ang project at wala kang makukuhang error na kapaki-pakinabang basahin. Ang Langfuse ang tamang tool para sa mga agent na ikaw mismo ang bumuo gamit ang API, kung saan ang sarili mong code ang lumilikha ng bawat span kasama ang prompt, model, at cost nito. Para sa Claude Code CLI, metrics store ang tamang katugma.

I-set up ang Claude Code spend tracking sa sarili mong VPS

Dalawang service lang ang kailangan: isang collector para tumanggap ng metrics, at Prometheus para mag-store ng mga ito. Panatilihing hindi exposed sa public internet ang dalawang ito, dahil ang bukas na OTLP port ay tumatanggap ng writes mula sa sinumang makakita nito. Isulat ang /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:

Ang 10.8.0.1 ay address ng server sa loob ng WireGuard tunnel, kaya reachable ang collector mula sa iyong mga machine at wala nang iba. May mahalagang silbi rito ang address bago ang port, dahil hindi hina-harangan ng ufw ang mga Docker port na naka-publish: tingnan ang kung bakit nilalampasan ng mga Docker published port ang ufw. Ang pag-set up mismo ng tunnel ay nasa isang WireGuard VPN sa sarili mong 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. Hindi kailanman pini-publish sa host ang port 8889, dahil ina-access ng Prometheus ang collector sa Compose network gamit ang service name:

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

Dapat magtapos ang collector log sa Everything is ready. Begin running and processing data.. Ang log na humihinto dahil sa config error ay nangangahulugang hindi na-parse ang YAML, at paulit-ulit na magre-restart ang container.

Ngayon, ituro rito ang Claude Code. Sa bawat machine na nagpapatakbo ng Claude Code, idagdag ito sa ~/.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"
  }
}

Magsimula ng session, magpadala ng isang prompt, maghintay sa export interval (10 seconds dito, 60 seconds bilang default), at pagkatapos ay tanungin ang Prometheus kung ano na ang nakolekta nito:

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

Dapat kang makakuha ng ilang pangalan na nagsisimula sa claude_code_. Pinapalitan ng exporter ng underscores ang mga tuldok at idinadagdag nito ang unit, kaya nakadepende sa bersyon ng collector ang eksaktong strings. Ang walang laman na resulta ay nangangahulugang walang dumating na data. Tiyaking magkatugma ang protocol at port, dahil ang http/protobuf ay gumagamit ng 4318 at ang grpc ay gumagamit ng 4317, at tahimik na nagfa-fail ang mismatch. Patakbuhin ang claude --debug at iuulat ng debug log ang mga OTel export error.

Para sa isang machine at walang server, laktawan ang lahat ng nasa itaas. I-set ang OTEL_METRICS_EXPORTER=prometheus at maglalabas mismo ang Claude Code ng scrape endpoint sa http://localhost:9464/metrics. Kapag prometheus lang ang nakalistang exporter, inaalis ng Claude Code ang mga unit na USD, tokens at s sa mga pangalan ng metric upang manatiling valid na Prometheus text format ang scrape.

May kasamang isang desisyon sa privacy ang setup na ito. Bilang default, counts lang ang lumalabas sa machine; walang prompt text at walang tool output. Binabago ito ng OTEL_LOG_USER_PROMPTS=1 at OTEL_LOG_TOOL_CONTENT=1, kaya maaaring mapunta sa metrics box mo ang source code at iba pang nasa context. I-enable lamang ang mga ito kapag sinadya mo, at basahin muna ang pag-iwas na mailagay ang mga secret sa agent context.

Pagsubaybay sa gastos para sa scripted at CI runs

Ang non-interactive runs ang madalas nakagugulat dahil walang nagbabantay sa screen. Ang claude -p na may --output-format json ay nag-uulat ng gastos ng run na iyon sa result payload nito:

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

Nilalaman ng payload ang total_cost_usd pati ang breakdown ayon sa bawat model, kaya maaaring itala ng CI job ang sarili nitong gastos nang walang dashboard. Idagdag ang value sa isang file, o i-push ito bilang metric sa collector sa itaas. Ito ang pinakamurang kapaki-pakinabang na paraan ng pagsubaybay sa gastos, at nangangailangan ito ng isang jq call bawat run.

Mga failure mode at kung ano ang makikita mo

Walang laman ang report. npx ccusage@latest daily Kapag walang nire-report na row, nangangahulugan itong hindi nito binabasa ang lokasyon kung saan nagsusulat ang Claude Code. CLAUDE_CONFIG_DIR Inililipat ang lokasyong iyon, at kailangang sabihin ito sa parser. Kung may mga row pero humihinto ang mga ito mga isang buwan na ang nakalipas, normal ito at gumagana ang cleanupPeriodDays ayon sa disenyo: default na inaalis ang mga transcript pagkalipas ng 30 araw.

Magkaiba ang kabuuang bilang na nire-report ng dalawang machine. Inaasahan ito at hindi bug. Parehong /usage at anumang log parser ay nagbabasa lamang ng lokal na session history, kaya wala sa dalawa ang usage mula sa ibang device o mula sa claude.ai.

Hindi tugma ang lokal na total sa invoice. Kinukuwenta ang mga lokal na figure batay sa token count at standard list rates. Hindi nito alam ang promotional pricing o contracted discount. Sa subscription, hindi rin isa-isang sinisingil ang mga token mo. Ang Console usage page ang authoritative na source para sa API billing.

Tumaas ang cost kahit pareho lang ang ginawa mong trabaho. Suriin muna ang mga cache column. Sa mahabang session, ipinapadala muli ang buong history nito sa bawat turn. Sisingilin ito sa cached rate habang warm ang cache at sa full input rate kapag naging cold ito. Kaya kapag matagal na naputol ang session, muling pinoproseso ang buong conversation. Makikita ito bilang malaking input number na katabi ng maliit na output number, at ipinapaliwanag ng pagpepresyo ng input kumpara sa output token kung bakit magkahiwalay na nagbabago ang dalawa.

Mukhang imposible ang isang araw na may subagents. Gumagamit ang bawat subagent ng sarili nitong context window, kaya nakadepende ang token use sa dami ng tumakbo at sa tagal ng bawat isa. OTel data lamang ang naghihiwalay sa mga ito, gamit ang query_source attribute sa claude_code.token.usage. Ipapakita ng log parser ang total at hahayaan kang manghula sa pinagmulan nito.

FAQ

Ipinapakita ba ng ccusage ang aktuwal na sinisingil sa akin sa Max plan?

Hindi. Sa isang subscription, hindi ka sinisingil batay sa token. Kaya pinapresyo ng log parser ang iyong mga token gamit ang standard list API rates at ipinapakita kung magkano sana ang parehong trabaho kung ginawa ito sa pamamagitan ng API. Magandang relative measure ito kung gaano kabigat ang isang araw, at kapaki-pakinabang ito sa paghahambing ng mga project o model sa isa’t isa. Para sa aktuwal mong babayaran, saklaw ng Console usage page ang API billing, habang saklaw ng plan billing page ang subscription.

Saan iniimbak ng Claude Code ang session files na binabasa ng mga tool na ito?

Sa ~/.claude/projects/<project>/<session-id>.jsonl, kung saan ang <project> ay ang path ng working directory na ang mga non-alphanumeric character ay pinalitan ng -. Ang bawat linya ay isang JSON object para sa isang message, paggamit ng tool, o metadata entry. Inililipat ng CLAUDE_CONFIG_DIR ang buong directory, at kinokontrol ng cleanupPeriodDays sa settings.json ang 30-day retention. Itinuturing ng Anthropic na internal ang format ng entry at maaari itong magbago sa pagitan ng mga version, kaya gumamit ng maintained tool sa pag-parse nito sa halip na sarili mong script.

Maaari ko bang ipadala ang telemetry ng Claude Code sa Langfuse?

Hindi nang direkta. Tumatanggap ang Langfuse OTLP endpoint ng traces, samantalang metrics at log events, hindi spans, ang ine-export ng Claude Code. Kaya wala itong mapaglalagyan. Ipadala ang Claude Code metrics sa isang OpenTelemetry collector at i-store ang mga ito sa Prometheus. Gamitin ang Langfuse para sa mga agent na ikaw mismo ang bumuo gamit ang API, kung saan nag-e-emit ang sarili mong code ng mga span na naglalaman ng prompt, model, at cost.

Bakit hindi nagtutugma ang mga local number ko sa Console usage page?

Dahil magkaiba ang paraan ng pagkalkula sa mga ito. Pinagsasama-sama ng /usage at ng mga log parser ang token count mula sa session files sa machine na ginagamit mo, pagkatapos ay pinapresyo ang mga ito gamit ang standard list rates. Iniuulat naman ng Console ang aktuwal na siningil sa iyong organisation, mula sa lahat ng machine at lahat ng key, matapos isaalang-alang ang anumang discount. Normal ang hindi pagtutugma. Karaniwang nangangahulugan ang malaking diperensya na may ikalawang device, CI runner, o ibang team member na naniningil sa parehong account.

Paano ko masusubaybayan ang cost ng isang claude -p run sa CI?

Patakbuhin ito gamit ang --output-format json at basahin ang total_cost_usd mula sa resulta, halimbawa gamit ang claude -p "..." --output-format json | jq '.total_cost_usd'. Kasama rin sa parehong payload ang per-model breakdown at session ID. I-record ang value na iyon sa bawat job upang makuha ang per-pipeline spend nang walang agent, dashboard, o karagdagang service.