Claude Code OTel Export: The Business Case for Normalized Agent Telemetry

TL;DR: Claude Code's OpenTelemetry (OTel) export emits per-session metrics carrying token counts, dollar costs, and session durations, plus per-prompt events recording each model request and tool call. On its own, that stream measures activity. The business case comes from normalization: linking agent sessions to commits, pull requests, and tickets so you can regress story points completed against token spend. PR cycle time and rework rate sit alongside as guardrails confirming the spend is not creating bottlenecks or quality drops. minware's patent-pending hypercube data model automates that linkage, which moves the cost from pipeline maintenance to report configuration.

Claude Code bills climb quickly once an org moves past pilot use, and the CFO's question is simple: is higher token spend buying more delivery, or just a bigger bill? Pull request merge counts prove code output rose while saying nothing about whether that code delivered value. A regression slope is the return on investment (ROI) figure that actually answers it: token spend regressed against a value delivery metric like story points completed. That calculation only works on normalized telemetry.

This article makes the business case for normalizing Claude Code telemetry alongside your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps, and your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues. Normalizing all three lets you correlate token spend against delivery outcomes. It covers what the export emits, the backfill limit, what normalization involves, how sessions link to delivery artifacts, what becomes answerable once they do, the engineering investment, and a build vs. buy framework for deciding who should own the pipeline.

Turning Claude Code telemetry into delivery metrics

Enabling the export is the easy part: a handful of environment variables. The hard part is what the export produces, raw observability data describing what the agent did, with no built-in connection to what the organization shipped. Point that stream at a generic application performance monitoring (APM) tool and you get clean charts of prompt latency, but no answers about delivery. Making it answer business questions requires structure that the export does not provide on its own.

Reading what the export emits

Claude Code exports metrics covering sessions, token usage, costs, and activity, structured according to the data models the OpenTelemetry specification defines. It also emits structured events through the OpenTelemetry logs signal, recording each model request and tool call with its duration. Token counts arrive broken out by input, output, cache read, and cache creation, with an estimated dollar cost attached to each API request.

Content is redacted by default. Prompt and response text arrives redacted unless you opt in. Tool parameters, tool content, and custom command names are excluded on the same basis. Tool names themselves are always included, so you can see that an agent ran an edit or a shell command without seeing what it ran, per the Claude Code monitoring documentation.

The configuration is a handful of environment variables, deployed centrally rather than by each developer:

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-collector.example.com:4318
OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer <token>"

Those variables are the whole of the client-side setup. The hard problem this article is about starts downstream of them.

The export does count commits, pull requests created, and lines of code alongside the token figures. Those arrive as session-scoped totals. Nothing ties a given session to the specific pull request it produced, the ticket it advanced, or the roadmap item it moved, which is the connection a CFO is asking about.

Planning around the backfill limit

OpenTelemetry has no historical backfill for activity before it was configured, so connect it as early as you can. Wiring the collector before you need the report costs less than reconstructing the period afterwards.

Where coarser history is needed, the Claude Code Analytics API reports per user, per model, per day and does support backfill. OpenTelemetry is the finer-grained of the two, reporting at per-prompt, per-session granularity. Most orgs end up running both, the Analytics API to reach back and OpenTelemetry to go deep from the point of configuration forward.

On Amazon Bedrock, Google Cloud's Agent Platform (formerly Vertex AI), or Microsoft Foundry, that pairing is not available. Claude Code does not send metrics from those providers back to Anthropic, so the Analytics API does not cover the usage. OpenTelemetry is the most direct route, though a Claude apps gateway or an LLM gateway can serve the same purpose. minware's guide to getting reporting data out of Claude Code compares the available routes.

Standardizing your agent telemetry

Normalization is the prerequisite for connecting AI spend to business outcomes. It means converting each vendor's payload into one canonical model so a token dollar means the same thing across tools.

