AI Coding Tool Cost Is Getting Harder to Forecast. Here’s What To Measure.

AI coding tools are moving into a new phase.

For the last couple of years, many organizations have treated them as a fairly predictable line item: licences, seats, adoption targets, enablement programmes.

That’s changing. Fast.

As AI coding tools shift towards usage-based pricing, the cost profile gets more variable. And with Nvidia’s CEO, Jensen Huang, predicting top-tier engineers will each use US$250,000 worth of tokens every month, engineering leaders are left trying to reforecast budgets and defend their snowballing AI spend.

Some are worried that costs will rise tenfold, while others are seeing a smaller impact than expected. Finance teams and boards don’t like uncertainty and won’t sign blank cheques for AI tools. It’s this unpredictability that’s adding to the pressure. 

Why AI Coding Tool Cost Varies

Agentic tools use tokens differently from a developer typing into a chat window. An agent might read files, gather context, call tools, edit code, run checks, retry failed steps, and summarise the result. All within one task.

Each step consumes tokens, so costs can rise faster than they would with occasional human-prompted use.

As well as the difference between individual developers and AI agents, two organizations with the same number of licences can end up with very different bills, depending on how their teams use the tools.

Some developers use AI occasionally for tests, documentation, boilerplate, and small fixes.

Others use it all day, across large contexts, with agents reading files, running tools, retrying tasks, and making multiple changes in the background.

That difference means budget conversations have to move beyond the number of licences you have, focusing on usage patterns, workflows, models, team behavior, and whether output is improving performance. 

High Usage Creates a New Planning Challenge

How do you reforecast AI coding spend when usage is uneven, you’re still rolling out adoption, and the tools are already embedded in your workflows?

A lot of organizations are starting by looking at token consumption.

That makes sense: usage-based pricing shows which users, teams, models, and workflows are driving cost. But token data only gets you so far.

A high-usage developer could be doing high-value work faster. They could be working on highly complex systems. They could also be leaving long sessions open, using expensive models for routine tasks, or generating output that creates more review and repair work later.

The same token profile can mean very different things.

It’s why we need to understand high usage alongside engineering outcomes. That means knowing the answers to these questions:

• Did meaningful output increase?
• Did maintainability hold up?
• Did review effort rise?
• Did the work survive beyond merge?
• Did you see gains in one team, one repo, one language, or one type of task?

Without that context, it’s hard to make the right decision.

You could end up restricting the people getting the most value from the tools. Or funding expensive usage patterns that don’t produce long-term engineering value.

The Quality Risk 

As our research shows, AI coding tools can improve developer productivity. We found that active developers with GenAI licences showed a 4.74% productivity increase, while a comparable control group saw productivity decline by 2.25% over the same period. 

In our Copilot analysis across 18 enterprises and 30,000+ developers, Copilot adoption was associated with a statistically validated 5.4% productivity uplift, with deeper usage linked to larger gains.  

Yet the same research also shows why productivity shouldn’t be the only metric you evaluate. Active GenAI-licensed developers saw a 4.21% increase in aberrant code, more than double the 1.70% increase observed in the control group. 

The combination of higher productivity and quality risk is what makes the new pricing environment so important.

As AI usage gets more expensive, you need to know whether the productivity uplift outweighs both the direct cost and the downstream engineering risk.

A Better Way to Reforecast AI Coding Spend

Reforecasting AI spend shouldn’t be about licence count alone. A more useful model has three layers.

1. Consumption: where is AI usage concentrated?

Start by mapping where the cost is coming from. Look at usage by team, user group, repo, workflow, model, and task type.

The goal is to identify concentration. Is spend spread fairly evenly across engineering? Or is a small group of users or workflows driving most of the consumption?

Usage concentration isn’t automatically bad, it just tells you where to investigate first.

A small number of heavy users may be creating disproportionate value. They might also be an obvious opportunity for training, model guidance, or workflow redesign.

2. Outcome: what did the usage produce?

The next layer is productivity.

This is where many AI ROI conversations flounder. Generated code, prompts, active seats, and token volume all show activity. But they don’t show whether useful engineering work increased.

You need a more objective unit of output – which is why we developed Billable Coding Effort. It measures meaningful engineering work over time, adjusted for commit behavior and work complexity. This means you can compare productivity before and after AI adoption, and across teams, projects, and regions.

With this objectivity, high usage is easier to interpret:

• High usage with higher Coding Effort may justify more investment.
• High usage with flat output needs a closer look.
• Low usage with no productivity change could signal poor adoption or a weak use case.

3. Consequence: what happened to quality and maintainability?

The final layer is quality.

Higher output is only valuable if the codebase can absorb it.

As AI-assisted development scales, leaders need to monitor maintainability, complexity, structural quality, rework, rollback, and repair patterns.

This is especially important because of the compounding cost of poor-quality code. It can block future change, increase review burden and operational risk, and make both human and agentic work harder over time.

For usage-based AI, it has to be part of the cost model.

AI spend should be evaluated against the quality of the work produced, not just the speed of production.

What You Can Do With the Evidence

When you combine visibility over consumption, outcome, and consequence, AI governance is much more practical. You can:

• Defend spend where high usage is producing more meaningful output and quality is stable.

• Scale the teams, repos, languages, or workflows where the return is strongest.

• Add training where users are consuming heavily without proportional output.

• Put controls in place where you’re seeing rework or maintainability drops offsetting productivity gains.

• Redesign workflows where agents are consuming more than the value they create.

With the switch to usage-based AI coding tools, this is exactly the kind of evidence you need.

The Planning Question For H2 2026

AI coding tools are already embedded in engineering workflows. Most organizations aren’t deciding whether to start from scratch. Instead, they’re deciding how to govern, optimize, and scale what they’ve already adopted.

As AI coding spend gets harder to forecast, it’s even more essential to connect usage to productivity, quality, and long-term maintainability.

With a more mature measurement layer AI budgets are easier to defend.

‍