Claude Code Usage Audit: How to Conduct a Token Spend Review

TL;DR: A defensible Claude Code audit correlates actual token spend against value delivery metrics like story points completed and roadmap delivery. The correlation represents the return on investment (ROI) readout. Workflow and quality metrics like PR cycle time and rework rate explain why a trend is moving but are not the ROI evidence itself. AI-assisted vs. non-AI comparison serves as a supporting check where a genuine non-AI cohort still exists. minware's pre-built AI impact reports automate the correlation, connecting Claude Code spend directly to delivery outcomes across version control, project management, and CI/CD.

Token spend on Claude Code often climbs quarter over quarter while story points completed stay flat. That pattern starts a difficult board conversation, and it's one most engineering leaders can't defend because they're measuring the wrong variables.

This guide provides the audit methodology to answer that question with data that holds up to procurement and finance scrutiny, moving past seat activations and PR merge counts to correlate actual spend against delivery outcomes.

Align token spend with delivery performance

Token spend measures dollar cost. Whether that spend paid off depends entirely on what it bought in delivery outcomes. The only meaningful audit question is whether higher spend correlates with more value delivered. Answering it requires pairing spend data with value delivery metrics from your version control and project management systems, not just from the AI tool's own dashboard.

Our guide on reporting data out of Claude Code covers the raw data sources in detail. The challenge here is linking that data to delivery outcomes in a way that a chief financial officer (CFO) can interrogate and defend.

Audit timeline and contract renewals

Run the audit before your renewal date, giving yourself at least a 90-day data window for the analysis. A 90-day window at weekly grain gives 13 data points per team, which is enough to give a regression a reliable slope.

If you're preparing for a 2026 contract renewal and haven't started collecting OpenTelemetry data from Claude Code, connect telemetry now. The Claude Enterprise Analytics API backfills data from January 1, 2026 onward. OpenTelemetry captures per-session detail from the point of configuration forward with no backfill available. The historical data from the Enterprise API can still support trend line analysis for a renewal conversation. The first-connection backfill for historical data can take several hours depending on repository and ticket volume. Build that into your kickoff timeline rather than treating it as a day-one blocker.

Evidence standards for AI audits

The evidence hierarchy for a budget-justification audit runs in this order:

1. Primary evidence: A linear regression of story points completed or roadmap delivery against token spend, with the slope representing the ROI readout.

2. Supporting signals: PR cycle time and rework rate alongside the delivery regression, showing whether the spend is creating or clearing pipeline bottlenecks.

3. Directional check: AI-assisted work compared to non-AI work from the same teams during the same period, where a genuine non-AI cohort still exists. Activity metrics like agent session counts can show adoption context, but they don't answer whether the investment is buying delivery. Our post on engineering metrics for board meetings covers how to frame this hierarchy for an executive audience.

Define your audit scope and objectives

Before pulling any data, define what you're measuring and why. An audit with no declared scope produces findings that are easy to dismiss.

Audit parameters and periods

Define the following before any data extraction:

• Time window: At least 90 days of overlapping spend and delivery data is recommended.

• Contributor scope: Contributors with at least one agent session during the period.

• Data point diversity: Enough variation in token spend across time periods, individuals, or teams so the regression has something to work with. Multiple teams are one way to get this, not a requirement, a single team with enough weekly data points works too.

• Delivery metric: Story points completed is the preferred primary metric. Organizations that don't estimate in story points can consider tickets completed or roadmap delivery as the dependent variable.

Structured reporting for audit findings

Finance and procurement reviewers don't operate in story points. Translate the findings before presenting them. Dividing 1 by the slope gives a cost-per-deliverable figure. Frame this alongside the fully loaded engineer cost per hour so the ROI case becomes concrete and independently verifiable.

Map Claude Code spend to engineering workflows

The biggest gap in most internal audits is data coverage. Engineering leaders pull whatever their AI tool dashboard surfaces and call it a spend review. A genuine audit requires data from two Claude Code sources and your delivery toolchain, linked together.

Claude Code audit data sources

