Claude Code Analytics API ROI Reporting: Correlating Token Spend to Delivery Outcomes

TL;DR: Pull request counts do not prove Claude Code delivers value. The defensible return on investment (ROI) methodology is a linear regression of story points completed against token spend, where the slope gives delivery yield per dollar spent. Workflow metrics like PR cycle time and quality metrics like rework rate serve as guardrails that explain why delivery trends move. They do not substitute for delivery outcome evidence. minware connects Claude Code Analytics API data to your version control and ticketing data through a normalized data layer, so you can run that regression without building a custom pipeline that consumes ongoing engineering maintenance.

When your board asks for the ROI of your Claude Code rollout, showing merged pull request counts will undermine your credibility. The real question is whether higher token spend is buying more delivery, and answering it requires a specific methodology: connecting Claude Code Analytics API spend data to completed story points through a linear regression that produces a defensible slope.

This article explains how to build that reporting pipeline, how to use workflow and quality metrics as guardrails, plus why building this internally costs more than engineering teams expect.

Seeing past pull request counts to real AI efficiency

Activity metrics measure whether the tool is being used. Throughput metrics like pull requests merged or lines of code measure code output volume, and neither proves delivery impact. Google's DORA research finds higher AI adoption associated with an increase in both throughput and instability. More shipped code arrives alongside more change failures, more rework, and longer resolution times.

The strongest evidence on this point comes from AI-assisted development itself. A study of Microsoft's early-2026 Claude Code and GitHub Copilot CLI rollout across tens of thousands of engineers found adopters merged roughly 24% more pull requests over four months than they otherwise would have. The authors used merged pull requests as their output proxy while stating plainly that a merged pull request is not the same as the value it delivers.

Separating code output from delivery outcomes

This is the throughput trap. When agents raise the volume of merged code, the review queue, the continuous integration (CI) pipeline, and the deploy gate become the binding constraints. DORA documents the mechanism directly: velocity gains for an individual author translate into significantly increased cognitive load for the reviewer.

Those constraints are what metrics like PR cycle time and change failure rate measure. More code in the repository lengthens pull request review times before it moves roadmap delivery. Measuring whether the investment is working requires connecting spend to value delivery metrics, specifically story points completed and roadmap delivery.

Sourcing token spend from Claude Code

Usage-based API spend creates a different reporting standard than flat-rate licensing. When a team moves from per-seat subscriptions to API-level consumption, finance teams expect a cost-per-outcome analysis. The Claude Code Analytics API exposes daily aggregated usage data and requires an Admin API key. Claude Enterprise organizations reporting claude.ai activity use the separate Enterprise Analytics API instead.

Two scope notes belong in any pipeline design. Anthropic tracks Claude Code usage on its first-party API only, so usage through Amazon Bedrock, Microsoft Foundry, Google Cloud, or Claude Platform on AWS is not included. The API also returns an estimated cost, so the figure is not what you were invoiced, and it flags subscription customers separately. Reported spend may differ from what you actually paid on flat-rate plans such as Claude Pro.

Token consumption needs a connection to downstream outputs, and those outputs need pairing with quality guardrails. Code produced by an agent that increases rework rate or lengthens PR cycle time is a cost shifted from initial development to review and remediation.

Measuring token spend against delivery outcomes

The primary ROI methodology is a linear regression of a delivery metric against token spend as a continuous variable. Story points completed and roadmap delivery are the two strongest outcome metrics for this analysis.

Token spend level is the durable variable. As adoption becomes near-universal, a genuine non-AI comparison group is disappearing. DORA reports that 90% of technology professionals now use AI at work, with over 80% believing it has increased their productivity. When you correlate token spend as a continuous variable, non-AI work sits at the zero-spend endpoint, so no separate binary split is required.

Tracing how token spend flows through delivery

Story points completed works as a dependent variable when estimates are consistent across teams, because it weights delivery by effort. Where teams size work differently, tickets completed or roadmap delivery serve the same purpose.

