Claude Code Usage Data: What to Capture and What to Skip

TL;DR: Your finance team does not care how many agent sessions ran last sprint. They care whether rising token spend is producing more completed value, measured as a value delivery metric such as story points completed. With Claude Code running $150 to $250 per developer per month at typical enterprise usage, the defensible answer comes from a linear regression of token spend against that value delivery metric, with rework rate as a quality guardrail and PR cycle time as a workflow guardrail alongside it. Claude Code exposes two data pipelines: OpenTelemetry (OTel) exports for session-level granularity and the Claude Code Analytics API or Claude Enterprise Analytics API (depending on your organization type) for historical backfill. minware connects version control, project management, and AI tool data into a normalized layer so that correlation runs in pre-built AI impact reports.

A note on naming: Anthropic splits the pull-based reporting route into two separate products by organization type: the Claude Code Analytics API for Claude Console customers, and the Claude Enterprise Analytics API for Claude Enterprise plan organizations. Both are referred to together below as "the Analytics APIs" except where the distinction matters.

Claude Code emits more telemetry than any engineering leader needs, and the fields easiest to capture are the ones least able to answer a budget question. This guide gives engineering leaders a practical filter for Claude Code usage data: which fields to capture, which ones to skip, and how to structure a regression that survives a board review.

Defining the right Claude Code usage metrics

Claude Code emits metrics and event logs, plus traces as an opt-in beta. Metrics cover token counts, costs, and cache activity. Event logs cover prompt events, tool decisions, and errors.

The volume is manageable. The difficulty is that most engineering leaders default to reporting whatever is easiest to capture, which tends to be activity data with no connection to delivery impact.

The right framework splits Claude Code data into three categories. Usage metrics cover whether and how often the tool is running. Contribution metrics cover what the tool produced in version control and ticketing. Cost metrics cover what you paid for that activity. Only when all three are linked do they support a defensible return on investment (ROI) claim.

Filtering meaning from raw logs

The unit of analysis is the agent session, a continuous sequence of prompts and autonomous tool executions that represents a coherent piece of developer work. Counting how often a command was run measures something thinner: how many times someone started, with no signal about what the agent actually did.

Anthropic's Claude Code monitoring documentation covers the full telemetry schema. OpenTelemetry exports, once enabled, push structured data including token usage, cost broken down by user and model, plus session activity and tool decisions. That data maps to agent sessions.

Justifying AI costs to finance

Finance has one question: is higher token spend buying more delivery, or just a bigger bill? Anthropic puts typical enterprise usage at $150 to $250 per developer per month, which is large enough to attract scrutiny at any meaningful headcount.

Token spend on its own is not evidence of value. It is a proxy for activity, and activity only proves the tool is running. The correlation between spend and delivery outcomes is the ROI evidence itself.

When you can show that teams spending more on tokens are completing more story points per sprint while cycle time holds steady, you have a defensible answer. Without it you have an adoption dashboard that will not survive the next budget review.

Selecting data for defensible ROI reports

Claude Code exposes two reporting pipelines, and the choice between them shapes both your reporting capability and your maintenance burden.

Table 1: Claude Code data pipeline comparison

Attribute	OpenTelemetry export	Analytics API (Claude Code / Claude Enterprise)
Data flow	Push-based, near real time	Pull-based, daily aggregates
Granularity	Per-prompt and per-session	Per-user, per-model, per-day
Historical backfill	None, collection starts when enabled	Supported, history retained
Cost field	Dollar cost per request	Estimated cost per model per day
Cloud provider deployments	Works across every setup	Not covered for Bedrock, Google Cloud, or Microsoft Foundry
Setup effort	Managed settings deployed org-wide, plus a collector	An admin or analytics API key
Best suited to	Session-level diagnostics and real-time monitoring	Backfilling history and org-level regression analysis

