Four Ways to Track Claude Code Cost, Compared

Before comparing tools, get specific about what you're trying to answer. Skip this and you'll end up building infrastructure you didn't need.

1. What will we be invoiced? — the number finance needs. Only your provider's billing console is authoritative, and no visibility tool substitutes for it.
2. Who is using how much? — adoption, seat decisions, chargeback, and explaining the return on the investment.
3. What were they actually doing? — incident investigation, or confirming nothing left the building. This requires records of prompts and tool activity.

If only (1) matters, the billing console is enough. (2) is where comparing the four options starts to pay off. If you need (3), the field narrows considerably.

Claude for Teams and Enterprise include an analytics dashboard in the admin console. Start here — if it covers your needs, you don't need to build anything.

What you get

The spend report exports to CSV with user email, account UUID, product, model, request count, prompt tokens, completion tokens, net spend, and gross spend — plenty of granularity for per-user reporting.

Four constraints that bite in practice

1. One-day delay — spend data refreshes daily and lags by a day. It won't tell you what is happening right now.
2. 90-day lookback — custom ranges reach back 90 days at most, and only through yesterday.
3. Seat-allowance usage isn't priced — on seat-based plans the spend report appears only once usage credits are enabled, and it covers overage only. Usage inside the allowance is never expressed in dollars.
4. Few people can open it — Team plans: Owners and Primary Owners only. Enterprise: Owners, Primary Owners, and Admins — but Admins cannot see Spend.

On the Console (API key) side you get the Console dashboard and the Claude Code Analytics API instead. Usage through a cloud provider — Bedrock, Google Cloud, Microsoft Foundry — is outside the built-in dashboards entirely.

ccusage is an open-source CLI that reads the coding-agent history stored on a machine and reports token counts and estimated cost. No install required to try it.

npx ccusage@latest daily
npx ccusage@latest monthly
npx ccusage@latest session
npx ccusage@latest blocks

It tracks cache-creation and cache-read tokens separately, and prices from an embedded snapshot so it works offline. You can override rates in ccusage.json. It also covers agents other than Claude Code, such as Codex.

Where it fits, and where it doesn't

For an individual understanding their own usage, nothing is faster. Watching your five-hour window fill up and pacing your work accordingly is something the other three options simply don't offer. But it reads local data on one machine, so organization-wide aggregation, distributing configuration, separating read access, and managing retention sit outside its design. Collecting everyone's output by hand to produce a company number is not a workable plan.

Claude Code exports OpenTelemetry metrics, logs, and traces. Point them at your own Collector and everything downstream is yours to decide. If you already run an observability platform, riding on it is the soundest option available.

What you're actually signing up to run

• OpenTelemetry Collector — ingest, transform, route. One more thing to make redundant and monitor.
• Time-series database — metric storage (Prometheus, Mimir, …). Get cardinality wrong and it shows up in both storage and query latency.
• Log backend — storage and full-text search for events, i.e. prompt and tool records (Loki, OpenSearch, …).
• Dashboards — building them in Grafana or similar. Defining and maintaining the metrics becomes your job.
• Retention and deletion — per-plan or per-org retention, and handling deletion requests. This gets heavy fast once audit logs are involved.
• Access control — separating who can read message content. Observability platforms are typically built on the assumption that every engineer can see everything, so co-locating audit logs needs a deliberate split.

You get near-real-time numbers, freedom to aggregate along your own dimensions (team, department, project), and integration with existing alerting. Conversely: if you don't need those, this is too much machinery.

The exporter configuration is identical to option 3; ingestion, storage, dashboards, and search are somebody else's problem. Because Claude Code emits standard OTLP, switching destinations is a configuration change — which also means the lock-in is thin.

Aimeterly sits here. It receives the OTLP that Claude Code sends once telemetry is enabled and turns it into usage, estimated cost, and productivity dashboards, plus audit-log search across the content types your organization turns on in its settings. No Collector, no time-series database — distribute a snippet through managed settings and you're running.

Roles are split into admin, manager, and viewer, so "managers see dashboards, admins see audit logs" is expressible. The read-access problem that stalls rollouts on the built-in analytics is solvable here.

The bottom two rows take you back to the three questions. Only the provider knows the invoice, and only an approach with capture enabled can reconstruct what happened. Everything above them is a question of what resolution you want on "who is using how much."

Ten people or fewer, on Teams, just want visibility

Start with the built-in analytics. Nothing to pay for, nothing to run, and at this size neither the one-day lag nor the 90-day window is a real constraint. Point individual developers at ccusage so they can pace their own consumption. As for which plan to sign in the first place, that's covered in Claude Team vs. Enterprise.

Tens of engineers, and managers need the numbers

Built-in read access is the first wall you hit (Team: Owners only; even on Enterprise, Admins can't see Spend). Exporting OpenTelemetry to somewhere permissions can be split is the straightforward answer. Ride your observability platform if you have one; consider managed if you don't. Building a stack from scratch rarely pays at this size.

You already run Grafana and Prometheus

Riding your own stack is compelling: one more endpoint on the Collector and it lands in the dashboards and alerts you already have. If prompt content is going in too, decide the storage split and read access first.

Running through Bedrock, Google Cloud, or Foundry

The built-in dashboards don't cover you, which leaves OpenTelemetry or an LLM gateway. Server-managed settings aren't available either, so delivery goes through MDM. On top of that user.email may be absent, so per-user aggregation needs an identifier you supply. See Bedrock, Google Cloud, and Foundry for the details.

You have an audit requirement

Neither the built-in analytics nor ccusage records prompts or tool activity at all. You'll be enabling OpenTelemetry content logging and receiving it in a self-hosted or managed backend. But settle purpose, scope, audience, retention, and employee notification before you switch it on — being able to enable something and being allowed to are different questions.