Token costs flow through the software development lifecycle (SDLC) in a specific sequence: agent session, commit or pull request, ticket completion, and epic or project advancement. Each step requires a data link to be measurable.

Claude Code session data connects to version control through commit metadata and AI authorship signals. Those commits connect to tickets through branch naming conventions or explicit ticket references. Our project completion reports show aggregate completion metrics at the epic level, which translates to roadmap language for board audiences.

Running the regression against story points completed

Each regression fits a single metric pair, so correlating token spend against three outcomes requires three separate regressions. The model's independent variable (X) is token spend aggregated by team and time period. The dependent variable (Y) is story points completed in the same window.

The regression slope gives delivery yield per dollar: how many story points the team completes per dollar of token spend. That marginal figure is the ROI answer, and it is the figure to present to a board or a chief financial officer (CFO).

The regression also reports an R-squared value, which indicates how much of the variation in story points completed the token spend explains. Where R-squared is low, spend explains little of the delivery variation, and that signal is worth surfacing directly. Our AI impact reports render this as a fitted line, with the slope and R-squared value shown on the chart itself.

Using AI versus non-AI cohorts as a supporting check

The continuous regression already includes non-AI work at the zero-spend endpoint, so it does not require a separate binary comparison group. Where a genuine non-AI cohort still exists, comparing AI-assisted to non-AI work from the same teams and time period serves as a supporting check rather than the primary methodology. That distinction matters because developers choose whether to use AI per task, and those choices are not random.

Naming the confounders cohort comparison cannot remove

Someone who uses AI on straightforward work and avoids it on the hardest problems produces data showing non-AI work is slower, when the cause is task selection. Person-level selection compounds the effect, because early adopters are often the strongest performers already.

This confounder is measurable, not theoretical. In METR's February 2026 study update, 30% to 50% of developers reported choosing not to submit tasks they did not want to do without AI, and METR concluded that selection effects left its own data only weak evidence for the size of the effect it measured.

Observational analysis cannot eliminate these confounders, though it can name them. Regression across teams and time periods adds variation the model needs. Neither approach produces a controlled experiment, and any analysis presented to a finance team must name the confounders explicitly to hold up to scrutiny.

Adding delivery context to raw token data

Raw token counts are meaningless without delivery context. A Claude Code session that produced a commit attached to a high-priority epic carries different weight than one that generated code unconnected to any ticket.

Connecting those contexts requires joining Claude Code Analytics API data with version control and project management data. It also requires resolving developer identities across all three systems, then aligning time windows so spend and delivery metrics cover the same periods.

Our blog on extracting reporting data from Claude Code covers the technical data sources available and how to think about their granularity.

Reading rework rate and cycle time as guardrails

Rework rate and PR cycle time are guardrails. Neither one is ROI evidence. A rising rework rate alongside increasing token spend means AI-assisted code is creating more bugs, which erodes the delivery gain the regression might otherwise show. PR cycle time that lengthens as token spend rises signals that more code is arriving for review faster than the team can process it, creating a bottleneck that absorbs the time AI saved upstream.

Defining rework rate and PR cycle time

Rework rate is calculated as bugs created divided by pull requests merged, a broader measure of quality problems than change failure rate (CFR). Both are worth tracking. Rework rate catches quality degradation across all merged code, while CFR signals the subset where failures reach production. Our analysis of AI-generated code quality patterns covers how AI changes the distribution of failure types and where to look first.

PR cycle time broken down by workflow status isolates the In Review stage, which is the earliest place increased AI-assisted code output shows up as a constraint. Tracking that trend alongside token spend shows whether review is absorbing the extra volume or scaling with it. Our efficiency reports surface that breakdown, and review latency works as a responsiveness indicator once you are tracking it.

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

Distinguishing supporting signals from delivery evidence

The five DORA metrics are deployment frequency, lead time for changes, change failure rate, failed deployment recovery time, and deployment rework rate. The latter four sit in the workflow or quality categories. Deployment frequency sits closer to throughput than to value delivery: a higher deployment count does not tell you whether what shipped was actually valuable. Together they explain why a delivery trend is moving, and none of them proves delivery value alone.