Depending on your organization type, this is either the Claude Code Analytics API (Claude Console organizations) or the Claude Enterprise Analytics API (Claude Enterprise organizations). The two differ in backfill window, see 'Capturing Claude Code telemetry' below.

Tracking token spend by team and time period

With 90% of technology professionals now using AI at work, the meaningful variable has shifted from whether a developer used AI to how much they spent. A regression of delivery outcomes against token spend treats spend as a continuous variable, so non-AI work sits at zero spend and is included automatically without a separate binary split.

Token spend means dollar cost, not a count of tokens consumed. How comparable that figure is depends on how your developers authenticate. On Claude for Teams and Enterprise plans, usage draws from a per-seat allowance, and usage inside that allowance is not metered in dollars, so reported spend can sit above or below what you actually paid. Where developers authenticate through the Claude Console or a cloud provider, usage is billed per token and the spend figure lines up directly with delivery output.

Track spend per team per time window, either sprint or week. The regression needs variation in spend across those data points, whether from multiple teams, multiple time periods for a single team, or both, to produce a meaningful slope.

Agent session counts show whether the tool is being used. That makes them an activity signal, so keep them out of any regression claiming delivery impact. The full field list your reporting layer has to end up with is set out in the checklist at the end of this guide.

Linking token spend to delivery goals

The hardest part of building this data set is connecting agent sessions to the tickets and pull requests they produced. Claude Code automatically tags commits it creates, but developers frequently make manual commits during agent-assisted work. Anthropic's telemetry schema captures session-level data without linking those sessions to your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues, or to pull requests in your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps.

minware's data model recovers relationships between agent sessions, commits, pull requests, and tickets even when explicit links are missing. It does this by modeling what commit and ticket each person was working on at any given time. Any gap in branch-to-ticket linking quietly undercounts AI-assisted work in your story points completed metric, which biases the regression and understates ROI.

Entity resolution handles mismatched usernames across your AI tools, version control, and project management systems automatically, so you do not need clean data to start.

Filtering out vanity metrics in Claude Code logs

Vanity metrics are fields that are easy to capture, look informative in a dashboard, and fail to answer whether the tool delivered business value. Presenting them to a board or finance team damages credibility, because anyone who tracks delivery data will recognize that the numbers say nothing about outcomes. As minware's guide on how developers game sprint metrics covers, metrics without outcome linkage are also easy to optimize without improving delivery.

Two of these arguments are largely settled. Seat activation and login counts have been discounted for years. Acceptance rate measures whether a developer approved a proposed edit, which is a permission signal rather than a delivery signal, and Anthropic reports accept and reject counts per tool for exactly that purpose. The argument still live in the market is the one below.

Reading code output volume correctly

AI coding agents make it easy to generate large volumes of code quickly. Tracking lines of code, commit counts, or pull requests merged in isolation is the throughput trap: it confirms that code is being produced without confirming that the code is delivering value.

DORA's 2025 research found that higher AI adoption is associated with a rise in both delivery throughput and delivery instability. Code ships faster, and the cleanup bill compounds behind it. As minware's change failure rate research covers, quality signals require tracking what happens after merge rather than at the point of generation.

The pattern that surfaces in delivery data is pull requests merged rising while PR review rate falls. Pair any throughput metric with a quality guardrail: pull requests merged pairs with rework rate, which counts bugs created divided by pull requests merged, and with PR review rate.

"Minware gives us clear visibility into code quality, defect rates, and development health with quality SDLC metrics." - George V. on G2

Mapping developer AI activity to business results

Connecting token spend to business results requires three links in a chain: from Claude Code telemetry to version control activity, from version control to project management tickets, and from tickets to roadmap outcomes. Breaking any one link leaves your delivery metrics missing a portion of AI-assisted work, which biases your regression.

Linking token spend to story points completed

The primary ROI methodology is a linear regression of a value delivery metric like story points completed against token spend. Y represents that value delivery metric, X represents token spend in dollars, the slope shows the marginal delivery value per dollar spent, and the intercept represents the baseline delivery rate when token spend is 0. The slope is the ROI figure itself.

