AI Coding ROI: How to Tell Whether Copilot, Cursor and Coding Agents Actually Pay for Themselves

Seat prices for AI coding tools are published, small next to a developer's salary, and easy to put in a spreadsheet, so most ROI cases are built on them. They leave out most of what the tools now cost. Since June 2026, GitHub Copilot has billed chat, agent and code review use in metered credits on top of the seat. Cursor splits included usage into pools and sells a higher-priced seat for heavy agent users, and Claude Code is billed by token through the API. The bill that arrives is driven by how developers work, not by how many seats were bought.

This guide covers what developer AI spend really includes, why vendor ROI figures are hard to trust, and how to work out whether your team is coming out ahead.

1. What AI Coding Tools Actually Cost

AI coding spend has three layers: the seat fee, metered usage on top of it, and the infrastructure the tools run against. Only the first appears on a price page.

The visible cost: per-seat licences

Seat prices are the figure procurement sees, and GitHub and Cursor publish them for every plan. Across tools they fall in a narrow band.

Copilot's included credits match the seat price dollar for dollar, so the seat works as a prepaid usage balance. Completions and next-edit suggestions don't draw from it. Once the balance is spent, an administrator can set an additional budget, and further use bills at model API rates.

The invisible cost: token and compute spend behind agentic workflows

Agentic tools make many model calls per task: reading files, planning, editing, running tests and reading the results back. Each call is billed on the tokens it sends and receives at the model provider's published rates, so the cost of a task depends on how many calls it takes and which model handles them. Copilot's credits, Cursor's usage pools and Claude Code's API billing all work this way.

Anthropic's documentation puts the average Claude Code cost across enterprise deployments at about $13 per developer per active day, or $150 to $250 a month, with 90% of users under $30 on an active day. Anthropic more than doubled that estimate in April from $6 a day, and said the change reflected its most advanced model becoming the default in Claude Code. Model choice moves the number as much as usage does: nOps's analysis of Cursor's billing found a 20x range between the cheapest and most expensive model for the same unit of output.