Claude Code exposes usage data through two separate routes, each with different granularity and backfill capabilities.

The Claude Enterprise Analytics API provides endpoints covering organization-wide engagement, adoption, and cost data, available for dates on or after January 1, 2026. This is the right source for trend analysis and team-level spend comparison over your audit window.

OpenTelemetry exports from Claude Code provide per-prompt, per-session granularity, with detailed telemetry data recorded on every span. This source captures data from the point of configuration forward. Team and enterprise accounts can deploy this configuration centrally.

You can control whether prompt text appears in the telemetry through your own OpenTelemetry setup before data reaches any analytics layer. Redacting prompt content can still support delivery correlation because token cost and session metadata are captured regardless.

Individual vs. Enterprise monitoring

The monitoring granularity available depends on your Claude deployment type:

Monitoring level	Data source	Granularity	Historical backfill
Enterprise API	Analytics API endpoints	Per-user, per-model, per-day	From January 1, 2026
OpenTelemetry	Centralized export	Per-prompt, per-session	Not supported
Claude Code Analytics API	Admin API endpoint	Per-user, per-model, per-day	Full history, no Enterprise plan required

A third path is worth knowing about: the Claude Code Analytics API reports the same category of daily productivity metrics, cost by model, sessions, commits, and pull requests, through the Admin API at no additional cost, without requiring a Claude Enterprise plan. For an audit scoped to Claude Code specifically rather than organization-wide Claude usage, this can be the simpler starting point.

For a renewal-ready audit, you can use either analytics API for historical trend analysis and OpenTelemetry for session-level waste pattern analysis. The sources are complementary.

Unified views for token spend analysis

The Enterprise API and OpenTelemetry data require linkage to your project management system, such as Jira, Linear, Azure Boards, or GitHub Issues, and your version control system, such as GitHub, GitLab, Bitbucket, or Azure DevOps. That linkage typically requires a normalized data layer that maps agent sessions to the commits and tickets they belong to.

This is where most custom internal pipelines fail. The linkage problem isn't just joining tables on a developer ID. Claude Code sessions can precede the commits they produce. A developer may also start a session on one ticket and switch context mid-session.

minware's patent-pending hypercube data model recovers these associations by modelling what commit and ticket each contributor was working on at any given time, working to connect agent sessions to roadmap epics without requiring explicit structured links in the source data.

Practices like missing ticket links and direct commits to main can create audit gaps where AI-assisted work can't be attributed to a roadmap item. Our post on direct commits to main covers why this habit creates both quality risk and measurement blind spots.

Measure engineering impact per token spent

The regression connecting spend to delivery outcomes is the analytical core of the audit. It quantifies how much additional delivery each dollar of token spend is associated with.

Story points completed per dollar spent

The regression fits a line where story points completed depends on token spend. The slope is the marginal delivery per dollar. A slope of 0.1 means each dollar of token spend is associated with one-tenth of a story point completed, or $100 of spend associated with 10 additional story points completed, already a strong result. Present R-squared alongside the slope. R-squared shows how much of the variation in story points completed is explained by the variation in token spend.

Two confounders are always worth naming explicitly in the audit report. Research shows that AI tools benefit experienced, senior-level developers, who increase productivity and expand into new domains, while early-career developers show no significant benefits despite being the most frequent adopters. That finding comes from one large study of AI coding tool adoption.

Cui et al.'s GitHub Copilot field study found the opposite pattern, with shorter-tenure developers showing larger productivity gains than longer-tenure developers, so treat the direction of this confounder as study-specific rather than settled. This selection effect means early adopters may not be representative of all developers.

Developers may also tend to use AI on more straightforward tasks, which could inflate the apparent output rate for AI-assisted work. A regression of spend against delivery across teams and time periods includes more variation than a binary AI-vs-non-AI split, though it may not eliminate these confounders entirely.

Track rework rate (bugs created divided by PRs merged) and PR cycle time alongside the delivery regression to confirm spend isn't inflating technical debt or creating review bottlenecks. A rising delivery slope paired with a rising rework rate may signal quality degradation that belongs in the business case.