minware's guide on calculating sprint velocity walks through adding up completed work at the end of each sprint, which is the Y-axis value for each team-sprint data point in your regression.

The R-squared value reports how much of the variation in the outcome metric the token spend variable actually explains. Run a separate regression for each delivery outcome you care about: three outcomes means three regressions, each with its own slope and R-squared.

The regression draws its variation from teams and time periods. A single team tracked across enough sprints at different spend levels works as well as multiple teams compared in the same window, as long as spend varies across the data points. Name the confounders when you present it. Teams with higher token spend may also be the teams working on better-scoped, more estimable work, which would lift the slope without AI causing any of it.

Using cycle time to validate AI impact

PR cycle time, measured from a branch's first commit to when its pull request merges, functions as a guardrail on your ROI claim rather than the claim itself. If token spend is rising and story points completed are rising while PR cycle time also climbs, the code volume is creating a review bottleneck that will eventually constrain delivery.

PR cycle time should hold steady or decrease as token spend rises, confirming that increased AI-assisted code volume is not overwhelming the review stage. minware's efficiency reports surface PR cycle time alongside work in progress (WIP) metrics for exactly this diagnostic purpose.

Using an AI-versus-non-AI comparison as a supporting check

Where a genuine non-AI cohort still exists, comparing AI-assisted work to non-AI work from the same teams and time periods provides a useful supporting check. Keep it running on outcome metrics rather than spend, and keep it secondary to the regression.

Name two confounders when presenting results. Task-level selection bias means developers choose whether to use AI per task, so someone who reaches for AI on straightforward work and avoids it on the hardest problems produces data showing non-AI work is slower. Person-level selection bias compounds it, since early adopters are often already the strongest performers. Readers who run these analyses themselves will already be thinking about both.

Capturing Claude Code telemetry: OTel vs. Analytics API

Anthropic exposes Claude Code usage data through two independent pipelines, each suited to a different reporting need. Anthropic's own naming differs from the shorthand used here: the pull-based route is the Claude Code Analytics API for Console customers and the Enterprise Analytics API for organizations on the Claude Enterprise plan.

OpenTelemetry export is push-based and provides real-time, session-level granularity. Telemetry is off by default and is turned on through managed settings deployed across the organization, which lock the configuration and override anything an individual developer has set. Once enabled, it pushes token usage, session activity, tool decisions, and cost breakdowns to any OTel-compatible collector. It provides no historical backfill, so observability starts from the day you enable it.

The Analytics APIs are pull-based and provide per-user, per-model, per-day granularity. They support historical backfill, which makes them useful for teams that did not configure OTel from the start of their rollout. If your developers reach Claude through a cloud provider rather than through Anthropic directly, these APIs do not cover that usage, and OpenTelemetry export is the route that works across every setup.

Filtering key Claude Code data fields

The fields worth capturing are split across two telemetry surfaces. From the claude_code.api_request event log:

• session.id

• input_tokens and output_tokens: token consumption per request, reported separately

• cost_usd: dollar cost per request

• cost_usd_micros: estimated cost in millionths of a US dollar, emitted as an integer. Use this instead of cost_usd where floating-point precision matters in a data warehouse

• model: which Claude model ran the session

From metrics:

• session.id: the unique identifier for an agent session, enabled via the OTEL_METRICS_INCLUDE_SESSION_ID environment variable, used to link telemetry records to version control activity

• claude_code.token.usage: token consumption, available when capturing metrics rather than event logs

• claude_code.cost.usage: cost in USD, available when capturing metrics rather than event logs. Prompt text is redacted by default and only reaches your pipeline if you explicitly turn it on in Claude Code's telemetry settings. Leaving it redacted still supports delivery correlation, since the regression runs on spend and outcome data.