Why agent-based tools break per-seat pricing assumptions (one long-running task can cost more than a month's seat)

A per-seat price assumes one person uses the tool about as much as the next. Agents remove that assumption: one developer can run several in parallel or leave one working on a long task, so spend follows the work given to the agent, not headcount.

The vendors' own pricing changes show it. Cursor added a Premium seat for its heaviest agent users, with five times the usage of a Standard seat at three times the price. GitHub moved every Copilot plan to metered credits on June 1. The arithmetic is also direct: a single active day at the $30 mark that 90% of Claude Code users stay under costs more than a month of Copilot Business at $19.

Infrastructure costs: CI minutes burned on AI-generated PRs, extra review cycles, sandbox compute

Three costs fall outside the tool's invoice:

• Pipeline minutes. Teams that use AI tools merge more pull requests (Faros measured 98% more on high-adoption teams), and every pull request triggers a CI run billed by the minute. GitHub-hosted Linux runners cost $0.006 a minute on private repositories beyond the included allowance, and since June 1 each Copilot code review also consumes Actions minutes on top of its AI Credits.
• Review time. The same Faros data shows human review time per pull request rose 91% on high-adoption teams. This is the largest cost in the group and the least visible, because it appears as senior engineers' hours and not as an invoice. Section 3 covers how to measure it.
• Agent environments. Agents that execute code run it somewhere. In the vendor's hosted sandbox, the cost passes through the tool's credits. In your own cloud account or CI, it lands on the cloud invoice with no label tying it to the agent.

Worked example: licence cost vs all-in cost per developer per month

All-in cost per developer per month is the seat fee plus metered usage plus pipeline cost, plus the cost of the review time those pull requests consume. The seat fee is known in advance. The other three set the range, and they vary with how each developer works.

A developer who only uses Copilot completions costs the seat price, $19 to $39, because completions don't consume credits. A developer who uses agent mode and chat regularly costs the seat plus any credits beyond the included balance. A developer who runs Claude Code daily costs Anthropic's published $150 to $250 a month on top of any seat, roughly 8 to 13 times a $19 Copilot Business seat. Review time is excluded from all three figures and goes on the cost side of the model in Section 4.

2. Why showcased ROI Numbers are a wrong metric

Three kinds of figure circulate as AI coding ROI: speedups from controlled experiments, time savings reported in surveys, and case studies published by vendors. None is measured the way a finance team measures a return, and the better studies disagree with each other by an order of magnitude.

Self-reported vs measured productivity gains

Developers are poor judges of their own speed with these tools. In METR's randomized trial, experienced open-source developers took 19% longer on real tasks with AI allowed, and afterward estimated it had made them about 20% faster. METR's follow-up did not overturn that result so much as fail to replace it: developers increasingly refused to work without AI, which made the new data unreliable. The lasting finding is the gap between perception and measurement. METR's 2026 survey of 349 technical workers found a median self-reported change of 1.4x to 2x in the value of their work, and METR itself noted reasons to doubt the size of that figure.

Measured data from whole organizations sits far lower. DX analyzed pull request throughput at more than 400 companies from November 2024 to February 2026 and found a median increase of 7.76%, with most organizations between 5% and 15%.

Vendor-funded studies and what to discount

The most cited speedup figure, 55%, comes from a GitHub experiment in which 95 developers each wrote an HTTP server in JavaScript. It measured one self-contained task with a clear specification, which is where completion tools help most, and GitHub ran it with Microsoft's economists. It says little about maintaining a mature codebase, where METR and DX measured far smaller effects.

Three things reduce the weight a study deserves when it is used to justify a purchase:

• Task scope. A single greenfield task overstates the effect on ongoing work.
• Comparison group. GitClear found that heavy AI users out-produced non-users by four to ten times, but most of that gap existed before they used AI. Against their own earlier output, the gain was about 25%.
• Who ran it. Vendor studies and vendor-published case studies are useful for method and weak as benchmarks. IBM's account of measuring its own coding tool reports a return of about ten times the tool's annual cost per developer on one internal program, and its measurement approach is more instructive than the number.

Velocity without quality control is not value

More output is not more value if it has to be reviewed, fixed or rewritten. Faros analyzed telemetry from more than 10,000 developers and found that high-adoption teams completed 21% more tasks and had 9% more bugs per developer, with no measurable improvement in company-level delivery metrics. DORA's 2025 report shows the same split: AI adoption now correlates with higher throughput, a reversal from 2024, and still correlates with higher delivery instability.

The maintenance cost arrives later. GitClear's analysis of 623 million changed lines from 2023 to 2026 found duplicated code blocks up 81% since 2023, two-week churn up 15%, and refactoring moves down 70% from 2022 levels. These costs are paid after a pull request merges, so a dashboard of merged work overstates the return.

What engineering leaders should ask for instead

Ask for evidence at the level a finance team can audit:

• A baseline from before rollout, using the same repositories and a matched time window.
• Output measured on artifacts the team already reviews and stores, such as merged pull requests, instead of self-reported hours saved.
• A comparison group: teams without the tool, a phased rollout, or the same developers against their own history.
• Quality next to volume: rework, review time and incident rate on the changes that shipped.
• Total cost, including usage, infrastructure, review time and the time spent enabling developers.

IBM's seven-step account follows this structure, and Section 6 sets up the same measurement.

3. The Metrics That Actually Matter

AI coding tools change several things at once: how fast code is written, how much of it reaches review, and how often it comes back. The metrics below separate those effects, ordered from the usage numbers vendors report to the cost-adjusted measure that connects spend to output. The general framework for scoring AI value metrics is covered separately. This section covers what is specific to coding tools.

Suggestion acceptance rate (and why it's a usage metric, not a value metric)

Suggestion acceptance rate is the number vendor dashboards report first, and it measures usage. A high rate shows developers take suggestions. It does not show that the accepted code survived review, merged, or stayed unchanged afterward, because acceptance happens before all of those. Its practical use is finding seats that are paid for and not used, which feeds the low-adoption case in Section 5.

Code churn / rework rate on AI-generated code

Rework rate is the share of recently written code that is changed or deleted soon afterward. GitClear measures churn as code revised within two weeks of being written. For AI-assisted work, compare the rate on AI-assisted pull requests with the same team's rate before rollout, since churn varies widely by team and codebase. A rising rate means part of the throughput gain is being spent redoing work, and it belongs in the ROI model as a deduction from the gain.

Review time per PR — the cost that moves in the wrong direction

Review time per pull request is the metric most likely to move in the wrong direction. Faros's telemetry showed it rising sharply on high-adoption teams, as pull requests grew larger and more numerous. Track two numbers: hours from review request to approval, and total reviewer hours per week by team. The second matters more for cost, because larger and more frequent pull requests compound. The cost falls on senior engineers, which is how junior output gains get absorbed (Section 5).

Cycle time and lead time (DORA, applied carefully to AI-assisted work)

DORA's delivery metrics are lead time for changes, deployment frequency, change failure rate and time to restore, and they remain the standard for measuring delivery. Two cautions apply to AI-assisted work. First, cycle time can improve while quality falls, because a quick fix to last week's AI-assisted change counts as a short cycle, so read it next to change failure rate. Second, DORA's 2025 report describes AI as an amplifier of existing practice, so compare each team against its own baseline and not against other teams.

Defect and incident rate on AI-assisted changes

Defect and incident rate show whether faster output reaches production safely. Tag pull requests as AI-assisted using commit trailers or the tool's admin analytics, then compare change failure rate and incident count between assisted and unassisted changes by the same teams. Attribution is imperfect, since tool analytics are largely per user and not per change, so treat the comparison as directional and watch the trend across quarters.

Cost per merged PR — the unit metric that nets cost against output

Cost per merged pull request divides the total AI coding cost for a period (seats, usage and pipeline minutes) by the pull requests merged in the same period. It nets cost against output in one number, and it has the same structure as the cost-per-unit measures in AI unit economics. IBM's measurement method uses pull requests as the unit because they are already reviewed, approved and stored with metadata. Weight by pull request type, since a feature and a one-line fix are not equal, and read the metric as a trend: rising cost per merged pull request with flat throughput means spend is growing faster than output.

4. A Usable AI Coding ROI Model

The model has one job: turn measured inputs into a coding spend ROI figure, a net monthly value per developer, that can be checked line by line. It is deliberately simple, because the result depends far more on how well the gain is measured than on the arithmetic.

Inputs: team size, fully-loaded dev cost, licence cost, token/compute spend, measured cycle-time delta, rework rate

Six inputs, each from a named source:

• Team size (D). Developers actively using the tools, from seat and usage data.
• Fully loaded developer cost (C). Monthly salary, benefits and overhead per developer, from finance.
• License cost (L). Seat fees per developer per month.
• Token and compute spend (U). Metered usage and pipeline minutes per developer per month, from the tool and cloud invoices.
• Measured cycle-time delta (g). The gain in capacity against the pre-rollout baseline or a comparison group. A cut of x in cycle time frees about x / (1 - x) more capacity, so a 10% cut is an 11% gain.
• Rework rate (r). The share of the gained capacity lost to rework and extra review, from the churn and review-time measures in Section 3.

The formula, written out

Net monthly value per developer = C x g x (1 - r) - (L + U)

ROI = net monthly value per developer / (L + U)

Break-even gain = (L + U) / (C x (1 - r))

Team size cancels out of all three. A 100-developer organization and a 10-developer team with the same C, tool costs and measured gain have the same ROI. Size matters for fixed costs such as enablement and administration, and for how much confidence the measured gain deserves.

Scenario A: 10-developer team, autocomplete-led usage

Usage is mostly completions and occasional chat. Copilot completions don't consume credits, so tool cost is close to the seat price, $19 to $39 per developer. Cost is not the risk in this scenario. Adoption is: a seat nobody uses adds cost with no gain (Section 5). With ten developers the measured gain is also noisy, because one team's throughput varies month to month, so read any single quarter as a range.

Scenario B: 100-developer org, mixed usage

Most developers use completions and chat, and a minority run agents, so tool cost is a blend of the two groups. If one developer in five runs agents at about $200 a month and the rest sit on a $19 seat, blended cost is about $59 per developer. At 100 developers the harder problem is attribution: without spend tagged by team, nobody can say where the agent spend comes from (Section 6).

Scenario C: agent-heavy team (where token spend exceeds licence spend)

Every developer runs agents daily. Anthropic's $150 to $250 per developer per month is the typical range for Claude Code, and 90% of users stay under $30 on an active day, which is about $630 over 21 working days. With a seat of about $40, tool cost is $190 to $290 for typical use and up to about $670 for sustained heavy use. Token spend is now the dominant cost, several times the seat price, and it moves with model choice and with how many agents run at once. A budget built from seat counts is wrong by an order of magnitude here.

Break-even and sensitivity: which input, if wrong, flips the answer

Break-even gain is the share of a developer's capacity the tools must free to pay for themselves. The table assumes a fully loaded cost of $15,000 a month ($180,000 a year), an illustrative figure to replace with the real one from finance, and a rework rate of zero.

Two things follow. In Scenarios A and B no realistic tool cost changes the answer. The inputs that can flip it are the measured gain and the rework rate: METR measured a slowdown in 2025, DX's median gain is 7.76%, and both matter far more than a $19 seat. In Scenario C, tool cost matters too. At a 25% rework rate, sustained heavy use needs about a 6% gain to break even, which sits inside DX's 5% to 15% range, so an agent-heavy team can lose money while its output dashboard rises. Halving the fully loaded cost doubles every break-even figure, so use finance's number and not an estimate.

5. Where AI Coding ROI Goes Negative

AI coding ROI turns negative in five recurring ways, and none of them appears on a vendor's usage dashboard. Each shows up in a different system: seat activity, review queues, spend reports, code analysis and invoices.

Low adoption — paid seats nobody uses

A seat costs the same whether or not the developer opens the tool, so every idle seat adds cost with no gain and raises the cost per active developer in the Section 4 model. GitHub exposes the data needed to find them: each Copilot seat carries a last activity timestamp, and the seat breakdown counts seats that were inactive in the current billing cycle. IDE activity only counts toward that timestamp when the developer has IDE telemetry turned on, so confirm that setting before reclaiming seats from people who may only look inactive.

Senior review time absorbing junior velocity gains

Faros's 2026 report, covering 22,000 developers across 4,000 teams, compares teams with low and high AI adoption. On high-adoption teams, tasks with code completed rose 210%, but average pull request size rose 51.3% and average time in review rose 199.6%. Pull requests merged with no review at all rose 31.3%. Review capacity did not grow with output, so the queue lengthens or reviewers skim, and Faros describes the burden as falling on senior engineers. A gain counted in the author's hours is paid for in the reviewer's, which is why the Section 4 model deducts review and rework from the gain.

Agent loops and runaway task costs

Agent spend stops tracking developer activity when the agent keeps running without one. Claude Code's cost documentation lists the usual causes:

• Scheduled tasks. A scheduled task fires on its interval even while the session is idle, and each firing sends the full context.
• Subagents and teammates. Every subagent sends its own requests on top of the main conversation's, and agent teams use roughly 7x the tokens of a standard session when teammates run in plan mode.
• Long sessions. Claude Code sends the full conversation with every request, so a session left open all day draws usage for the whole history on each turn.

The documented controls are workspace spend limits for API organizations, spend limits at the organization, group or member level on Team and Enterprise plans, and a usage view that ranks the heaviest scheduled loops. Limits stop a runaway task only after the money is spent, so attribution matters as much (Section 7).

Technical debt and maintenance drag accruing later

A study of open-source projects that adopted Cursor found a large increase in development velocity that lasted about two months. Static analysis warnings rose about 30% and code complexity rose substantially, and neither faded; the authors identify those increases as a driver of the velocity slowdown that followed. The paper, Speed at the Cost of Quality, studied open-source repositories, so treat the size of the effect as indicative for proprietary codebases. The practical consequence is timing: a review held in the first quarter after rollout sees the gain and misses the debt, which is one reason Section 6 sets a recurring review cadence.

Tool sprawl: three overlapping assistants billed separately

In the Pragmatic Engineer's survey of 906 engineers in early 2026, 70% used between two and four AI tools at once and 15% used five or more. Each tool bills on its own terms: a Copilot seat, a Cursor plan with usage pools, per-token API billing for Claude Code. One developer can generate cost in all of them for work that one tool could handle, and no single invoice adds it up. The Section 4 model handles this by summing license and usage cost across every tool a developer uses before comparing it with the measured gain.

6. How to Set Up Measurement Before You Need the Answer

Most of the numbers in this guide depend on a baseline that cannot be reconstructed after rollout, so the measurement plan has to exist before the first seat is assigned. It has four parts: a pre-rollout baseline, spend attributed to teams, a comparison group where one is possible, and a review schedule tied to renewals.

Baseline before rollout — the step most teams skip and can never recover

IBM's measurement used matched twelve-week windows before and after adoption, on the same repositories with active developers, and counted pull requests classified as feature work, defect fixes or vulnerability remediation because those were already reviewed, approved and stored. Capture the same artifacts before rollout. Anthropic's guidance for Claude Code gives the same advice for cost: start with a small pilot group and establish a baseline before wider rollout.

The baseline needs five measures, each with a source that already exists:

Attributing AI spend to teams and repos

Each vendor reports spend per user, in its own format and with no shared team key. Claude Code exposes per-user cost through Console workspaces, the Claude Code Analytics API and OpenTelemetry export, and Team and Enterprise plans export a per-user spend report as a CSV. Copilot reports per-seat activity through its seat API. All of these are keyed to the person, not the repository, so rolling them up to a team or repo means joining each developer to the team that owns the code they work on. That join is the real work, and Section 7 covers doing it once instead of once per tool.

Running a holdout group where org size allows

IBM's own report notes that no comparable control group was available, so its result rests on a before-and-after comparison. A holdout is the stronger design, and METR's trial shows what it can reveal: developers who believed they were faster were measured slower. Where there are enough teams, stagger the rollout so the teams that start later act as the comparison group, matched on repositories and type of work. Smaller organizations usually cannot resolve an effect the size of DX's 7.76% median from one team's monthly throughput, so they should use their own history as the baseline and read the result as a range.

Quarterly review cadence tied to renewal dates

Renewals are when the numbers get used, so schedule the review a few weeks before each one. The review checks seat activity, spend against budget, cost per merged pull request, review hours, rework and change failure rate against the baseline. Pricing also changes between renewals: GitHub moved Copilot to metered credits on June 1, and Cursor restructured its Teams plans the same month, so each review should also confirm what the seat now includes.

7. Getting Visibility Into AI Coding Spend

Seat invoices show what was bought, and cloud bills show what was consumed in your own account, and neither reports developer AI spend by team. Closing that gap takes one dataset that holds both and a way to assign every dollar to an owner.

Why licence invoices and cloud bills tell you different halves of the story

A GitHub or Cursor invoice lists a fixed seat fee plus usage, attributed to individual users. Cloud bills work the other way: when coding tools route through a cloud provider such as Amazon Bedrock, usage appears in the AWS Cost and Usage Report by account and model with no developer or team attached, and spend billed directly by Anthropic or OpenAI never appears there at all. The pipeline minutes and agent environments from Section 1 sit on a third bill. Each shows part of the cost, and the total per developer exists nowhere until someone assembles it.

nOps assembles it. It brings the cloud bill and the AI tools' own billing data into one dataset, mapped hourly to model, account, department or product, and token type, with no agents or code changes.

Attributing token, API and compute spend to engineering teams

nOps assigns each dollar to a team without requiring tagging changes in AWS. Virtual tag rules match on service, account, region or existing tag values and assign a team, product or cost category. Rules run in priority order, the first match wins, and a catch-all rule placed last captures the remainder. An unallocated bucket shows what no rule has claimed, so allocated plus unallocated always equals total spend. Three controls build on that allocation:

• Budgets. AI Wallets set spend limits at the group or seat level, with predictive alerts before a seat is blocked and an approval flow to approve, partially fund or reject increases.
• Anomaly detection. An hourly comparison against the prior week flags anything running at three times its same-hour baseline, which is how a runaway agent loop gets caught before the invoice.
• Commitment management. Compute that agents run on in your own cloud account is covered by commitment management, which automates Savings Plan and Reserved Instance coverage so the infrastructure layer of AI coding cost is priced down as well.

nOps manages $5 billion in AI and cloud spend and was recently ranked #1 in G2's Cloud Cost Management category. Get a free savings analysis.

Demo

AI-Powered Cost Management Platform

Discover how much you can save in just 10 minutes!

Book a Demo

FAQ