"I use Minware for our SDLC metrics and appreciate its ability to provide quality metrics throughout our SDLC. It gives us clear visibility into code quality, defect rates, and overall development health." - George V. on G2

Our post on change failure rate and AI code covers the specific quality patterns that show up when AI code volume rises faster than code review capacity.

Spend correlated with roadmap delivery

Beyond sprint-level delivery metrics, connect token spend to epic and project completion. Which roadmap initiatives had the most AI-assisted work, and did they complete on time? This framing resonates with boards and finance teams because it connects spend to the commitments the organization made at the start of the quarter.

When teams are slower despite high AI spend, the causes are usually identifiable in the workflow data. Our post on why teams are slower covers structural patterns, including unplanned work absorption and sprint scope changes, that show up as velocity drops even when AI usage is high.

Analyze Claude Code patterns for budget anomalies

After building the regression, analyze the underlying spend data for waste patterns that inflate the bill without contributing to delivery outcomes.

Analyzing high-spend and zero-activity contributors

Identify high-spending contributors by token spend and compare their delivery output to their spend level. If high spenders show weak delivery correlation, investigate whether they're running long sessions that produce no mergeable commits.

At the other extreme, contributors with zero agent sessions across the full audit window may represent paid seats with no usage. Pull the contributor list from the Enterprise API and cross-reference against your identity system to identify these seats for potential cleanup.

Uncovering waste from repeated AI prompts

Three specific patterns inflate Claude Code token costs without proportional delivery gains:

• Context window bloat: Each new message in a session can re-send the full conversation history, including prior messages, file reads, tool outputs, and memory files. Long sessions can carry substantial token cost in re-transmitted context.

• Failed command loops: Commands that fail and retry without correction may burn tokens on the retry without advancing delivery.

• Low-yield sessions: Sessions that produce no commits or pull requests may represent spend with limited delivery association. Where these patterns appear consistently for a contributor, the session data gives a manager a specific starting point for a workflow conversation.

Benchmarking AI costs by team

Compare each team's regression slope, story points completed per dollar of token spend, rather than a simple total-spend-over-total-output ratio, which attributes all delivery to AI and breaks down for any team with unspent budget. Segment by repository or project to control for task complexity before drawing conclusions about team-level efficiency.

Build a defensible business case for AI spend

The regression, guardrail metrics, and waste analysis combine into a structured business case. Here's how to assemble it.

AI ROI and token efficiency

The audit's primary output is the regression slope: story points completed per dollar of token spend. That marginal figure is the correct ROI readout. Dividing total story points by total spend attributes all delivery to AI spend, including everything the team would have shipped without any AI assistance. The slope isolates the marginal contribution instead, which is what belongs in the business case.

Present R-squared alongside the slope. For teams that want to run statistical significance testing, export the regression data to CSV and use an external calculator. minware reports the slope and R-squared value, not confidence intervals or p-values.

Audit trails for token usage data

A defensible audit requires traceable data lineage. Every number in the business case must trace to a specific data source and a visible calculation. With minware, every metric's formula is visible and editable in the UI via minQL, so a finance reviewer who asks "how is this calculated?" gets a direct answer without an engineering escalation. Our post on debugging a failed metrics initiative covers why opaque metric definitions are the most common reason audit findings get rejected in executive reviews.

Build vs. buy decision matrix

If you're evaluating whether to build this audit pipeline internally, the full cost picture looks like this:

Evaluation factor	Custom internal pipeline	minware governance layer
Initial build time	Multiple weeks of engineering time	Immediate (14-day trial)
Annual maintenance	Recurring engineering time as APIs and schemas change	Covered by platform, aside from initial setup via customer success
Data normalization	Manual SQL scripts	Automated hypercube model: connects users, AI sessions, commits, PRs, and tickets across data sources
Metric customization	Hardcoded database views	Pre-built metrics, customizable without engineering