Weighing the total cost of ownership in a custom pipeline

Piping OpenTelemetry output into a script that writes to a spreadsheet is the lowest-friction way to start, which is why many teams reach for it first. It can be built quickly. It also carries a total cost of ownership (TCO) that runs indefinitely, as Anthropic updates its telemetry schema, as format structures shift, and as your team grows beyond the scope of one developer's setup.

When a field name or data type changes in the telemetry export, every custom script becomes an incident requiring developer time to diagnose and fix. That burden grows with each additional tool integration, and it compounds as your team scales.

The recurring cost most teams underestimate is not the initial build. It is answering "how exactly is this calculated" every time a stakeholder asks, indefinitely, from whoever built the pipeline.

Table 2: Build vs. buy framework

Attribute	Custom pipeline on OTel or the Analytics API	minware normalized data layer
Initial setup	Collector, storage, and normalization logic	Connect integrations, configure teams and reports
Schema maintenance	Your team owns every update	Vendor-managed
Entity resolution	Requires custom logic for mismatched usernames	Automated across version control, AI tools, and project management
Outcome correlation	Manual regression in spreadsheets	Pre-built AI impact reports
Multi-tool normalization	Separate handling per tool	Single data layer for Claude Code, Cursor, and GitHub Copilot
Data lineage transparency	Whatever your team documents	Fully visible metric formulas

minware normalizes token spend and session data from Claude Code, Cursor, and GitHub Copilot into a single reporting layer, using vendor enterprise APIs and OpenTelemetry depending on the tool. That lets you compare AI-assisted work across tools in the same report.

Answering a question specific to how your organization works still means configuring a report or a metric definition for it, either yourself or through a customer success agent. That configuration effort is the real constraint, not the connection step.

"What I like best about minware is its flexibility. The platform comes with a great set of engineering reports out of the box, so you can start getting value immediately." - Verified user on G2

Avoiding common Claude Code tracking pitfalls

Setting up telemetry is the technical half of AI ROI reporting. The strategic half is aligning the organization on what the data is supposed to answer before anyone starts collecting it. Most tracking failures start in the process, well before any telemetry is configured.

Moving team goals beyond adoption

Adoption is the goal most rollouts start with, and it works as a leading indicator while the rollout is under way. It becomes a trap when it stays the primary metric after the rollout is complete. DORA's 2025 research argues that leaders need to move past encouraging adoption toward measuring whether the tool is being used effectively.

Shift team goals from adoption to delivery improvement. Sprint completion and project completion against due dates both map to outcomes finance and the board can evaluate, and minware's predictability reports cover both.

Defining success before tracking data

Collecting data without a hypothesis produces noise. Before deploying telemetry or connecting the API, define what you are trying to optimize. Three common targets, each with a counterpart that catches the failure mode of optimizing the primary metric alone:

1. Delivery: story points completed as primary, with rework rate as the guardrail, since it counts bugs created divided by pull requests merged

2. Flow: PR cycle time as primary, with PR review rate alongside it to confirm that faster merges are not coming from skipped reviews

3. Quality: rework rate as primary, with change failure rate alongside it, since a high change failure rate signals a more severe problem needing immediate attention

Pick one primary target before running regressions. minware's quality reports keep these categories separate, so you can focus on the right set without mixing delivery and quality signals in a single view.

Connecting telemetry as early as you can

The teams that produce the most defensible AI ROI analysis connected telemetry well before they needed to defend the investment. Connect your OTel pipeline or the Analytics API as soon as Claude Code is in production. The Analytics API supports historical backfill, so if you have already rolled out without telemetry configured, that history is still recoverable at a coarser daily grain.

Give the data enough time to cover several sprints at different spend levels, whether across one team or several. A regression needs spread in the independent variable to produce a slope worth reading, and the first weeks after a rollout rarely provide it.

Assembling the minimum viable data set