Analysis that leads with "our DORA metrics improved after the Claude Code rollout" does not answer the board's question about return on investment. Those metrics need to sit alongside story points completed and roadmap delivery to carry weight in an executive review.

Accounting for the validation load

One additional factor belongs in any financial ROI model: the time engineers spend reviewing and correcting AI-generated code. DORA finds that time saved during initial code generation is often re-allocated to verification and prompting overhead, where engineers spend significant time auditing output or fine-tuning instructions.

If AI accelerates code generation while review time has not scaled with it, the review stage absorbs the saved time downstream. A defensible model subtracts that validation load from the gross gain to produce a net figure.

Connecting version control, ticketing, and Claude Code data

Connecting these three data sources into a normalized reporting layer requires solving three problems: relationship linking between entities with no structured connection, identity matching across systems, and time alignment across different granularities.

Recovering relationships across your SDLC tools

Our patent-pending hypercube data model recovers relationships between entities with no structured link, connecting Claude Code sessions to tickets by modelling what commit and ticket each person was working on at a given time, even when developers do not tag tickets in sessions. That relationship recovery is the harder problem and the one most custom pipelines cannot solve.

Identity matching across systems is the easier half: developers appear under different usernames and email addresses in your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps, your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues, and Claude Code's own usage reporting, which identifies users by an authenticated email address or an API key name. Our entity resolution handles those mappings automatically and keeps them current as people change roles or email addresses.

Comparing Claude Code data sources

Four routes carry Claude Code data into a reporting pipeline, each with a different granularity. The Claude Code Analytics API reports token consumption at per-user, per-model, and per-day granularity, with historical data accessible through the API. OpenTelemetry exports report at per-prompt, per-session granularity with no historical backfill. The Claude Enterprise Analytics API covers broader engagement and adoption metrics from January 1, 2026 onward. A GitHub app integration attributes pull requests merged and lines of code back to sessions using a 21-day-before to 2-day-after matching window, excluding code rewritten by more than 20%. It is available on Claude for Teams and Claude for Enterprise plans, not Console or API customers.

Claude Code follows the OpenTelemetry GenAI semantic conventions for model call attributes. It emits its own session, prompt, and token metrics alongside them. Prompt content is redacted by default and only included when a customer sets OTEL_LOG_USER_PROMPTS in their own OpenTelemetry configuration, so whether that detail reaches our platform is the customer's choice.

Aligning time series for fair comparison

Aggregate token spend and story points completed over the same time windows, or the regression is not valid. A team that spent heavily on tokens in a sprint where no stories closed due to mid-sprint scope changes produces a distorted data point that biases the regression downward.

Our patent-pending hypercube data model's time model attributes engineering time at hour-level accuracy without manual time logging, which is what makes per-period aggregation consistent across connected sources.

Counting the hidden costs of custom ROI tooling

Building an internal telemetry pipeline feels like a contained project. Writing a script to pull Claude Code Analytics API data alongside a version control export, then joining it to your ticketing system in a spreadsheet, is achievable in a week of engineering time.

The problem starts when a second stakeholder asks for the data next to story point velocity, or when Anthropic updates its telemetry schema, or when a developer changes their email address and the identity join breaks silently. By the time the project is a dependency others rely on for board reporting, it is owned by whoever happened to build it, and that person spends recurring time on maintenance rather than shipping product.

Comparing build against buy

Factor	Internal build	Third-party platform (minware)
Initial setup cost	Engineering time to script data pulls and joins	Connect a data source in the trial, no engineering time
API maintenance	Updates required when vendor schemas change	Compatibility maintained as part of the service
Identity resolution	Custom matching logic required	Automatic identity resolution
Metric transparency	Depends on internal documentation	Formula logic exposed in the UI
Time alignment	Custom alignment logic required	Handled by the time model
Ongoing support	Continues to require engineering time	Customer success team support
Custom metric configuration	Logic lives in the codebase, so changing a definition requires an engineering task	Pre-built reports cover most use cases. Custom metric definitions carry a minQL learning curve, absorbed in practice by customer success.
Pricing	Ongoing engineering maintenance time	$25/contributor/month, Professional

