Claude Code cost per developer: the 8 metrics to instrument before you quote a figure

This page has no euro figure, and that is deliberate

We are not going to tell you what Claude Code costs per developer per month, because we do not yet have ninety days of our own data and neither does anyone else who is willing to show their working. What follows is the measurement design instead: what to instrument, what each source of data can and cannot tell you, and which of the resulting numbers will embarrass you in a budget review.

That is not modesty. Cost per developer is a product of four things that vary enormously between organisations: which model answers each step, how much of the prompt prefix is cacheable, how many turns a task takes before it lands, and whether engineers run one agent or four in parallel. Any two of those can move the monthly figure by a factor that makes a borrowed benchmark worse than no benchmark, because a borrowed benchmark gets quoted with confidence.

What does transfer is the instrumentation. Anthropic documents eight OpenTelemetry metrics for Claude Code, three Admin API report endpoints, and a set of defaults that decide whether your numbers are attributable at all. Those are stable enough to build on, and they are the subject of this piece.

The figure that comes out at the end will be yours. It will not match ours when we eventually publish one, and it should not.

The instrumentation checklist, in the order it has to be done

Enable telemetry centrally before anyone opts in individually, because a metric that exists on four laptops and not on the other forty produces a number that is worse than none. Managed settings are the mechanism: environment variables defined there have high precedence and cannot be overridden by a developer, and the file can be distributed through MDM alongside everything else you already push to engineering machines.

The checklist below is the artefact. It is ordered by dependency, not by effort. The two steps that get skipped are the chargeback label and the attribute pruning, and both get rediscovered a quarter later — the first when finance asks for a split nobody can produce, the second during a data protection review.

One detail worth knowing before you debug a silent collector: Claude Code does not pass OTEL_ variables to the subprocesses it spawns, including the Bash tool, hooks, MCP servers and language servers. Instrumentation you expected to inherit will not.

The artefact

The ten steps

1. Decide the identity question first. Team-level attribution or per-developer attribution is a policy decision, not a configuration one, and it determines what you are allowed to store. Everything below changes depending on the answer.
2. Stand up the collector before enabling any client. Point it at a metrics backend you already operate, and terminate TLS properly — the OTLP endpoint will carry a bearer token in OTEL_EXPORTER_OTLP_HEADERS.
3. Push managed settings to every machine, not a wiki page telling developers to export variables. Setting OTEL_EXPORTER_OTLP_ENDPOINT centrally also removes conflicting developer-set per-signal endpoints at startup, and logs a warning you can see with claude --debug.
4. Set OTEL_RESOURCE_ATTRIBUTES with the team, department or cost centre you intend to charge back to. Keep the values low-cardinality: every custom key becomes a label on every metric series, and a per-project label on a large team is how a metrics bill starts competing with the token bill.
5. Turn off the attributes you decided not to keep. OTEL_METRICS_INCLUDE_ACCOUNT_UUID and OTEL_METRICS_INCLUDE_SESSION_ID both default to true, and session ID in particular is high cardinality by design.
6. Leave content logging alone unless legal has signed it. OTEL_LOG_USER_PROMPTS, OTEL_LOG_TOOL_DETAILS, OTEL_LOG_TOOL_CONTENT and OTEL_LOG_RAW_API_BODIES all default to disabled, and each one moves source code and prompt text into your logging pipeline.
7. Provision an Admin API key and pull the Analytics API daily into the same warehouse as the metrics. Anthropic states it is free to use for all organisations with access to the Admin API. It is not the only per-user cost view: API customers see per-user spend for the current month in the Console dashboard at platform.claude.com/claude-code, and Team and Enterprise plans export a per-user, per-model spend report as CSV from Settings → Analytics. The Analytics API is the one you can schedule into a warehouse, which is why it is the one on this list.
8. Reconcile weekly against the Cost API. The OpenTelemetry number is an estimate; the cost report is what finance will see. Track the gap as a percentage and investigate when it moves, not when it is non-zero.
9. Record the baseline before anyone tunes anything. Model routing, caching and prompt changes all land after the measurement starts, and without a baseline you cannot attribute a saving to any of them.
10. Write down the denominators. Cost per what, over which window, counting which people — before the first chart exists, not after somebody disputes it.

