For the first few years of generative AI in software development, the economics looked refreshingly simple. GitHub Copilot: roughly the price of another SaaS seat. ChatGPT: another monthly subscription. Multiply the number of developers by the price per user, put the number into the software budget, and move on.
That model is disappearing.
I explored the market for AI coding cost management in considerably more detail in the accompanying ETX2 Technology Brief: “The Emerging Landscape of Cost Management for AI-Driven Software Development.” It includes the four-layer market taxonomy, current pricing and cost ranges, hyperscaler and monitoring-platform comparisons, a survey of purpose-built AI FinOps products, OpenTelemetry developments, and practical cost-management strategies.
The data and product landscape are current as of August 2026; given how rapidly AI pricing and tooling are evolving, consider the brief a point-in-time market snapshot rather than an evergreen catalogue.
As coding assistants evolve into coding agents, they consume much more compute. They read repositories, reason over large contexts, modify multiple files, run tools, call other agents, test their own work and sometimes continue operating for extended periods without human intervention.
And somebody has to pay for all those tokens.
During 2026, the market has been moving decisively away from the idea that sophisticated AI coding can be offered as essentially unlimited usage behind a $20 subscription. GitHub, OpenAI, Anthropic, Cursor and others now combine subscriptions, usage allowances, credits, token consumption or considerably more expensive power-user plans.
The result is an interesting shift.
AI coding tools are starting to look less like software licenses and more like cloud infrastructure.
And that means engineering organizations may have to learn a lesson that IT infrastructure teams learned years ago: Consumption without cost attribution eventually becomes a problem.
The seat price is the floor
The headline prices for AI coding tools still look inexpensive.
GitHub Copilot starts around the price of a normal developer productivity tool. Cursor and Claude offer entry-level subscriptions around $20. Even $100 or $200 power-user tiers don’t look particularly dramatic when compared with the fully loaded cost of a software engineer.
But the subscription price increasingly tells only part of the story.
Research cited in the paper suggests that organizations combining inline coding assistance with more agentic workflows can end up spending around $200–$600 per developer per month. Anthropic has reported enterprise Claude Code usage averaging around $150–$250 per developer per month.
At the extreme end, Gartner warned in June 2026 that heavy agentic coding workloads can reach thousands of dollars per developer per month, with exceptional cases much higher.
Those extreme numbers obviously should not be interpreted as the typical cost of using an AI coding assistant.
But they reveal something important.
A developer clicking “accept” on an autocomplete suggestion and an autonomous agent spending hours iterating over a repository are technically both using an “AI coding tool.”
Economically, they are completely different workloads.
That distinction becomes increasingly important as agentic development matures.
More tokens don’t automatically mean more productivity
There is another reason why this matters.
If additional AI consumption reliably produced proportional improvements in engineering output, managing token cost would mostly be an accounting exercise.
Spend twice as much, produce twice as much software.
Unfortunately, the evidence does not suggest such a clean relationship.
One large study cited in the survey, covering more than 400 organizations over 14 months, reported a median increase in pull-request throughput of 7.76%, with many teams seeing improvements in roughly the 5–15% range.
That is useful.
It can easily justify several hundred dollars of additional tooling cost for a developer whose fully loaded employment cost runs into five figures per month.
But it is very different from assuming that AI turns every developer into three developers.
More importantly, Gartner’s warning is that there is no direct relationship between increasing token consumption and increasing productivity.
That creates what I would call the marginal-token problem.
The first few dollars of AI consumption may be extremely valuable. They eliminate tedious work, accelerate exploration or generate useful boilerplate.
The next hundred dollars may still produce substantial value.
But what about the next thousand?
At some point, running another agent, adding another reasoning loop or feeding even more context into a model may increase the bill without producing a corresponding improvement in shipped software.
Which means that simply measuring AI usage isn’t enough.
We need to connect consumption to engineering outcomes.
Cloud FinOps all over again
There is an obvious precedent.
When enterprises moved from owned infrastructure to public cloud, computing changed from something organizations purchased upfront into something they continuously consumed.
Technically, this was enormously powerful.
Financially, it created new problems.
Individual teams could provision infrastructure in minutes. Costs became distributed across thousands of resources. Bills became difficult to explain. And organizations discovered that giving engineers almost frictionless access to effectively unlimited computing resources could produce some interesting invoices.
FinOps emerged to answer seemingly simple questions:
Where is the money going?
Who is consuming it?
Which application is responsible?
AI coding is beginning to create a remarkably similar challenge. The difference is that the unit of consumption isn’t a virtual machine or storage volume.
It is increasingly an AI agent performing work, which makes attribution harder.
Knowing that the development organization consumed 12 billion tokens this month is not particularly useful.
Knowing that €18,000 was spent on AI-assisted development is somewhat better.
Knowing that €4,300 was spent on Project A is better still.
But the really interesting question is: What did that €4,300 actually produce?
An AI FinOps stack is emerging
While researching the market, I found that AI cost management is already starting to stratify into several layers.
I find it useful to think about four layers.
Layer 1: The AI providers
OpenAI, Anthropic and other model providers increasingly expose usage dashboards, APIs, project or workspace segmentation, spending limits and cost reporting.
This is the obvious starting point.
If all your development AI goes through one provider and a small number of API keys, native tooling may be sufficient.
The limitation is equally obvious: each provider sees only its own consumption.
Layer 2: The cloud platforms
Azure, AWS and Google Cloud add another level of context.
Azure combines Application Insights, Azure Monitor and API Management. AWS connects Bedrock telemetry with CloudWatch, inference profiles and Cost Explorer. Google increasingly integrates AI consumption with its broader Cloud Billing and monitoring capabilities.
This starts to look much more like classical FinOps.
Teams can allocate costs, detect anomalies, build dashboards and connect AI consumption with the wider infrastructure estate.
For enterprises already consuming models through their hyperscaler, this may become the natural control plane.
Layer 3: Enterprise observability
Then there are the platforms many enterprises already use to monitor distributed applications.
Datadog, Grafana, New Relic, Dynatrace, Splunk and Elastic are extending their observability stacks to understand generative AI.
Instead of monitoring only latency, errors and request volumes, they can increasingly trace model calls, token consumption, tool calls and estimated inference cost.
This is particularly interesting because AI agents are ultimately distributed systems.
A single agent request may trigger several model calls, invoke tools, query data, call APIs and initiate other agents.
Looking only at the final token bill tells you very little about what actually happened.
Layer 4: Purpose-built AI FinOps
The newest category is perhaps the most interesting.
A growing collection of startups is trying to connect AI expenditure directly to software engineering work.
Some attribute Claude Code or other coding-agent sessions to developers, repositories, branches or tickets. Others reconcile usage across multiple AI vendors. Some try to connect spend with story points, delivery metrics, rework rates or engineering outcomes.
This is where AI FinOps starts becoming something meaningfully different from traditional cloud cost management.
The important unit isn’t necessarily:
Cost per million tokens.
It might be:
AI cost per feature delivered.
Or:
AI cost per resolved ticket.
Or perhaps eventually:
AI cost per unit of business value created.
That is a much harder measurement problem.
But it is also the one that ultimately matters.
OpenTelemetry could become surprisingly important
There is another development in this space that deserves attention: the emerging OpenTelemetry GenAI Semantic Conventions.
OpenTelemetry already provides a vendor-neutral way to instrument distributed applications.
The GenAI conventions extend that model with concepts such as model calls, token counts, tool invocations and other generative-AI-specific telemetry.
Azure has adopted OpenTelemetry heavily for AI monitoring. Grafana uses it through OpenLIT. Langfuse and Traceloop support it, and AWS supports related telemetry scenarios as well.
This matters because instrumentation may ultimately be more strategic than the dashboard sitting on top of it.
If organizations standardize how AI activity is captured, they can route that telemetry into Application Insights today, Grafana tomorrow and another cost-management platform later.
For enterprises trying to avoid yet another observability silo, that is an attractive proposition.
What should enterprises do today?
The market is still immature, so buying another platform may not be the first step.
The more important change is conceptual.
Treat AI coding consumption as something that needs engineering and financial governance from day one.
That means establishing spending limits before broad rollout rather than after the first surprising invoice.
Measure real consumption for several months before negotiating enterprise commitments.
Consider moving very heavy users onto predictable flat-rate plans where appropriate.
Separate teams, projects and workloads so that costs can actually be attributed.
Use cheaper models for routine work and reserve expensive reasoning models for tasks that justify them.
And above all, don’t monitor AI expenditure in isolation.
Track rework. Track defects. Track throughput. Track delivery outcomes.
Then ask whether additional AI consumption correlates with improvements in those measures.
Because there is a dangerous metric hiding in every AI dashboard: Token consumption can go up even when value doesn’t.
From AI adoption to AI economics
For the last few years, the enterprise conversation around coding assistants has largely been about adoption.
Should developers be allowed to use them?
Which model performs best?
Can the tools access proprietary source code safely?
How much faster will developers become?
Those remain important questions.
But agentic development introduces another one:
What happens when AI starts consuming meaningful amounts of money while doing the work?
At that point, selecting an AI coding tool is no longer just a developer-experience decision. It becomes an economic architecture decision.
And the organizations that deploy hundreds or thousands of coding agents will eventually need to understand those agents much the same way they understand their cloud infrastructure:
who is using them, what they are doing, what they cost, and whether the result justifies the consumption.
The era of the $20 AI coding assistant isn’t necessarily over.
But increasingly, $20 is the entry price, not the cost model.
Defining the right model for the regarding coding job is challenging. And what about the cost for AI agents that are part of larger solutions and that consume token with each and every execution...
It is tough to see how the token consumption grows with a growing codebase when starting with agent teams in Claude Code. Time to optimize which model goes with what agent.