Managing API volatility and schema drift

AI vendors update their APIs and telemetry formats on their own release schedule. The OpenTelemetry GenAI semantic conventions also continue to evolve as the tooling matures. Claude Code's telemetry surface shows the pattern: assistant response logging arrived as a versioned configuration change, and the Enterprise Analytics API returns no data before 1 January 2026.

Each schema change that touches an internal pipeline requires someone to identify the break, understand the new format, update the transformation logic, and validate that historical comparisons still hold. Those changes arrive without warning and often coincide with other engineering priorities. minware maintains compatibility with vendor APIs as they evolve and handles schema changes as part of its standard operation.

Answering the how-is-this-calculated question

The recurring cost teams underestimate most is human. When a stakeholder asks how exactly a number is calculated, someone must investigate. With an internal build, that often requires escalating to whoever built the pipeline.

minware implements every metric in minQL, a formula language built for engineering data, which exposes the full calculation logic in the user interface rather than hiding it behind proprietary query logic. Our customer success team can explain or adjust any formula without an engineering escalation.

"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. At the same time, those reports are highly customizable, and minQL makes it possible to build your own metrics and dashboards tailored to your team's workflow rather than being limited to predefined reports." - Verified user on G2

Metrics programs also fail for reasons that have nothing to do with calculation logic. Our guide on debugging a failed metrics initiative covers the dysfunction patterns that cost a program its stakeholder trust.

Auditing your current spend-to-delivery reporting

The checks below cover the three most common gaps: data quality in the underlying sources, historical coverage for the regression, plus identity matching and team output mapping across systems.

Running the self-audit checklist

Work through these ten checks to establish whether your current Claude Code ROI reporting would survive an executive review.

1. Token spend data comes from the Claude Code Analytics API or an OpenTelemetry export.

2. Token spend is connected to story points completed or roadmap delivery.

3. The analysis uses a linear regression with a named slope, expressed as story points per dollar.

4. The regression reports an R-squared value indicating how much of the delivery variation the spend explains.

5. Rework rate is tracked alongside the regression as a quality guardrail.

6. PR cycle time is tracked alongside the regression as a workflow guardrail.

7. Developer identity is resolved across version control, project management, and Claude Code's usage reporting.

8. Token spend and delivery outcomes are aggregated over the same time windows.

9. Any cohort comparison names the task-selection and person-selection confounders explicitly.

10. The validation cost, meaning time engineers spend reviewing and correcting AI output, is included in the net ROI calculation.

Fixing data gaps that weaken the signal

Messy source data is one of the most common objections to starting a metrics program. The honest response is that our best practice metrics surface exactly where the data breaks down, and those findings become an itemized action list rather than a reason to delay.

Our best practice metrics report tracks PRs Traceable to Ticket, Tickets Completed with Estimate, and Tickets Completed in Sprint, among others. Each gap produces a list of specific failing items rather than an aggregate rate, so a manager can work through them directly. Teams with more complete ticket linking also produce more accurate story point velocity data, which improves the regression's signal.

Estimating the timeframe for historical ingestion

First-connection backfill can take several hours depending on repository size and data volume. Professional backfills 1 year of history and Enterprise is unlimited.

OpenTelemetry data for Claude Code captures data from the point of configuration forward with no historical backfill at per-session granularity, though the Claude Code Analytics API supports historical access at per-user, per-day granularity. Connect telemetry as early as you can to widen the data window available for the regression. Note also that the Claude Code Analytics API carries a documented freshness window, where only data older than one hour appears in responses.

Connecting spend to team output

minware resolves developer identities across systems and maps activity to team membership automatically, so a report showing token spend by team also shows the story points that team completed in the same period. Our customer success team handles story point velocity definition customization for teams that do not run sprints, for example measuring points completed per calendar week instead.

