Claude Code Usage Tracking Limitations: What It Can't Tell You

TL;DR: Claude Code's native tracking reports token spend, session activity, suggestion accept rate, and code contribution in the form of pull requests and lines of code. Anthropic's own guidance points teams at those contribution metrics to demonstrate return on investment (ROI), but pull requests merged measures code output volume and says nothing about delivered value. A defensible answer for an executive review comes from a linear regression of token spend against story points completed or roadmap delivery, with rework rate and cycle time alongside as quality and workflow guardrails. minware connects Claude Code telemetry to version control and project management data so that regression runs from pre-built AI impact reports.

Native Claude Code tracking answers how much an organization is spending and how much code the tool produced. Neither figure tells a board whether that spend is moving roadmap delivery, which is the question that arrives in budget and renewal conversations.

Claude Code's analytics dashboard reports lines of code accepted, suggestion accept rate, daily active users, and sessions. On Claude for Teams and Claude for Enterprise plans, connecting the GitHub app also gets merged pull requests attributed back to Claude Code sessions. Claude Console (API) customers do not have this option: contribution metrics with GitHub integration are not available for API usage. Those numbers are genuinely useful for controlling spend and tracking rollout. This piece covers where they stop, why the gap matters in an executive review, and what a defensible measurement approach requires instead.

What Claude Code usage tracking actually measures

Native tracking surfaces four categories of data: token spend, session activity, suggestion accept rate, and code contribution. Each measures the tool or its output, so each carries a specific blind spot that matters when the goal is an ROI report a chief financial officer will accept.

Token spend and session activity

Token spend is a cost measure, and its size tells you little about the value of the work behind it. High spend can come from complex, valuable work. It can equally come from inefficient prompting, oversized context, or a long chain of reasoning on a problem that never needed it. Session counts sit beside it as an activity measure, recording that the tool was used without carrying any claim about what the work produced.

Claude decides per request whether to reason before answering, and how deeply. Those thinking tokens are billed as output tokens, so two sessions on the same ticket can carry very different costs depending on task complexity and the effort level configured.

Token spend also means dollar cost rather than a raw count of tokens. Anthropic reports its dashboard figures as estimates for analytics purposes and directs teams to the billing page for actual costs, so comparing spend across teams on different plans requires normalizing for plan type before any regression is meaningful.

Suggestion accept rate and its scope

Claude Code reports a suggestion accept rate, defined as the percentage of times users accept its code editing tool usage across the Edit, Write, and NotebookEdit tools. It measures whether a proposed edit was taken, and it stops there.

Acceptance says nothing about the correctness of the code, its architectural fit, or whether it was necessary at all. A developer can accept every edit Claude proposes and still introduce a regression that surfaces as bugs two sprints later.

Rework rate is the measure that catches what acceptance misses. minware calculates it as bugs created over pull requests merged, which requires version control and project management data that no acceptance figure contains.

Code contribution metrics and the throughput trap

The contribution metrics are the ones most likely to end up in a board deck. Anthropic's documentation suggests using them to demonstrate ROI by comparing pull requests and lines of code shipped with and without Claude Code, and recommends pairing them with DORA metrics, sprint velocity, or other engineering KPIs, since output counts alone don't answer the impact question.

Pull requests merged, commits, and lines of code are throughput measures of code output volume. A team can raise all three while roadmap commitments continue to slip, because none of them records whether the work shipped anything the business was waiting for. That is the throughput trap: optimizing the output you can see while the outcomes the business cares about stay unmeasured.

Attribution has hard edges as well. Claude Code matches sessions to merged pull requests within a window running from 21 days before to two days after the merge, and it excludes code a developer substantially rewrote, defined as more than a 20% difference.

What native tracking cannot show after the session ends

Beyond what native tracking measures, there are signals it cannot produce at all. Three gaps surface consistently when engineering leaders try to build a fuller picture of what AI is doing to their delivery.

Code quality beyond the commit

Native tracking records that code was written and a commit was made. It carries nothing about what that code does to system stability over the following month.

Code churn, the share of code rewritten or deleted shortly after it was written, is one of the quality measures that catches the pattern, and it is calculated from version control history rather than session data. Tracking code health in legacy codebases means connecting that history to ticket-level outcomes, a linkage that no usage export contains.