The managed settings file

The managed settings file below is the whole client-side configuration, and every key in it comes from Anthropic's monitoring reference at code.claude.com/docs/en/monitoring-usage. The last two lines are the team-attribution decision expressed as configuration: both of those attributes default to true, so switching them off is an active choice that has to be made once, centrally, rather than negotiated per machine. Note that user.email is still attached whenever it is available and has no opt-out flag, which is why the collector remains the enforcement point rather than the client.

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel.internal.example.com:4317",
    "OTEL_RESOURCE_ATTRIBUTES": "department=engineering,team.id=platform,cost_center=eng-123",
    "OTEL_METRICS_INCLUDE_ACCOUNT_UUID": "false",
    "OTEL_METRICS_INCLUDE_SESSION_ID": "false"
  }
}

Turning eight metrics into one figure a CFO recognises

The eight metrics exist so you can compute three ratios, and the ratios are what a budget conversation is actually about. None of them requires a number from us; all of them require a denominator you have to choose and write down.

Cost per merged pull request is the honest headline. Take claude_code.cost.usage summed over the window, and divide by merged pull requests from your version control system — not by pull_requests_by_claude_code, which counts what was created rather than what landed. The gap between those two denominators is itself worth watching.

Cost per active hour is the ratio that converts into an FTE comparison. claude_code.active_time.total is in seconds and carries type=user and type=cli, so user-attributed active time divided into cost gives a dollar-per-hour figure you can hold against your own loaded engineering rate. We are not supplying that rate — every organisation's is different and most already know theirs to the euro.

Cost per developer per month is the one everybody asks for and the one to publish last, because it is the most sensitive to who counts as a developer. Distinct actors with at least one session is a defensible denominator. Headcount in the engineering org is not, and using it is how a tool that is cheap per user gets reported as expensive per seat.

Run all three for a full quarter before drawing a trend. Thirteen weeks covers enough release cycles, holiday weeks and model changes that the curve means something. Four weeks measures the novelty period.

Denominators

# Client-side metric reference:
# https://code.claude.com/docs/en/monitoring-usage
#
# Per-user daily aggregates. Free, Admin API key required.
# https://platform.claude.com/docs/en/manage-claude/claude-code-analytics-api
curl -sS "https://api.anthropic.com/v1/organizations/usage_report/claude_code?starting_at=2026-09-01&limit=1000" \
  -H "anthropic-version: 2023-06-01" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY"

# The reconciliation source. Daily buckets only; group by workspace.
# https://platform.claude.com/docs/en/manage-claude/usage-cost-api
curl -sS "https://api.anthropic.com/v1/organizations/cost_report?starting_at=2026-09-01T00:00:00Z&ending_at=2026-10-01T00:00:00Z&group_by[]=workspace_id&group_by[]=description" \
  -H "anthropic-version: 2023-06-01" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY"

# Denominators, decided before the first chart:
#   cost per merged PR   = sum(claude_code.cost.usage) / merged PRs from git
#   cost per active hour = sum(claude_code.cost.usage)
#                          / (sum(claude_code.active_time.total{type="user"}) / 3600)
#   cost per developer   = sum(claude_code.cost.usage)
#                          / count(distinct actors with num_sessions > 0)

What you have after a quarter of this

A cost per merged pull request with a stated denominator, a per-team split that came from a label rather than an argument, a reconciliation gap between your estimate and Anthropic's cost report that you can explain, and a baseline that makes the next optimisation provable instead of plausible.

You will also have found at least one thing you were not looking for. In every cost instrumentation project we have run — across LLM workloads generally, not Claude Code specifically — the surprise has never been the headline number. It has been the distribution underneath it.

What you will not have is our figure, and you do not want it. You want yours, measured on your repositories, with your model mix, over a window long enough that the next model release does not invalidate it.

Keep reading

• LLM gateway for Claude: one route, every model, spend attributed per team
• What Claude costs: the four things that actually drive the bill
• LLM cost optimisation: caching, routing and per-department attribution
• Claude Code for enterprise: the three sign-off blockers