Without it, every team that wires its own exporter invents its own schema. The result is shadow telemetry: multiple dashboards with multiple definitions of cost, none of them comparable. This is exactly why OpenTelemetry publishes semantic conventions: shared attribute naming, so a token dollar means the same thing everywhere. The same problem reappears one layer up when you compare tools against each other.

Token usage data is broadly available across AI coding tools through vendor APIs and OpenTelemetry exports. Currently that means GitHub Copilot via API, Cursor via API, Claude Code via both, and Codex via OpenTelemetry. An org running two of those tools needs one normalized layer to see total AI spend in a single report.

minware integrates with any AI coding tool. Where a vendor exposes no usable telemetry at all, AI commit and pull request authorship can still be read directly from version control.

Linking agent data to ROI metrics

Linking sessions to delivery artifacts is where the export stops helping. Claude Code adds a Co-Authored-By trailer to the commits it creates, though the attribution setting lets an organization change or hide it. Developers also make commits manually after an agent did the work. Those sessions carry no structured connection to any commit, pull request, or ticket.

Recovering the link requires modeling what commit and ticket each person was working on at any given time, which is the hard problem minware's patent-pending hypercube data model solves. By tracking the timeline of work across systems, relationship recovery connects sessions to their delivery artifacts even when no structured tag exists.

Answering the ROI question with normalized data

Normalized Claude Code telemetry answers questions that raw observability data cannot. The primary ROI metric is a regression of a value delivery metric against token spend, read off the slope. Story points completed is the usual choice where teams estimate, with roadmap delivery or tickets completed standing in where they do not.

That slope measures delivery per dollar. If the line shows 0.02 story points per dollar of spend, every additional dollar of token cost is associated with 0.02 additional story points shipped. minware's AI ROI report plots that regression against real data, alongside the equivalent charts for commits, lines committed, and pull requests merged.

The R-squared value shows how much of the variation in delivery the spend actually explains. A low R-squared value means token spend is not strongly correlated with story points completed. That says only that. It does not identify what else is driving delivery.

Two selection effects sit behind any conclusion drawn from that slope. Developers choose whether to reach for an agent, so straightforward work skews toward AI while the hardest problems skew away from it. The people who adopt earliest are often the strongest performers already. Name both when you present the regression.

Checking PR cycle time for review bottlenecks

PR cycle time runs from a branch's first commit to when its pull request merges. As agent output rises, the metric should hold steady or fall. Cycle time rising alongside spend means the extra volume is queuing somewhere, most often waiting on a first human review, so the constraint has moved from writing code to reviewing it. That points at review capacity as the fix.

Checking rework rate for quality drift

Rework rate divides bugs created by pull requests merged. Holding flat as throughput climbs is the signal that quality is keeping pace. Climbing with spend means the additional code is arriving with additional defects, which cancels part of the delivery gain the slope appears to show. minware's rework rate is broader than DORA's deployment rework rate, catching quality problems that never reach a failed deployment.

Together, the value delivery slope and both guardrails are what hold up in an executive review.

Estimating the real engineering investment

Building a custom pipeline to normalize Claude Code telemetry with version control and project management data requires ongoing engineering resources. The initial integration takes weeks: writing parsers for OpenTelemetry data, mapping sessions to commits, resolving developer identities across systems, and building reports that connect token spend to delivery metrics.

The real cost arrives later, when schema and format changes break parsers. New team members then need onboarding on the model, and every stakeholder question about how a metric is calculated lands on whoever built it.

minware absorbs that maintenance burden. The platform normalizes Claude Code telemetry alongside your version control and project management systems without custom pipeline code. Pre-built AI impact reports connect token spend to story points completed, PR cycle time, and rework rate. The hypercube data model handles relationship recovery, identity matching, and data normalization automatically. Sessions link to commits and tickets without manual tagging.

Deciding who should own the pipeline

The build vs. buy decision comes down to three questions:

• Do you have engineering capacity to maintain a custom pipeline?