Quality problems from AI-assisted work also arrive faster than most teams expect. Our analysis of change failure rate in AI-generated code shows them appearing quickly in production metrics when guardrails do not scale alongside the extra output.

The J-curve and delayed instability

Organizations adopting a new capability often follow a J-curve pattern: early performance gains, then a dip as complexity increases, then recovery at a higher level as the practice matures.

DORA's 2025 research found that higher AI adoption is associated with an increase in both software delivery throughput and software delivery instability. More code moves, and more of it breaks.

Spotting that shape requires tracking output alongside quality over the same periods. Native usage data holds only the output half, so a team watching it alone sees the climb without the dip that follows.

Review load across the team

Heavy agent use changes what reviewers face. DORA's 2025 research found that velocity gains for an individual author frequently translate into significantly increased cognitive load for the reviewer, with time saved writing code often reallocated to auditing and verification.

That load shows up in PR review time, the stretch between a pull request opening and its first substantive review from another person. Tracking it against token spend shows whether the review stage is absorbing the extra volume.

The cumulative effect lands in PR cycle time trends. As our cumulative flow analysis puts it, when an AI-assisted stage speeds up but the next stage widens, AI has saved local time and moved the bottleneck.

Where the gap blocks delivery reporting

The measurement failures below are the ones that stop a leader from connecting Claude Code data to the numbers a board review actually turns on.

Sprint and story point data

Story points completed comes from ticket completion data in your project management system. Claude Code's usage exports carry no structured awareness of that system. Connecting one over Model Context Protocol gives the agent access during a session without recording that link in any exported telemetry.

A developer spending a day in agent sessions may be closing one complex ticket, or may be generating code attached to no ticket at all. Both look the same in usage data.

The gap matters for reporting. Calculating sprint velocity needs ticket completion data, estimate data, and sprint assignment data, none of which usage exports touch. Without that linkage, a rising spend line cannot show whether the team is completing more of what it committed to.

Deployment data and DORA metrics

Deployment frequency and lead time for changes, two of the five DORA metrics, come from version control and deployment data. You can source deployment timing from CI/CD pipeline runs, from Git tags for deployed versions, or from merges to the main branch, and none of those routes runs through Claude Code.

Claude Code now attributes merged pull requests to sessions for teams running the GitHub app, so the chain reaches the pull request. It stops there. Nothing connects that pull request to the ticket, the epic, or the roadmap item it was meant to deliver.

That leaves the most useful question unanswered. Rising agent usage tells you nothing on its own about whether deployments became more frequent or more stable.

Cost attribution and capitalization

Usage data reports cost per user and per model. It does not attribute that cost to a revenue-generating project or a cost center.

Cost capitalization, the accounting practice of attributing engineering labor costs to specific projects or roadmap items for financial reporting, requires mapping contributor effort to epics and initiatives. Capitalized internal-use software is typically amortized on a three to five year straight-line basis in practice, though a longer life is permitted where justified.

Finance teams deciding whether AI spend belongs in operating or capital expenditure need that mapping. Building it means joining token cost to salary data and work effort in one data model, which usage exports cannot do on their own.

Why activity and output metrics fail as ROI evidence

Activity and throughput metrics carry no outcome context. They establish that the tool is being used and that code volume rose. Whether delivery improved sits outside what either measures. Our software development metrics guidance argues against code volume as a measure of effectiveness for exactly this reason.

When an engineering leader brings active user counts or pull request totals to a budget renewal, those figures cannot answer the question finance is asking: is higher spend buying more delivery, or just a bigger bill? The board wants to know whether the investment changed the delivery curve. Answering that takes delivery data, which output counts do not contain.

Requirements for defensible AI ROI reporting

Closing the gap takes a specific methodology rather than more data. The sections below cover the regression, the data prerequisites, the linking mechanism, and the guardrails that make an ROI figure defensible in an executive review.

Token spend correlated with delivery outcomes

The primary methodology is a linear regression of token spend as a continuous variable against a value delivery metric, usually story points completed or roadmap delivery. Linear regression, a statistical method that fits a line through the relationship between two variables, returns a slope giving the change in the outcome per dollar of spend, along with an R-squared value showing how much of the variation in delivery that spend explains.

Non-AI work sits at the zero-spend endpoint of that model, so no separate binary cohort split is needed. Name the confounders when you present the slope. Developers who reach for AI on straightforward work and avoid it on the hardest problems produce data suggesting non-AI work is slower, when the cause is task selection.