Our drill-down chain runs from a high-level story point velocity trend to the individual tickets and agent sessions behind it, giving front-line managers a concrete to-do list rather than an average that requires a separate investigation.

Building a defensible spend-to-delivery report

Adoption is no longer the variable worth measuring. Confidence in AI output has not kept pace with how far it has spread: Stack Overflow's 2025 Developer Survey found 84% of developers using or planning to use AI tools, while 46% distrust the accuracy of what those tools produce versus 33% who trust it. That gap is the case for measurement over intuition. Regressing story points completed against token spend gives you a slope, an R-squared value, and a named set of confounders, which together answer the CFO's actual question about whether higher spend is buying more delivery.

Start a 14-day free trial at minware.com, no credit card required, and connect your first data source. Explore our pre-built AI impact reports with your own data before talking to anyone on our team.

FAQs

How do I extract token spend data from Claude Code?

The Claude Code Analytics API exposes daily aggregated usage and estimated cost through the /v1/organizations/usage_report/claude_code endpoint, at per-user, per-model, per-day granularity, with historical data accessible. Claude Code also supports OpenTelemetry exports at per-prompt, per-session granularity, though OpenTelemetry offers no historical backfill, so the two sources serve different purposes in a reporting pipeline. minware ingests both, joining them to your version control and ticketing data.

How much does minware cost?

minware's Professional plan is listed publicly at $25/contributor/month, with no seat minimum and a 100-contributor cap. Enterprise is $45/contributor/month with a 50-contributor minimum, billed annually, and removes the cap. Both prices are on our pricing page. The 14-day trial requires no credit card and no sales call.

Do you store our source code?

No. minware hashes source code during ingest and never stores it. That applies on a standard connection as well as through the on-premise agent. Separately, for teams that prefer not to grant direct API keys, our on-premise ingest agent runs inside your environment and connects to source systems using your own credentials.

Can I run the regression if my team does not estimate in story points?

Yes. You can run the regression using any value delivery metric your team tracks, including tickets completed or roadmap delivery. Story points completed is the strongest choice when estimates are consistent across teams because it weights delivery by effort, though tickets completed works when estimation practices vary. minware's customer success team can configure the metric definition to match your team's actual process in a single call.

Why can't we just join the data ourselves in a spreadsheet?

Our patent-pending hypercube data model recovers relationships between entities with no structured link, connecting Claude Code sessions to tickets even when a developer does not tag a ticket in the session. That relationship recovery is what a manual join cannot replicate. A manual join also breaks silently when developers change email addresses, usernames, or roles. minware resolves identities across systems and maintains those mappings continuously as source data changes.

Key terms glossary

Change failure rate (CFR): A quality metric measuring the share of deployments that result in a failure reaching production. Narrower than rework rate, and one of the five DORA metrics.

Hypercube data model: minware's patent-pending data architecture that links every SDLC artifact, including agent sessions, commits, pull requests, tickets, and epics, through a normalized layer that recovers relationships between entities with no structured connection.

Linear regression: The statistical method used to correlate token spend against story points completed, producing a slope, expressed as delivery yield per dollar, and an R-squared value indicating how much of the variation in delivery the spend explains.

PR cycle time: A workflow metric running from a branch's first commit to the point its pull request merges. Used here as a guardrail against review-stage bottlenecks rather than as delivery evidence.

Rework rate: A quality metric calculated as bugs created divided by pull requests merged, serving as a guardrail against code quality degradation and capturing a broader set of quality problems than change failure rate alone.

Story points completed: A value delivery metric that sums the story points field for all completed tickets in a given period, serving as the primary dependent variable in token spend regressions when estimates are consistent across teams.

Story point velocity: A value delivery metric expressing story points completed per sprint, or per fixed time period such as a week for teams that do not run sprints.

Token spend: The dollar cost of API consumption, distinct from token count, serving as the continuous independent variable for correlating AI investment to delivery outcomes. The Claude Code Analytics API returns this as an estimated cost, and on flat-rate plans such as Claude Pro reported spend may differ from the amount actually invoiced.