The checklist below is the minimum for a defensible ROI report. Everything beyond it adds diagnostic depth once you have established the primary correlation.

Minimum viable ROI data checklist:

• Token spend per team per sprint or week, from Claude Code OTel export or the Claude Code / Claude Enterprise Analytics API

• A value delivery metric such as story points completed per team per sprint or week, from your project management system

• PR cycle time trend, from your version control system

• Rework rate, from version control and project management data

• Model, to account for cost differences across Claude model versions

• Entity resolution confirming Claude Code users match version control and ticketing identities

• Session-to-delivery-record linking, connecting agent sessions to the commits, pull requests, and tickets they produced, even where no explicit link exists

• Enough elapsed time to cover several sprints across teams running at different spend levels

Building a report that survives the next budget review

The capture list is short. Token spend, story points completed, PR cycle time, and rework rate, connected across the same teams and time periods, are enough to produce a slope you can defend in an executive review. Credibility comes from the correlation you can show and the confounders you are willing to name. The volume of telemetry sitting behind it matters far less.

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

FAQs

How do I prove Claude Code ROI to the board?

Run a linear regression of a value delivery metric such as story points completed against token spend across teams and time periods, then read the slope as the marginal delivery value per dollar spent. Cite the R-squared value to show how much of the variation in that metric the spend explains. Include rework rate as a quality guardrail and PR cycle time as a workflow guardrail alongside the delivery metric.

What is the minimum data needed for Claude Code ROI reporting?

A defensible ROI report requires token spend from your AI tool telemetry, a value delivery metric such as completed story points from your project management system, and PR cycle time from your version control system. Those three fields, connected across the same teams and time periods, are enough to run a regression and produce a defensible slope. minware's pre-built AI impact reports run that correlation once the sources are connected.

Can I track Claude Code usage without setting up OpenTelemetry?

Yes. The Claude Code Analytics API or Claude Enterprise Analytics API (depending on your organization type) provides per-user, per-model, per-day usage data and supports historical backfill, which makes it useful for teams that did not configure OTel from day one. OTel gives session-level granularity with no historical backfill. The Analytics APIs' aggregated view is sufficient for org-level ROI reporting.

Does the reported token spend figure match what we actually pay?

It depends on how your developers authenticate. On Claude for Teams and Enterprise plans, usage draws from a per-seat allowance that is not metered in dollars, so the reported figure is an estimate priced at standard list rates and can sit above or below your actual bill. Where usage is billed per token through the Claude Console or a cloud provider, the reported spend matches what you pay.

Key terms glossary

Token spend: The dollar cost associated with AI model consumption. On flat-rate plans it is an estimate priced at list rates, so it may differ from the amount actually paid.

Story points completed: The total of the story point estimate field across tickets completed in a period. It carries no sprint scoping of its own.

Agent session: The unit of active Claude Code usage, representing a continuous sequence of prompts and autonomous tool executions rather than a count of how many times a command was run.

Rework rate: The count of bugs created divided by pull requests merged. A broader quality measure than DORA's deployment rework rate, which counts only deployments intended to fix a bug divided by total deployments. Used as a guardrail against code volume rising faster than code quality.

PR cycle time: A workflow metric measuring the duration from a branch's first commit to when its pull request merges, used to detect pipeline bottlenecks when code volume rises faster than review capacity.

PR review rate: The share of merged pull requests that received a review from another person, used as a guardrail alongside pull requests merged.

Regression slope: The output of a linear regression reporting the change in a delivery outcome, such as story points completed, per unit change in token spend. This is the marginal ROI figure.

R-squared value: The coefficient of determination from a regression analysis, reporting what share of the variation in the outcome metric the spend variable actually explains. Higher values support more defensible correlation claims, with acceptable thresholds depending on your organization's context.

OpenTelemetry (OTel): An open-source observability framework for exporting telemetry from software systems. Claude Code uses OTel to export session-level data to a configured collector endpoint.