Checklist: what you need before running an AI ROI regression

Before correlating token spend with delivery outcomes, confirm each of the following:

• Version control connected: Repositories contributing to the roadmap are ingested with historical data available.
• Project management connected: Your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues, is linked with ticket and estimate data accessible.
• Claude Code telemetry configured: OpenTelemetry export is deployed centrally through the managed settings file rather than per developer. The Claude Code Analytics API covers per-user, per-model, per-day granularity with history available, while OpenTelemetry adds per-prompt and per-session detail from the point it is switched on.
• Identity resolution confirmed: Developer identities across version control, project management, and Claude Code are reconciled to one person.
• Agent sessions linked to tickets: Time-based or explicit linking connects sessions to the commits and pull requests they produced, and to the tickets representing the value of that work.
• Story points completed available: The dependent variable in the regression is ready at team and time-period level.
• Rework rate tracked: The quality guardrail on pull requests merged is running alongside the delivery metric.
• PR review time tracked: Rising PR review time while output rises means the bottleneck has moved to the review stage, not that delivery has improved. It is the second guardrail.
• Token spend normalized for plan type: Flat-rate plan users are flagged so reported spend reflects marginal cost.

Session and ticket linking

Claude Code's usage data does not link agent sessions to tickets. A developer may run 20 sessions in a day across three different tickets, with no structured relationship connecting any session to any ticket.

Recovering those relationships takes time-based linking: modeling what commit and ticket each person was working on at any given time, then associating sessions with the most proximate ticket and pull request in the data. minware's patent-pending hypercube data model does this automatically, connecting sessions to commits and pull requests, then through to tickets and epics, even where no explicit ticket ID appears.

Explicit linking still helps. Developers often hold several tickets in progress or write code before moving one to in progress, and a branch-to-ticket convention makes those associations more accurate.

Guardrail metrics for quality and workflow

Every throughput or value metric presented as ROI evidence needs a quality counterpart alongside it. Pull requests merged pairs with rework rate, calculated as bugs created over pull requests merged, and with PR review rate. Deployment frequency pairs with change failure rate.

When spend rises and story points completed rises with it, rework rate is what confirms the additional delivery is stable rather than storing up incidents for later sprints. That's the quality guardrail. PR cycle time is the workflow guardrail, doing a different job than rework rate. When delivery outcomes do not move at all, rising PR cycle time is one of the first places to look, since it shows work piling up before it reaches done rather than a quality problem in what shipped.

Closing the visibility gaps

Connecting native Claude Code data to delivery outcomes means closing the gaps in order: the metric set, the roadmap linkage, the definitions behind both, and the decision about who maintains it all. Together they lift the reporting layer from session-level activity to roadmap-level accountability.

Connecting usage data to DORA metrics

The five DORA metrics, deployment frequency, change lead time, change fail rate, failed deployment recovery time, and deployment rework rate. All five draw on version control and CI/CD data that Claude Code cannot reach.

Connecting them means running one normalized pipeline that ingests version control, CI/CD, and AI tool data together. That is what makes it possible to see whether AI usage is tracking with DORA trends or pulling away from them.

Rework rate carries the most weight of the five in this context, because it captures quality problems that change failure rate alone misses. A high change failure rate still signals a more severe problem that needs immediate attention.

Mapping sessions to roadmap milestones

Session-level activity reaches roadmap epics only when sessions are linked through commits and tickets to the epics those tickets sit under.

minware's project completion tracking report shows burnup and burndown against roadmap epics, plus estimated completion against due dates and total engineering cost against budget, in the same data model that powers its AI impact reports. Those reports include regression charts that plot an outcome metric against token spend with the fitted slope and R-squared value shown.

This is the view business stakeholders can evaluate. It answers whether AI spend is moving the roadmap at the pace the business committed to.

Customizing metric definitions without code

Definitions differ between organizations. What counts as done for sprint reporting, which statuses belong in a ticket cycle time calculation, and how work categories are derived all vary by team. A fixed metric set forces those teams to report on someone else's definitions.

minware exposes those definitions as editable properties in the report configuration, so a team can exclude a user acceptance testing status from workflow metrics or set its own done criteria without writing code.

"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

Weighing build against buy

