How to Track, Audit, and Govern Claude Code Costs Across Your Organization

When someone says "we need to manage our Claude Code costs," three different jobs are usually bundled together. Separating them first is what keeps you from picking the wrong tool.

1. Confirming the bill — what you actually get charged. Only your provider's billing console (Anthropic, AWS, Google Cloud) is authoritative.
2. Seeing usage and estimated cost — who uses which model, and how much. This is what drives improvement, chargeback, and investment decisions.
3. Governing — spend limits, enforced configuration, blocked operations. The machinery that actually stops things.

This article focuses on layer 2, while keeping its boundary with 1 and 3 explicit. The most expensive misconception at rollout time is assuming that a dashboard will stop overspending.

How Claude Code is billed — and where you can see the numbers — depends on how developers authenticate. In a company-wide rollout it's common for several methods to coexist. Find yourself in this table first.

The first row is where people get tripped up: on seat-based plans, usage inside the allowance is never expressed in dollars. If you want per-user spend as a number, you either turn on usage credits and measure the overage, or you use telemetry estimates. Adoption metrics — daily active users, sessions, code contribution — live on a separate dashboard from spend.

Anthropic's own documentation notes that OpenTelemetry export works on every setup and is the only option that streams per-user token and cost metrics into your own observability stack in near real time. The flip side: usage through a cloud provider is not covered by Anthropic's analytics dashboards at all.

Know the going rate

For budgeting, the published figures are a useful anchor (as of August 2026). Across enterprise deployments the average is about $13 per developer per active day and $150–250 per developer per month, with 90% of users staying under $30 per active day. Measure your own baseline with a small pilot group before extrapolating to the whole company.

Check the auth method with /status

/status shows how a given machine is authenticated. An API key set in the environment can take precedence over a subscription, which means a developer can be generating metered API spend without realizing it. Checking this on a few representative machines before rollout prevents a class of surprise invoices.

There is more than one way to answer "who is using how much," and they cover different ground. Look at what already exists before building anything.

Anthropic's built-in analytics

Claude for Teams and Enterprise include an analytics dashboard in the admin console (daily active users, sessions, contribution metrics, exportable as CSV). The dollar-denominated spend report appears once usage credits are turned on, and it covers spend beyond the seat allowance. On Enterprise, the Analytics API returns per-user usage and cost programmatically. Console (API key) customers get the Console dashboard and the Claude Code Analytics API. Start here — if this covers your needs, you don't need anything else. And if you're still deciding which plan to sign in the first place, see Claude Team vs. Enterprise.

Aggregate local history with ccusage

ccusage is an open-source CLI that reads the Claude Code history on a machine and reports tokens and estimated cost by day, month, and session. It's the fastest way for an individual to understand their own usage. Because it reads local data, it isn't aimed at company-wide distribution, centralized auditing, or access control.

Send OpenTelemetry to your own stack

Claude Code can export OpenTelemetry metrics, logs, and traces. Point OTLP at your own OpenTelemetry Collector and feed Prometheus, Grafana, and a log backend, and you get maximum freedom. You also take on the Collector, the time-series database, dashboards, log search, retention and deletion, and access control — designed and maintained by you.

Send OTLP to a managed backend

The exporter configuration stays identical to the self-hosted route; ingestion, storage, dashboards, and search are handled for you. 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 over the content types your organization turns on in its settings.

The columns to read carefully are "Authoritative billing" and "Can stop spend." No telemetry tool is your billing system of record, and none of them stops spending. Both belong on the provider side. What a provider console tends not to give you is near-real-time export into your own stack, aggregation along your own dimensions such as team or department, and event-level audit detail. That is the gap telemetry fills.

How the four differ on refresh rate, lookback window, and who can read the numbers is covered in Four Ways to Track Claude Code Cost, Compared — read that first if you're still deciding. You can see what these dashboards look like on the demo (demo data) page.

Before distributing any configuration, know what actually leaves the machine. Claude Code sends no OpenTelemetry at all until CLAUDE_CODE_ENABLE_TELEMETRY=1 and an exporter are configured. Once enabled, it has three channels — metrics, events (logs), and traces — and every content-logging flag is off by default, so what you get initially is metadata with no message content. The full inventory lives in the monitoring documentation.

Eight standard metrics

These carry attributes such as user.email, user.id, session.id, model, terminal.type, and organization.id. You can add your own dimensions — OTEL_RESOURCE_ATTRIBUTES=department=platform, for example — to segment by team or department.

Events and content logging are separate things

Alongside metrics, Claude Code emits events as logs: claude_code.user_prompt, claude_code.assistant_response, claude_code.tool_result, claude_code.api_request, claude_code.api_error, and claude_code.tool_decision (the short forms such as user_prompt appear in each record's event.name attribute). The important part is that prompt and response text is not included by default. Recording content requires explicitly enabling these variables:

Trim the attributes

Metric attributes drive cardinality, which drives cost and performance on some backends. You can drop session IDs with OTEL_METRICS_INCLUDE_SESSION_ID=false and account UUIDs with OTEL_METRICS_INCLUDE_ACCOUNT_UUID=false. If you're sending to your own stack, decide this before you start collecting.

Telemetry configuration is environment variables. Asking every developer to set them by hand doesn't scale, so you distribute them as managed settings. The JSON payload is identical regardless of the delivery method.

Minimum configuration

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://<your-endpoint>",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer <token>"
  }
}