The annual maintenance line reflects ongoing compatibility updates as Claude Code, Jira, and GitHub evolve their APIs and schemas, plus the recurring cost of answering "how exactly is this calculated?" for every stakeholder who reviews the report. That question doesn't go away after launch. With an internal build, it lands indefinitely on whoever wrote the pipeline.

AI gateways like LiteLLM sit in a different category. They're effective for real-time cost control at the point of the API call, logging token counts and costs per request. Because they have no visibility into the commits, pull requests, or tickets that token spend produces downstream, they can't measure whether spend correlates with delivery improvement. Position the two as complementary: a gateway for spend control, a purpose-built analytics layer for outcome correlation.

Anthropic's data retention policy during the audit

Regarding Anthropic's data policies: per Anthropic's own documentation, retained data is never used for model training without the customer's express permission, and conversation content is not retained by default. Under a zero-data-retention (ZDR) arrangement, which Anthropic enables per organization on request, prompts and responses are not stored at rest after the API response returns, except that content flagged by Anthropic's automated trust and safety systems may be retained for up to two years. The exception to the default no-retention policy is Anthropic's Covered Models, which require 30-day retention regardless of ZDR.

Your Claude Code ROI narrative

The executive summary for your audit should follow a four-part structure:

1. Spend summary: Total token spend for the period and how it compares to the prior period.

2. Delivery correlation: The regression slope with units, the R-squared value, and a plain-English interpretation for non-technical stakeholders.

3. Guardrail check: Rework rate (quality) and PR cycle time (workflow) trends alongside the delivery regression.

4. Recommendation: Scale, hold, or cut spend based on the findings, with a specific action for each scenario: expand to additional teams, maintain current spend level, or reduce seats and redirect budget to higher-ROI tools.

Keep token spend audits accurate

The following approaches ensure audit findings are consistent, comparable across teams, and defensible in executive reviews.

Recognizing why login counts mask real ROI

Login counts and seat activation rates are activity metrics. They measure whether the tool is being used. Story points completed and roadmap delivery show whether the tool is moving the business forward. Conflating these is a common reason AI renewal conversations become difficult. Don't wait for a board question to start collecting the right data.

Standardizing metric definitions across teams

An audit that uses one team's definition of "done" and another team's sprint setup produces numbers that can't be compared across teams. minware's editable metric layer lets a customer success agent override the done status for sprint reporting, the estimate units used by each team, and the ticket fields that define a roadmap commitment, without engineering escalation or a roadmap item.

Preventing bias in usage audit reports

Selection bias is one of the most common sources of inflated AI ROI estimates in engineering audits. Early adopters of AI tools are often already high performers, so comparing their output to later adopters produces a flattering but misleading picture. The regression approach reduces this by treating spend level as a continuous variable across all contributors, rather than splitting into binary adopted-vs-not groups. Name the remaining selection bias in the audit report rather than hoping reviewers don't raise it.

Monitor Claude Code token spend

The following sections cover the setup sequence, recommended cadence, and readiness checks for running a repeatable audit.

Your token audit timeline

A realistic setup timeline for a first audit:

1. Days 1-3: Connect the Claude Enterprise Analytics API along with your version control and project management systems. Enterprise API data becomes available for dates on or after January 1, 2026 once connected. Deploy OpenTelemetry configuration centrally so per-session data starts flowing from this point forward.

2. Days 4-7: Verify identity resolution and data normalization across GitHub, Jira, and Claude Code. Confirm the team structure matches your current org hierarchy.

3. Week 2: Allow historical data to populate and validate that story points completed data covers the full audit period.

4. Weeks 3-4: Run the regression analysis, identify waste patterns, and draft the audit report for stakeholder review.

Self-audit feasibility checklist

Use this checklist to assess whether your current data setup supports a defensible audit:

1. Data source verification: Have you connected both the Enterprise API and OpenTelemetry exports?

2. Identity resolution and data normalization: Are developer identities mapped consistently across GitHub, Jira, and Claude Code, and are your agent sessions pulling through to commits, PRs, and ultimately value delivery?

