Claude Code enterprise rollout: usage, spend, and governance

Roll Claude Code out past a dozen developers and the same three questions land on the platform team within a month: who is using it, what is it costing, and can we show what it did. Anthropic ships more built-in answers than most teams expect, and a Claude Code enterprise rollout should start by using all of them. They stop, though, at four places that matter: other vendors' agents, session quality, audit evidence, and MCP oversight. This guide covers both halves, verified against Anthropic's docs as of July 2026 and against the live telemetry export of our own agent fleet, plus the OpenTelemetry route that fills the gaps.

What Claude Code enterprise analytics answer out of the box

Anthropic runs two analytics dashboards, split by how you buy. Claude for Teams and Enterprise organizations get claude.ai/analytics/claude-code; organizations on the Claude API get a dashboard in the Console. Both show daily active users and sessions, lines of code accepted, and suggestion accept rate: the percentage of edit proposals users take. The Console version adds daily spend in dollars and a per-user table of cost and accepted lines for the month. The Team and Enterprise version adds the more interesting half: contribution metrics.

Contribution metrics connect Claude Code sessions to merged pull requests through a GitHub app. The mechanism is worth understanding before you present the numbers to anyone. When a PR merges, added lines from the diff get matched against Claude Code session output, using a window of 21 days before to 2 days after the merge; whitespace and quoting get normalized first. A PR counts as "with Claude Code" if at least one line matches with high confidence. The matcher skips lock files, build artifacts, and generated code, and drops attribution for code a developer substantially rewrote. Matching PRs get a claude-code-assisted label right in GitHub, so you can query them yourself. Anthropic describes the counting as deliberately conservative, so read the dashboard as a floor on impact rather than a ceiling.

Two caveats before you promise any of this to your CISO. Contribution metrics require the GitHub app, and organizations with zero data retention enabled do not get them; the dashboard falls back to usage metrics only. The claude.ai dashboard also covers claude.ai seats specifically, while API-key usage shows up on the Console side instead.

The APIs behind the dashboards

Three APIs matter, and which ones you get depends again on how you buy.

The Claude Code Analytics API returns one record per user per day: sessions, lines of code added and removed, and commits and pull requests created through Claude Code. Each record also carries accept and reject counts per editing tool, plus token usage and estimated cost broken down by model. Data lands within about an hour, and the endpoint is free to call with an Admin API key:

curl "https://api.anthropic.com/v1/organizations/usage_report/claude_code?starting_at=2026-07-01" \
  --header "anthropic-version: 2023-06-01" \
  --header "x-api-key: $ADMIN_API_KEY"

It exists precisely for the build-our-own-dashboard instinct, so nothing needs scraping.

The Usage and Cost Admin API covers everything your organization does on the Claude API, not just Claude Code. It returns token counts bucketed by minute, hour, or day, groupable by model, workspace, API key, or service tier, plus a daily cost report in cents. If Claude Code runs alongside other Claude workloads, this is where finance reconciles the bill.

Claude Enterprise organizations on claude.ai use a third one, the Enterprise Analytics API, with its own key type and data starting January 1, 2026.

One coverage note that bites teams on AWS or GCP: the Analytics API only tracks Claude Code running against the Claude API. Sessions through Bedrock, Vertex, or Foundry do not appear in it. That stings, because those deployment paths are common in exactly the enterprises that need the reporting most. The client-side telemetry further down does not have this limitation.

Where the built-in Claude Code usage tooling stops

None of what follows is a knock on Anthropic. A vendor's analytics have a natural boundary at the vendor's own product, and these four questions all live past it.

Cross-vendor visibility

Most organizations at rollout scale run more than one agent: Cursor seats here, Copilot from an old contract, Codex on ChatGPT Business, Claude Code on Max seats. Each vendor's dashboard counts its own way. Anthropic attributes a PR on one matched line inside a 21-day window, and other vendors count their own way; summing the dashboards double-counts every PR that two tools touched. There is no referee. One European retail group put the resulting ask to us plainly: usage insight across Copilot and Claude Code without reading over developers' shoulders. The built-in dashboards cannot answer that; each one stops at its own vendor's edge.

Session quality

Every built-in number is a volume or adoption number: sessions, lines, tokens, accept rate. Accept rate is the closest thing to a quality signal, and it measures the moment of acceptance. A diff that gets accepted, merged, and reverted three days later scores identically to one that survives a year. Whether the output was any good lives in the transcript and in what happened to the PR afterwards. No token counter sees either.

Audit evidence

The dashboards aggregate by design, and compliance reviews ask the opposite kind of question: show me what the agent did in this session. Which commands ran, which permission prompts were auto-approved, who switched a session into a more permissive mode, which sessions touched the payments repo. EU AI Act timelines are turning internal AI usage into a documented-evidence problem for European companies. "We have a dashboard" and "we can produce session-level evidence" are different capabilities, and auditors ask for the second one.

MCP oversight inside Claude Code sessions

