Claude Code Usage Metrics: The 12 Metrics Engineering Leaders Should Track
TL;DR: Proving Claude Code ROI requires moving past seat utilization and lines of code. Claude Code's raw token spend data does not connect to the outcome-level view a board needs. The 12 metrics that matter connect token spend to workflow signals (e.g., PR cycle time, work in progress), quality signals (e.g., rework rate), and value-delivery outcomes (e.g., story point velocity, roadmap delivery). Correlating token spend as a continuous variable against those value-delivery outcomes, with workflow and quality metrics explaining why the trend is moving, is the methodology that answers a CFO's question directly. minware's patent-pending hypercube data model connects Claude Code token data to those outcomes, with every calculation visible and traceable. The most valuable action you can take today is connecting OpenTelemetry as soon as possible, because it captures data going forward from the moment it is configured. The Enterprise API can backfill earlier usage at a coarser per-user, per-day grain.
High Claude Code seat adoption rates will not justify your AI budget in a CFO review. Adoption numbers measure whether the tool is open. They say nothing about whether delivery is improving. Engineering leaders who present token volume without connecting it to value-delivery outcomes like story point velocity and roadmap delivery, with workflow signals like PR cycle time and quality signals like rework rate explaining the trend, are answering the wrong question.
This guide outlines the 12 KPIs that connect token spend to value-delivery outcomes, workflow signals, and quality guardrails, along with the methodology for configuring telemetry so that you can start capturing usage as soon as possible.
Beyond adoption: measuring real AI coding ROI
Measuring real ROI starts with understanding why standard adoption tracking falls short and which data layers actually connect to delivery.
Beyond logins: tracking actual AI value
Seat logins measure whether your team opened the tool. They say nothing about whether it moved work forward. What determines the depth of your reporting is not the seat count but which data source you connect, and that varies by plan.
OpenTelemetry export is available on all Claude Code plans and reports at per-prompt, per-session granularity. Team plans add the ability to manage that configuration centrally rather than per developer. The usage API is limited to Enterprise plans and reports at a coarser per-user, per-model, per-day grain, with the advantage that it supports historical backfill. Teams on lower plans that skip OpenTelemetry are left with the native dashboard, which is where most reporting stalls.
That distinction matters more than plan tier alone suggests. Because OpenTelemetry is available everywhere, session-level measurement is open to any team willing to configure it, regardless of what they pay.
The three measurement levels that matter:
| Measurement level | Metrics included | Data source | Business value |
|---|---|---|---|
| Adoption | Active seats, agent sessions, logins | Native console / agent session logs | Low (measures usage, not value) |
| Operational | Token spend, pull requests merged, commits | Version control + AI tool telemetry | Medium (measures activity and cost) |
| Outcome | Roadmap delivery (value delivery), PR cycle time (workflow), rework rate (quality) | Version control + project management + AI tool telemetry | High (measures real business ROI) |
minware's AI impact reporting pulls from your version control system (GitHub, GitLab, Bitbucket, or Azure DevOps), your project management system (Jira, Linear, Azure Boards, or GitHub Issues), and AI tool telemetry to surface all three levels in one normalized view.
Beyond throughput: tracking delivery outcomes
"Percentage of AI-generated code" is one of the most misleading figures in AI adoption reporting. It incentivizes volume output rather than delivery quality and is straightforward to game: a developer who routes more code through Claude Code shows higher AI attribution numbers whether or not their work is shipping faster or with fewer defects.
The harder problem is the gap between how AI code looks at review and how it behaves in production. In New Relic's 2026 State of AI Coding report, 94% of technology leaders rated AI-generated code as higher quality than human-authored code at the point of review, while 74% said at least a quarter of it required significant post-deployment rework. That is a survey of 200 US technology decision-makers at manager level and above, run by Hanover Research, so it captures leader perception rather than measured code quality. Reporting a high AI-generated code percentage while PR cycle time is flat or rising is not a success story.
The alternative to a gameable output percentage is a metric set that measures how the delivery system behaves when you change it. The primary metric that answers what boards care about is roadmap delivery: is the team hitting its commitments? DORA's supporting workflow and quality metrics (deployment frequency, lead time for changes, change failure rate, mean time to restore, and rework rate) explain why the trend is moving in either direction. minware's software delivery friction guide covers the specific bottlenecks that inflate these metrics regardless of AI tool use.
Beyond token counts: building a defensible measurement foundation
The CFO's question is precise: is higher token spend buying more delivery, or a bigger bill? Correlating token spend as a continuous variable against value-delivery outcomes like story point velocity and roadmap delivery, with PR cycle time and rework rate explaining why the trend is moving, is the methodology that answers it directly.
The most valuable action you can take today is connecting OpenTelemetry as soon as possible. It captures data going forward from the moment it is configured, so every day it runs adds session-level detail you would not otherwise have. The Enterprise API can backfill earlier token data at a coarser per-user, per-day grain, so teams that connect later are not starting from nothing.
The continuous correlation methodology does not require a clean pre-rollout baseline: non-AI work has zero token spend and forms the natural low-spend endpoint of the regression. Trend confidence increases as data accumulates. Improvements that persist across multiple consecutive sprints carry more weight than single-sprint variations, which is why 3 to 6 months of data gives a more defensible read than a single reporting cycle.
5 essential categories for measuring AI impact
The metrics that reveal AI impact cluster into five categories, each covering a distinct dimension of engineering delivery.
Tracking AI cost with token spend
Token spend is the investment side of the ROI equation and the variable every other category gets compared against. It is the dollar cost of AI tool consumption reported through the vendor's API or OpenTelemetry, and the hypercube data model lets you break it down by any dimension: by person, by team, by project, by repository, by time period, or by roadmap initiative.
Note that reported token spend may be more or less than the amount actually paid for users on flat-rate plans like Claude Code Pro or Max, where billing does not scale directly with token volume. Say so whenever a spend figure carries weight in a decision.
Accelerating delivery pace with AI tools
PR cycle time and lead time for changes are the primary indicators of whether Claude Code is accelerating delivery or accelerating code generation alone. A developer who generates more code in less time but creates larger PRs that sit in review for three days has not improved cycle time.
Tracking these metrics requires linking Claude Code activity to version control data, and to deployment data for lead time. Deployment data can come from CI/CD pipeline runs, from Git tags for deployed versions, or from merges to the main branch where no CI/CD data is available. CI/CD is one route to it, not a requirement.
When minware detects a commit created during an agent session, it links that session to the pull request and then to the downstream deployment using the time-based association built into minware's patent-pending hypercube data model. That link makes PR cycle time attributable to AI-assisted work.
minware's cumulative flow diagram guide covers how to visualize whether AI-assisted work flows through the pipeline at a different rate than non-AI work, or accumulates at a specific stage like code review.
Preventing AI-driven code quality risks
Change failure rate and rework rate are the guardrail metrics that prevent teams from optimizing cycle time at the expense of quality. minware's analysis of change failure rate in AI-generated code explains why AI-assisted development requires broader quality measurement than the standard DORA definition alone.
minware calculates rework rate as the ratio of bugs created against pull requests merged. This is a broader measure of quality problems than DORA's own rework rate definition, which counts only deployments intended to fix a bug against total deployments, and it applies across both AI-assisted and non-AI work.
Pairing throughput metrics with rework rate as a guardrail also defends against metric gaming. A developer who inflates PR volume through Claude Code may surface quality issues through an elevated bug count, making potential manipulation more visible.
"Minware gives us clear visibility into code quality, defect rates, and development health with quality software development lifecycle (SDLC) metrics." - George V. on G2
Tracking roadmap and delivery reliability
Story point velocity and roadmap burnup trends show whether Claude Code investment is moving the commitments that leadership actually tracks. A team generating more code per sprint that misses its roadmap commitments at the same rate as before has demonstrated activity growth without delivery improvement.
minware's pre-built project completion tracking report shows burnup and burndown against roadmap epics and estimated completion vs. due dates, in the same data model that powers AI impact reporting. Separate cost reports let you view engineering effort associated with each initiative.
Tracking best practice adherence
Best practice metrics are the lever front-line managers can pull to improve every other category. minware links agent sessions to commits, pull requests, and tickets even when no explicit ticket ID exists, by modeling what each person was working on at any given time. Linking branches and commits to tickets makes those associations more accurate, because developers often have more than one ticket in progress, or write code before marking a ticket in progress at all.
That accuracy matters most for value-delivery metrics. PR cycle time and rework rate are calculated from version control data and do not depend on ticket linking. Story point velocity and roadmap delivery do, and without reliable links they can quietly miss AI-assisted work. minware's guide on how developers game sprint metrics explains why this linkage is also the primary structural defense against metric manipulation.
Connecting token spend to delivery outcomes
Tracking cost impact requires connecting token spend to the delivery metrics that answer a CFO's question. Logging usage volume alone leaves the CFO's question unanswered.
Linking token usage to delivery outcomes
As AI adoption widens across teams, the more durable variable is token spend level as a continuous variable correlated against value-delivery outcomes like story point velocity and roadmap delivery. Work without AI assistance has zero token spend, so a continuous correlation of spend level against those outcomes, with PR cycle time and rework rate explaining why the trend is moving, already includes no-spend work as one endpoint, without requiring a separate binary split.
Reporting lines of code or commit counts alongside token spend is the more common version of this mistake. Both measure code output volume, and both rise predictably once an agent is in the workflow. Neither says anything about whether the work shipped.
Linear regressions give a statistical basis for comparing AI investment to delivery impact. Each regression fits one metric pair, so correlating token spend against story point velocity, against PR cycle time, and against rework rate means running three regressions rather than one. Each returns a slope, which is the change in that outcome per additional dollar of spend, and an R-squared value showing how much of the outcome's variation the spend actually explains.
minware's identity resolution reconciles names, emails, and user IDs across all vendors, then matches Claude Code sessions to the commits and pull requests that followed them using time-based heuristics. This is what makes token-to-outcome correlation possible at scale without custom extract, transform, load (ETL) work.
Quantifying optimal token budgets
Budget owners want a cost efficiency figure they can track over time. That figure is the regression slope, for example story points completed per dollar of token spend, which estimates how much additional delivery each additional dollar is associated with. It is the output of an analysis rather than a metric you track in a report, and it is not the same as dividing total spend by total output, which credits every delivered item to AI whether or not AI touched it.
Read that way, the slope answers the budget question directly: as token spend per engineer increases, is more delivery coming proportionally, or are you hitting diminishing returns?
Tracking Claude token usage spans multiple layers, from software as a service (SaaS) seat visibility to proxy logging, gateway budget caps, and FinOps cost reporting. minware sits at the outcome layer, connecting spend data to the delivery metrics that justify the investment.
The 12 critical KPIs for AI coding success
Use this checklist to assess whether your reporting covers the dimensions needed for a defensible AI ROI report. Each item is a single metric, and the categories match the five above.
Cost
1. Token spend: The dollar cost of AI tool consumption, reported through the vendor API or OpenTelemetry. The investment side of every correlation in this list, and breakable down by any dimension the hypercube data model supports, including person, team, project, and time period.
Delivery pace
2. PR cycle time: Time from first commit on a branch to when the pull request merges, correlated against token spend level as a continuous variable. The primary indicator of whether higher AI spend is accelerating delivery or code generation alone.
3. Lead time for changes: Elapsed time from code committed to deployed in production, drawn from version control and deployment data. Tracks whether AI-assisted work is clearing the deployment pipeline faster.
4. PR review time: Time from PR opened to first review received. AI is known to elongate this part of PR cycle time, which makes it the leading indicator to watch when PR sizes grow. minware's technical debt tracking guide covers how to monitor code quality issues introduced by AI agents.
5. Work in progress (WIP): The total time duration of in-progress tickets assigned to a person within a day, divided by the day. A per-person, per-day time statistic scoped to tickets. Rising WIP per person signals that AI-generated code is producing more concurrent in-flight ticket work than the team can close. minware's distributed team wait time guide covers invisible WIP accumulation patterns.
6. Pull requests merged: The total count of merged pull requests. A throughput metric that reflects code output volume rather than delivered value, so track it alongside token spend to detect whether higher spend is buying delivery progress or generation volume, and never present it as the ROI evidence on its own.
Quality guardrails
7. Change failure rate: Change failures divided by total deployments. Rising failure rates alongside a rising deployment cadence signal that AI-generated code is not being reviewed with sufficient rigor.
8. Rework rate: Bugs created divided by pull requests merged, measured across AI-assisted and non-AI work. A widening rework rate is a clear signal that throughput gains are borrowing against future delivery capacity.
Roadmap and delivery reliability
9. Story point velocity: Story points completed per sprint, or per fixed time period per team for teams that do not run sprints. The clearest signal that AI-assisted work advanced committed scope rather than generating code that did not ship.
10. Roadmap delivery: Roadmap items, typically epics or initiatives, delivered by their due date divided by the number committed. The metric that connects AI investment to delivery predictability in board terms, because it answers whether Claude Code is helping teams hit commitments.
11. Deployment frequency: Deployments to production within a given time period, measured from CI/CD pipeline runs, Git tags, or merges to the main branch. Useful as a supporting signal, though it sits closer to throughput than the two value metrics above, so lead with those.
Best practice
12. Branch-to-ticket linking rate: Pull requests merged into a main branch that have a link to a valid ticket in the branch ref, PR title, or PR body, divided by total pull requests merged into a main branch. minware recovers session-to-ticket associations without it, but this linkage makes them materially more accurate, which is what value-delivery attribution depends on. minware's story point estimation guide covers the related discipline of keeping ticket estimates accurate enough to support throughput analysis.
How to detect and neutralize metric manipulation
AI coding tools introduce specific patterns of metric distortion that standard reporting does not catch without deliberate guardrails.
Preventing bias in productivity data
Lines of code and commit counts are particularly vulnerable to gaming when developers use Claude Code. A developer who generates large volumes of code and commits it in small batches will appear highly productive on both dimensions while potentially introducing review bottlenecks and defects that consume more time than was saved. Monitoring lead time and PR review time alongside those counts is what exposes the pattern, because inflated output shows up as review queue time before it shows up anywhere else.
Isolating raw throughput metrics from quality and cycle time data is what prevents this bias going undetected. A team whose commit count and rework rate both increase significantly may be optimizing for the wrong outcomes.
The pairing rule follows from that: every throughput metric needs a quality counterpart reported alongside it, and the right counterpart is usually the ratio metric that already uses it as a denominator. Pull requests merged pairs with rework rate, which is bugs created over pull requests merged. Deployment frequency pairs with change failure rate, which is change failures over deployments. Story point velocity pairs with rework rate.
Validating metrics through human review
Metrics sharpen manager judgment by flagging the specific pull requests, tickets, or agent sessions that warrant a closer look. When a metric flags an outlier, the front-line manager reviews it in context before acting. minware's drill-down chain supports this directly: a flagged outcome metric leads to its supporting metrics, then a list of the individual failing items, each linked back to the source system for full context. The manager always holds final judgment, which removes most of the incentive to game a number in the first place.
Controlling for bias in AI ROI analysis
Proving AI ROI is an observational analysis, not an experiment. The methods below control for the biases that make an observational result misleading.
Measuring ROI when everyone uses AI
Token spend as a continuous variable is the primary methodology, and it replaces binary adoption status. Non-AI work has zero token spend, forming the zero-spend endpoint of a spend-to-outcome regression. Engineers using Claude Code at high volume form the upper end. The correlation line across those data points answers whether more spend is buying more delivery, and it stays valid as adoption approaches universal.
Run the regression across teams and time periods, since that variation is what the model fits. minware connects agent traces to PRs and delivery signals, then correlates token spend against story point velocity, roadmap delivery, PR cycle time, and rework rate, giving the CFO a defensible per-dollar figure.
Correlation is not causation. Before drawing a conclusion, check what else changed over the period in question: hiring and attrition, a shift from feature work to bug fixing, or a material change in the codebase.
Comparing AI-assisted and non-AI work
Comparing AI-assisted and non-AI work from the same teams during the same period is a useful supporting check where a genuine non-AI cohort still exists. Its advantage over a spend correlation is precision: it surfaces differences caused by AI more directly than an aggregate spend figure can.
Its downside is why it is a supporting check rather than the primary method. Developers choose whether to use AI on a given task, and those choices are rarely random. A developer who reaches for AI on straightforward work and avoids it on the hardest problems will produce data showing non-AI work is slower, when the cause is task selection rather than AI impact. Person-level selection compounds it, since the developers who opt in first are often already the strongest performers.
Neither bias is fully removable in an observational setting. What you can do is check whether cohorts had comparable performance before rollout, and treat any cohort difference as a prompt for investigation rather than a finding.
Adapting analysis when data is missing
The most common gap is telemetry that was configured after usage began. OpenTelemetry reports going forward only, so connect it as early as you can and use the Enterprise API to backfill the earlier period at a coarser per-user, per-day grain. The two sources answer different questions, so teams with access to both generally run both.
For teams where ticket linkage is incomplete, minware's best practice metrics surface the specific commits and PRs missing ticket IDs, giving managers an itemized list of exactly where the data gap is coming from rather than a generic data quality warning.
Selecting metrics executives trust
Executives trust metrics they can trace back to a visible calculation and a clear business outcome, which sets a specific bar for how AI impact data needs to be structured.
Mapping AI usage to business outcomes
The connection from a Claude Code session to a board-level delivery outcome runs through several data layers: agent session to commit, commit to pull request, pull request to ticket, ticket to epic, epic to roadmap initiative. Each link requires explicit data or reliable inference. minware's patent-pending hypercube data model maintains all of these links simultaneously, so filtering by a roadmap initiative automatically surfaces the token spend, PR cycle time, and rework rate for all the work underneath it.
This is the data architecture that makes it possible to answer the CFO's question without rebuilding a spreadsheet for every reporting cycle. minware's AI impact reporting surfaces this chain in a pre-built view that connects token spend to workflow, quality, and delivery metrics.
Designing defensible AI impact reports
Every metric in minware's reporting layer is implemented in minQL, minware's formula language, which is visible in the UI. A VP preparing for a board presentation can click through any chart and inspect the exact calculation logic behind it. Customizing that logic to reflect how their org defines cycle time or story point estimation typically goes through a customer success call rather than direct minQL editing.
"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
Customizations that would require a vendor roadmap ticket in other platforms are handled in customer success calls at minware. That turnaround covers edge cases like excluding certain ticket statuses from cycle time for specific teams, or defining work categories through a cascading rule when ticket types are inconsistent across projects.
The hidden ongoing cost: Every time a stakeholder asks "how exactly is this calculated," someone who owns the pipeline has to answer. With a vendor, that is a support conversation. With an internal build, it is indefinitely the responsibility of whoever wrote the SQL.
Validating Claude Code ROI with data
The build-vs-buy analysis for this reporting layer has a concrete cost profile:
| Feature / cost | Internal build | minware platform |
|---|---|---|
| Initial setup | Weeks of engineering time | Self-serve trial available |
| Maintenance | Ongoing (API changes, schema updates) | Included in subscription |
| Data normalization | Custom integration scripts | Patent-pending hypercube model |
| Governance layer | Custom development required | Transparent minQL formulas, customizable via customer success |
Turning an AI budget line into a board-ready report
Connecting Claude Code token spend to PR cycle time, rework rate, and roadmap delivery is the step that turns an AI budget conversation into a defensible board-level report. The 12 metrics in this guide cover the full chain from cost to delivery pace to roadmap reliability, each with a visible calculation and a clear owner. Engineering leaders who connect telemetry now will have the session-level data needed to run that correlation when the CFO asks.
Professional pricing is $25 per contributor per month, no seat minimum, monthly billing, and a 14-day self-serve trial with no credit card required. Jellyfish's pricing for direct contracts remains sales-gated, which delays evaluation. Start a 14-day free trial at minware.com and connect your first data source. Explore the pre-built AI impact reports with your own data before talking to anyone on our team.
FAQs
How long does it take to measure Claude Code ROI?
Connect OpenTelemetry as soon as you can, since it captures data going forward from the moment it is configured. The Enterprise API can backfill the earlier period at a per-user, per-day grain, so a late start is not a lost cause. Once telemetry is running, the continuous spend-to-outcome correlation can begin immediately. Trend confidence grows as data accumulates: improvements that hold across multiple consecutive sprints are a stronger signal than single-sprint results, so 3 to 6 months of data produces a more defensible read for a board review.
What if our team uses multiple AI coding tools alongside Claude Code?
The spend-to-outcome correlation methodology applies across tools. minware ingests token spend from each AI tool separately, via the vendor's API or OpenTelemetry depending on what that tool exposes, then connects each tool's session data to the commits, pull requests, and tickets that followed. Identity resolution runs automatically across your version control system, your project management system, and every connected AI tool, so the multi-tool data lands in one reporting layer with no custom ETL. That lets you compare delivery outcomes across tool cohorts within the same team and period.
What is the minimum team size for minware's Professional plan?
Professional has no minimum contributor count, at $25 per contributor per month billed monthly. Enterprise requires a 50-contributor minimum, at $45 per contributor per month billed annually. Contact sales for Enterprise details.
Why does branch-to-ticket linking matter for AI tracking?
minware links a Claude Code session to the ticket and roadmap item it belongs to even without an explicit ticket ID, by modeling what each person was working on over time. An explicit ticket ID in the commit, branch, or pull request makes that association materially more accurate, because developers often have several tickets in progress at once or write code before moving a ticket to in-progress. PR cycle time and rework rate are unaffected either way, since both are calculated from version control data. Story point velocity and roadmap delivery are where weak linking shows up, and where AI-assisted work can be quietly undercounted.
Key terms glossary
PR cycle time: The time from the first commit on a branch to when the pull request merges, drawn from version control data. Ticket cycle time is a separate metric, running from when a ticket moves to in-progress to when it is completed. Both appear separately in minware reports. This article tracks PR cycle time, which is why review duration, such as a PR sitting in code review for three days, directly affects the metric.
Rework rate: minware's rework rate counts all bugs created against pull requests merged, a broader measure of quality problems than DORA's own rework rate definition, which counts only deployments intended to fix a bug against total deployments. Used as a quality guardrail alongside throughput metrics to detect whether delivery pace is coming at the expense of code stability.
Token spend: The dollar cost of AI tool consumption, reported by the vendor's API or OpenTelemetry export. Used as a continuous variable for correlation against delivery outcomes, and breakable down by any dimension the hypercube data model supports, such as person, team, project, or time period. Note that reported token spend may be more or less than the actual amount paid for users on flat-rate plans like Claude Code Pro or Max, where billing does not scale directly with token volume.
Hypercube data model: minware's patent-pending multi-dimensional data structure that links version control, project management, CI/CD, and AI tool data without rigid predefined schemas, enabling any metric to be broken down by any dimension. Its pending patent covers recovering relationships between entities that carry no explicit link, such as connecting an agent session to a ticket when the session produced no commits.
Work in progress (WIP): The total time duration of in-progress tickets assigned to a person within a day, divided by the day. A per-person, per-day time statistic scoped to tickets in your project management system, used to identify whether concurrent in-flight work is expanding faster than the team can close it. PR queue dynamics are a related but separate observation tracked through PR review time.
Lead time for changes: The total elapsed time from code committed to version control to deployed in production, one of the five DORA metrics and a primary indicator of delivery pace.
Deployment frequency: The number of deployments to production within a given time period, measured from CI/CD pipeline runs, from Git tags for deployed versions, or from merges to the main branch where no CI/CD data is available. One of the five DORA metrics. Paired with change failure rate to detect whether a higher deployment cadence is introducing quality tradeoffs.
minQL: minware's formula language for engineering data, used to implement every metric in the platform. The underlying formulas are visible in the UI, so any metric can be inspected and traced back to its exact calculation. Customizations are typically handled through customer success rather than direct editing by customers.
Roadmap delivery: The number of roadmap items, typically initiatives or epics in your project management system, delivered by their due date divided by the number committed. Tracked at the epic and initiative level. The value-delivery metric that connects AI investment to delivery predictability in board and CFO reporting.
Story point velocity: The number of story points completed per sprint, or per fixed time period per team for teams that do not run sprints. Teams that do not estimate in story points use the equivalent unit they do track, such as tickets completed. Used as the primary value-delivery outcome correlated against token spend level when measuring AI ROI, because it confirms that AI-assisted work advanced committed scope rather than generating code that did not ship.