This uses the same schema as settings.json, so it works as-is with either delivery method below. The token in OTEL_EXPORTER_OTLP_HEADERS is a secret: keep it out of your repository, and check who can reach the distribution channel.

Option A: server-managed settings (Teams / Enterprise)

On Claude for Teams or Enterprise, paste the JSON into Admin Settings → Claude Code → Managed settings on claude.ai and every user receives it (server-managed settings documentation). Clients fetch at startup and poll hourly during active sessions. This suits organizations without MDM, or fleets that include unmanaged devices. Only Owners and Primary Owners can edit it.

Option B: endpoint-managed settings (MDM)

If you run an MDM, deliver the same JSON through a macOS configuration profile, a Windows registry policy, or a managed-settings.json at the OS-level managed path. Because the file can be protected at the OS level, this gives stronger guarantees.

When nothing shows up

• OpenTelemetry configuration, unlike most settings, requires a full restart to take effect.
• Run claude --debug to surface exporter errors when you're unsure whether anything is being sent.
• If a developer has overridden the endpoint in personal settings, setting OTEL_EXPORTER_OTLP_ENDPOINT in managed settings strips the conflicting developer-set per-signal endpoints at startup (v2.1.217+).
• If a provider variable such as CLAUDE_CODE_USE_BEDROCK or a non-default ANTHROPIC_BASE_URL is exported in the shell, the server-managed settings fetch is skipped entirely.
• Check whether claude_code.session.count is climbing on the receiving end first. If it is, the path works and you're down to an attribute problem.

Bedrock, Google Cloud, and Foundry

Server-managed settings are not available with third-party model providers — Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, or a custom endpoint. There you either deliver endpoint-managed settings through MDM or run a self-hosted gateway. These setups also fall outside Anthropic's analytics dashboards, which leaves OpenTelemetry or an LLM gateway as the practical routes to per-user cost attribution.

If you'd rather not build and run the receiving end, Aimeterly's setup guide covers it: creating an organization issues an endpoint and an ingest token immediately, so replacing the <...> placeholders above and distributing gets the ingestion path working. Per-user aggregation still needs the identity work described just above.

Recording prompts and responses lets you reconstruct what was asked and what happened. It also means source code, customer data, credentials, and personal information may end up in the record. Being able to enable something and being allowed to enable it are different questions.

The default is: no content

Content logging is split mainly into four types — prompts, responses, tool details, and tool content — and all four are off by default (so is OTEL_LOG_RAW_API_BODIES, which this guide never enables). Rather than switching everything on, work backwards from what you actually need to answer. If the question is "what instructions were given," prompts alone are enough (with OTEL_LOG_ASSISTANT_RESPONSES=0 set explicitly, as noted above).

Settle these first

1. Purpose — write down why you're recording (incident investigation, data-exfiltration review, demonstrating policy compliance).
2. Scope — which of the four types, and for whom: the whole company or specific teams.
3. Who can read it — admins only, or managers too? Does your tooling separate those roles?
4. Retention and deletion — how long you keep it, the deletion procedure, and who can run it.
5. Notifying employees — communicate purpose, scope, and audience in advance. Check with legal and HR whether employment agreements or works-council consultation apply.

Don't wire productivity metrics into performance reviews

Lines of code, commits, pull requests, and suggestion-acceptance rates are genuinely useful for gauging adoption and spotting people who need support. As individual performance measures they distort quickly — they reward writing more lines and committing more often. Keep them at the level of organizational trends, and say explicitly at rollout that they won't be used as direct input to performance reviews. That single statement does more for adoption than any dashboard.

Visibility and control are different layers. A dashboard tells you what happened; it stops nothing. Here's where each thing you might want actually takes effect.

Which means the right thing to ask of a telemetry tool isn't enforcement — it's being able to confirm afterwards that policy was actually followed. Put enforcement in the provider console and managed settings; put verification in telemetry. That division holds up best over time.

The same material, in the order you'd work through it. Clearing these top to bottom avoids most of the rework.

1. Confirmed the auth method and who gets billed (/status, plan, any cloud-provider routing)
2. Set spend limits on the provider side, and know which ones actually stop spend versus merely alert
3. Chose the telemetry destination and reviewed who can reach the token
4. Picked exactly one delivery method for managed settings per group of clients (server-managed or MDM)
5. Warned developers about the approval dialog, if you're delivering a non-empty endpoint through server-managed settings
6. Fully restarted Claude Code on the target machines after delivery (OpenTelemetry settings don't apply until you do)
7. Confirmed claude_code.session.count is arriving at the receiving end
8. Verified in a pilot that identifying attributes such as user.email arrive as expected (external providers need extra work here)
9. Agreed on a diagnostic path for when nothing arrives (claude --debug, checking which managed source is active)
10. Decided the purpose, scope, audience, retention, and deletion process for content logging
11. Shipped OTEL_LOG_ASSISTANT_RESPONSES=0 explicitly, if you only want prompts recorded
12. Confirmed OTEL_LOG_RAW_API_BODIES is absent from the payload you distribute
13. Completed employee notification and any required internal process
14. Separated estimated cost from authoritative billing in internal reporting