Sessions increasingly call MCP servers: Jira, internal APIs, databases. Allowlisting servers works well through checked-in settings, but the dashboards show no tool-level activity. "Which sessions called the production database MCP server last week, and with what" has no built-in answer. The raw material for one does exist, in telemetry.

The OpenTelemetry export path

Claude Code ships native OpenTelemetry export, and it is the mechanism that turns the four gaps above into ordinary engineering problems. Enabling it is a couple of environment variables:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=https://collector.internal:4317

With that set, metrics stream out: claude_code.token.usage, claude_code.cost.usage, session counts, lines of code, commits, pull requests, and active time, each tagged with user, organization, and model. The events go further: user prompts, tool results, every tool permission decision, permission mode changes, and MCP server connections, with a prompt ID correlating the events inside each turn. The docs also describe a distributed tracing beta, though when we ran the export ourselves nothing span-shaped arrived; treat spans as emerging and plan around metrics and events. Privacy defaults are sensible: prompt and response content stays redacted unless you opt in per signal with OTEL_LOG_USER_PROMPTS and friends. That is the difference between a telemetry rollout your works council reviews and one it blocks.

Three properties make this the enterprise path. It is enforceable: managed settings distributed by MDM can turn telemetry on org-wide, and users cannot override them. It is attributable: OTEL_RESOURCE_ATTRIBUTES stamps team and cost-center onto every metric, so per-team cost allocation stops being a spreadsheet exercise. And it is deployment-agnostic: the telemetry comes from the client, so it works the same on Bedrock, Vertex, or Foundry. That is exactly where the Analytics API goes dark.

It also travels across vendors. Codex has an [otel] section in its config that exports logs, metrics, and traces the same way. A single collector can therefore receive Claude Code and Codex sessions side by side, and OpenTelemetry is the only layer where that cross-vendor view is possible today.

What actually arrives on the wire

We run seven background Claude Code agents for our own operations, so before writing this section we pointed the fleet's telemetry at our own platform and read what came out. Four things the docs do not spell out:

The export is metrics and log events, not spans. Every log record arrived with traceId: undefined, under the scope com.anthropic.claude_code.events. Any session tree you see in an observability backend is reconstructed by the receiver from those events, so backends differ in how faithfully they rebuild the agent, LLM, and tool hierarchy. Worth asking your vendor how they do it rather than assuming spans exist.

Cost arrives self-reported per API request, with the full token split. Our test prompt was ten input tokens and cost $0.0199, because 16,908 cache-read and 8,940 cache-creation tokens moved with it. That context iceberg is invisible inside a monthly Console total and exact here, which is the difference between knowing Claude Code cost you $30k last month and knowing which team, session, and system prompt did it.

Identity attribution is built in whether you ask for it or not. Every metric datapoint and event carries the user's email, a hashed user id, organization id, session id, and terminal type, so per-person spend works out of the box. Per-team allocation took one extra variable: we stamp OTEL_RESOURCE_ATTRIBUTES with an agent slug per session and it arrived as filterable metadata. One wrinkle to decide deliberately: our platform's default PII redaction rewrote the emails to [EMAIL_ADDRESS] in stored traces, so a per-person cost view needs either the hashed id or an explicit redaction-level choice. Your privacy review will want to make that call, not discover it.

Permission decisions ride along with tool events. Each tool event in our export carried the decision that allowed it (decision: accept, source: config), which turns "what is the agent allowed to do" from a settings screenshot into an auditable event stream.

The wiring itself was environment variables only: one shell profile snippet and one secret on the machine our agents run on, no framework changes, and no session restarts needed. The exception was our one Codex-runtime agent, which ignores these variables entirely; its export lives in ~/.codex/config.toml, which is exactly the cross-vendor fragmentation the collector layer is for.

Where LangWatch fits

LangWatch, where I work, is an observability and evaluation platform for LLM applications, built on OpenTelemetry. That base is the one reason it belongs in this guide, and it is where the fleet telemetry above landed: sessions arrive with no SDK and no integration project, and the gap list becomes query work. Sessions grouped by team and cost, transcripts retained as audit evidence, evaluators (code checks or LLM judges) scoring sessions against your own definition of a good outcome. Codex and any other OTel-emitting agent land in the same place. It runs EU-hosted or self-hosted, ISO 27001 certified and GDPR compliant. For adoption reporting, Anthropic's own dashboard is better and costs nothing. LangWatch picks up the session-level, quality, and cross-vendor questions the dashboard is not built to answer.

A Claude Code enterprise rollout order

If you are starting this quarter, this sequence avoids rework. Enable the analytics dashboard first, since it is a toggle and gives you adoption curves from day one. Wire the Analytics API into whatever BI tool finance already reads, which is an afternoon of work and stops the monthly screenshot ritual. Decide MCP allowlists and permission deny rules in checked-in settings before habits form; retrofitting policy onto a hundred developers' muscle memory is much worse. If you also run Codex or Cursor, plan for the comparison question early, because someone in the next budget cycle will ask it. Our own take on that one is in the Codex vs Claude Code notes.

And turn on the OpenTelemetry export before you think you need it. The history only exists from the day you enable it, and the first audit request will ask about the past.