3. Value metric baseline: Do you have at least 90 days of story points completed data that overlaps with token spend data?

4. Guardrails: Are rework rate (quality) and PR cycle time (workflow) tracked alongside your delivery metrics?

5. Data point diversity: Do you have enough variation in token spend, across time periods, individuals, or teams, for the regression to have something to work with?

6. Audit trail: Can every metric in your report be traced back to a visible formula and a named data source?

Recommended cadence for token audits

Run a full regression audit quarterly to catch spend anomalies before they compound across a billing cycle and to keep the methodology current as team structures and AI usage patterns evolve. Between full audits, a monthly spot-check of per-team spend against story points completed is enough to catch significant divergence early, before it becomes a renewal-cycle surprise. Our post on sprint goals covers how to interpret sprint completion trends alongside delivery velocity when assessing whether AI spend is improving delivery predictability or masking underlying planning problems.

Build the audit case with one methodological choice

A defensible Claude Code audit rests on one methodological choice: correlate token spend against value delivery metrics like story points completed and roadmap delivery through a linear regression, then use PR cycle time and rework rate to explain why the trend is moving rather than as substitutes for the ROI evidence itself. Engineering leaders who set this up before the board asks the question walk into the renewal conversation with a slope and an R-squared value instead of a defensive guess.

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 long does a Claude Code usage audit take to set up?

Initial configuration using minware's pre-built connectors is typically completed in a single session. Enterprise API data, available for dates on or after January 1, 2026, begins syncing on connection and completes within several hours depending on org size and data volume.

What minimum data is needed for a defensible regression analysis?

You need enough variation in token spend, across time periods, individuals, or teams, to yield a reliable R-squared value. A 90-day window with that variation is the practical floor for a regression that holds up in a procurement conversation, multiple teams are one way to get it, not a requirement. minware's pre-built AI impact reports run this regression automatically once at least 90 days of spend and delivery data are connected.

Does minware store the prompt text from Claude Code sessions?

You configure prompt text redaction within your own OpenTelemetry setup before data reaches minware. minware ingests and stores only the metadata required for token spend correlation. The audit methodology works with or without prompt content because token cost and session metadata are captured regardless.

Key terms glossary

Story points completed: A value delivery metric representing the sum of estimate fields for all completed tickets within a specified timeframe. The primary dependent variable in a Claude Code ROI regression.

Roadmap delivery: A value delivery metric tracking whether roadmap initiatives and epics complete on time relative to their estimated or due dates. An alternative dependent variable to story points completed for organizations that report at the initiative level.

PR cycle time: A workflow metric measuring the duration from a branch's first commit to the merge of its pull request. Unqualified, "cycle time" in this context refers to PR cycle time.

Rework rate: A quality metric calculated as bugs created divided by pull requests merged. A broader quality measure than change failure rate, which counts the percentage of production deployments requiring immediate intervention against total deployments.

Token spend: The actual dollar cost of AI model consumption for a given period. Token spend may differ from the amount billed to users on flat-rate plans. It is not a count of tokens.

Regression slope: The mathematical readout from a linear regression showing the marginal change in a delivery metric per dollar of token spend. This is the ROI figure itself, derived from fitting a line to the data, not from dividing total outcomes by total spend.

R-squared: A value between 0 and 1 indicating how much of the variation in the delivery metric is explained by variation in token spend.

Agent session: The unit of Claude Code activity representing a bounded period of autonomous task execution. The correct unit for counting real Claude Code usage.

minQL: minware's formula language that makes every metric formula visible and editable in the UI, enabling transparent data lineage and custom metric definitions.

Hypercube data model: minware's patent-pending data model that recovers relationships between entities like agent sessions, commits, and tickets by modeling what each contributor was working on at any given time, even when no explicit structured links exist.

Enterprise API: The Claude Enterprise Analytics API's endpoints providing per-user, per-model, per-day token spend aggregates, with data available for dates on or after January 1, 2026. A primary data source for trend analysis in renewal audits, alongside the Claude Code Analytics API for organizations without a Claude Enterprise plan.