A custom pipeline pulling the Analytics API into a warehouse is a reasonable option for a small team with a homogeneous stack and no cross-team reporting requirement. The comparison shifts on maintenance. Schemas change, identities drift, and someone owns the answer to "how exactly is this calculated" every time a stakeholder asks.

The honest tradeoff on the vendor side is configuration effort, but only when it's needed. Most teams get value from the out-of-the-box reports without any setup. Configuration effort only enters the picture once a team wants a report or metric definition customized to an organization-specific question, done by the team or by a customer success agent.

See our full build vs. buy comparison for the complete cost breakdown.

Moving from activity counts to delivery evidence

Spend figures and code contribution counts are worth having. They belong in a rollout review, where the question is whether the tool has landed with the team. The question boards ask is whether rising spend is producing more completed roadmap work. Closing that gap takes a linear regression of token spend against story points completed or roadmap delivery, run across teams and time periods, with rework rate and PR review rate alongside as guardrails.

minware connects version control, project management, and Claude Code telemetry into one normalized data layer, so engineering leaders can run that regression from pre-built AI impact reports instead of maintaining a pipeline of their own.

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

FAQs

How do you check Claude Code usage at the organizational level?

Organization-level usage is available in the Claude Code analytics dashboard for Team and Enterprise plans, which covers usage, adoption, and contribution metrics. For programmatic access, the Claude Code Analytics API returns per-user, per-model, per-day records with token counts and estimated cost, and Anthropic publishes no deletion period for that data. OpenTelemetry export adds per-prompt and per-session detail from the point it is configured, with no history before that.

Can you attribute Claude Code token costs to specific projects?

Not from usage data alone, because it carries no connection to your project management system. Attribution requires linking sessions to version control commits and to tickets, then aggregating those linked costs against roadmap epics and initiatives. minware handles that linking through its hypercube data model, which recovers the session-to-ticket relationship even where no explicit ticket ID appears in the session data.

What is the difference between the Claude Code Analytics API and OpenTelemetry exports?

The Analytics API reports at per-user, per-model, per-day granularity, and historical data stays queryable, so a team can assemble past periods after the fact. OpenTelemetry export reports at per-prompt and per-session granularity, which is far more detail, and it only captures data from the point it is switched on. Teams that configure it after rollout cannot recover earlier sessions at that granularity.

How does thinking effort affect Claude Code token spend?

Claude decides per request whether to reason before answering. The effort level sets how willing it is to think and how deeply. At high effort and above, Claude thinks on almost every request, and those thinking tokens are billed as output tokens. Anthropic publishes no fixed multiplier for the increase, so per-session cost varies with task complexity. That variance is worth tracking against story points completed to confirm the additional reasoning is buying delivery rather than inflating spend.

Key terms glossary

Agent sessions: The unit of active Claude Code usage, covering a continuous sequence of prompts and autonomous actions run by the agent. Agent session count is an activity metric showing whether the tool is being used.

Token spend: The dollar cost of token consumption, which can differ from the amount actually paid on flat-rate plans. Token spend is the continuous variable in an AI ROI regression, distinct from a raw count of tokens.

Pull requests merged: A throughput metric counting merged pull requests. It measures code output volume and carries no delivery claim on its own.

Story points completed: A value delivery metric totaling the story points on completed tickets. It is the most common dependent variable in an AI ROI regression because it reflects completed, estimated work.

Roadmap delivery: A value delivery metric tracking progress against committed roadmap epics and initiatives, reported as burnup or burndown against due dates.

Rework rate: A quality metric that minware calculates as bugs created over pull requests merged. DORA's own rework rate is narrower, counting deployments made to fix a bug or incident against total deployments.

PR review rate: A quality metric tracking the proportion of pull requests that received a human review before merging, used alongside pull requests merged to confirm reviews keep pace as output rises.

Linear regression: A statistical method correlating a continuous independent variable, such as token spend, against a dependent outcome, such as story points completed. The slope gives the change in the outcome per dollar of spend, and the R-squared value shows how much of that outcome's variation the spend explains.

Hypercube data model: minware's patent-pending data architecture, which normalizes and links development artifacts across version control, project management, and AI tools, recovering relationships such as agent session to ticket where no explicit key connects them.

Cost capitalization: The accounting practice of attributing engineering labor and tooling costs to specific projects or roadmap items for financial reporting, typically amortized on a three to five year straight-line basis in practice.