• Do you need reporting flexibility beyond what a vendor offers?

• Can you afford the opportunity cost of building instead of shipping product?

Building makes sense for a small team with simple processes that only needs lightweight tracking. minware can match most data models directly, and a team that already runs extract, transform, load (ETL) pipelines for other business systems rarely has spare capacity to build and maintain one more. The cost is ongoing: someone owns the pipeline, the schema, and the explanation when a number does not match expectations.

Buying makes sense when:

• you need defensible answers quickly

• maintenance would pull engineers off product work

• transparent metric definitions matter more than schema control

Buying does not remove configuration work. A report or metric definition still has to be configured to answer an org-specific question, either by your team or by a customer success agent, and that configuration effort is the real constraint rather than the onboarding timeline.

The choice is about who maintains the pipeline and who explains the methodology when the CFO asks how a number was calculated. minware lists Professional pricing publicly at $25 per contributor per month with no seat minimum, and the trial is self-serve.

Connecting the bill to delivery

The OTel export gives you the raw material, per-session metrics carrying token counts and dollar costs. Per-prompt events record every model request and tool call. Normalization gives you the answer. A dashboard of prompt latency does not supply a regression slope with guardrails, which is what the CFO is asking for. Story points completed per dollar of token spend, read off the line, with PR cycle time and rework rate alongside it, is what survives board scrutiny. The export is the starting point, and normalization is what makes it defensible.

Start a 14-day free trial at minware.com, no credit card required, and connect your first data source.

FAQs

Does enabling Claude Code OTel export require changes to every developer's machine?

No. Administrators deploy the configuration for all users through Claude Code's managed settings file, which takes precedence over any user, project, or local value a developer sets.

What if I already have an APM tool collecting the OTel stream?

APM tools answer latency and error rate questions well. minware normalizes telemetry across tools into one data model. It resolves developer identities across systems, recovers the relationships between agent sessions, commits, and tickets, then regresses story points completed against token spend. APM tools do none of those things, so the two uses are complementary.

Is the token spend figure in the OTel export what I actually paid?

Not necessarily. Claude Code computes the figure locally from token counts at list price. For users on a Pro or Max plan, where usage is included in the subscription, that figure does not represent an amount billed. If your organization pays contracted rates, an administrator can set the modelPricing managed setting so the reported figure uses those rates. Treat it as directionally correct for correlation and reconcile against billing data for precise cost attribution.

Key terms glossary

Token spend: The dollar cost of AI tool usage, as reported by AI tool APIs or OpenTelemetry. Distinct from token consumption, which is a count of tokens. For users on flat-rate plans, reported spend may differ from the amount billed.

Story points completed: The total of the story points field for completed tickets. A value delivery metric, and the usual choice for regressing against token spend where teams estimate in points.

PR cycle time: The time from a branch's first commit to when its pull request merges. A workflow guardrail confirming that rising AI output is not creating a bottleneck in the review or merge stage.

Rework rate: The number of bugs created, divided by the number of pull requests merged. A quality guardrail confirming that code quality is holding as throughput rises. Broader than DORA's deployment rework rate, which counts only unplanned deployments made in response to a production incident.

R-squared: The share of variation in one metric that another explains, on a 0 to 1 scale. A low value means the two are not strongly correlated. It is not a measure of confidence or statistical significance, which minware does not calculate. Export the data to a spreadsheet or an external calculator for significance testing.

Agent session: The unit of Claude Code usage, representing a multi-step task executed by the coding agent, distinct from a single prompt. An activity metric showing whether the tool is being used, without a delivery claim on its own.

OpenTelemetry (OTel): An open standard for emitting, collecting, and exporting observability data from software systems. Claude Code uses it to export per-session metrics covering token usage, dollar costs, and durations. It also emits per-prompt events recording each model request and tool call. It reports at per-prompt, per-session granularity, with no historical backfill for activity before it was configured.