AI coding agents are burning through enterprise budgets faster than expected. Uber reportedly exhausted its entire 2026 AI budget by April after expanding its use of Claude Code. GitHub Copilot has moved from flat-rate pricing to metered credits. The era of cheap AI-assisted development is ending.

What You Need to Know

AI coding agents can consume 10 to 50 times more tokens than basic chat prompts because they plan, generate, test and retry autonomously. Gartner predicts that by 2028, AI coding token costs will surpass average developer salaries. Companies are now forced to choose between rationing usage and rethinking their entire inference economics. The shift from per-token pricing to owned capacity is reshaping how enterprises budget for AI development.

The Token Consumption Trap

When a developer assigns a coding task to an AI agent, the agent does not simply answer once. It plans, generates code, runs tests and repeats the process to correct errors. A single task can use 10 to 50 times more tokens than a basic chat prompt.

The more useful the agent becomes, the more calls it makes. With per-token pricing, the workflows creating the most value also become the most expensive. This creates a perverse incentive: the better your AI coding assistant performs, the faster it drains your budget.

Uber's experience illustrates the problem. The company reportedly burned through its entire 2026 AI budget by April after expanding its use of Claude Code. GitHub Copilot, meanwhile, abandoned flat-rate pricing for metered credits. These are not isolated incidents. They signal a structural shift in how AI coding tools are priced and consumed.

Why Cost Per Token Fails as a Metric

The natural response to runaway AI costs is rationing: usage caps, seat limits and approval workflows before developers launch agents. Blanket limits, however, can restrict the very workflows delivering value. They also optimize the wrong number.

Cost per token measures consumption, not results. Some spending reflects waste, including retries and runaway loops. Some represents the work of shipping software. A meter cannot distinguish between the two, and neither can a spending cap.

A better measure is cost per merged pull request: total AI-assisted development cost divided by the number of changes that pass review and are merged. Track rework and defects alongside it so cheaper changes do not conceal lower quality.

If that cost falls as AI usage rises, without compromising quality, developers are converting more consumption into useful software. The question is not how many tokens they use, but how much finished work the investment produces.

Matching the Model to the Task

Agentic coding does not require the most powerful model at every step. Use a frontier model, or an on-premises flagship when policy requires it, for difficult planning and novel reasoning. Route suitable work, including code generation, test creation and repeated refactoring, to open-weight models you operate yourself.

A gateway can route requests according to task complexity, data sensitivity, cost and latency. This reserves premium inference for the moments that justify it rather than applying premium pricing to an entire workflow. Meter the exception, not the workload.

Open-weight models make this division increasingly practical. Software-engineering benchmarks show that leading open-weight models can approach frontier performance on some tasks. That does not establish equivalence across every repository or workflow. Evaluate candidates against your own code, tests and acceptance criteria before assigning production work.

  • Frontier models: Reserve for difficult planning and novel reasoning where accuracy justifies premium cost.
  • Open-weight models: Route code generation, test creation and repeated refactoring to self-operated models.
  • Gateway routing: Direct requests by task complexity, data sensitivity, cost and latency to optimize spend.
  • On-premises inference: Keep sensitive code inside the enterprise while sending only approved prompts externally.

The Economics of Owned Capacity

With rented inference, every call adds to the bill. With owned capacity, most of the cost is committed upfront, so each additional call gets cheaper as usage grows. The economics are simple: per-token pricing makes heavy use more expensive, while owned capacity becomes more efficient as teams use it more.

Ownership is not free, though. Power, operations, maintenance and depreciation all must be considered. The number that matters is the fully loaded cost per merged pull request.

Owned capacity also delivers a type of value that never appears on an invoice: control over sensitive code. When code generation and testing run on-premises, proprietary code stays inside the enterprise. Only approved planning prompts and governed exceptions go to external models, through a gateway the organization controls. That opens the sensitive repositories where security usually stalls adoption, and where the biggest gains are waiting.

At HPE, a hybrid AI platform routes routine workloads from more than 150 internal applications to open-weight models running on premises, including on HPE Private Cloud AI. The result: token costs down 30 to 50%.

That is the point of hybrid. With HPE Private Cloud AI, owning your inference does not mean giving up frontier models. Run the volume on capacity you own and let a gateway send the hardest work to external models.

Why This Matters

The shift from per-token pricing to owned capacity will reshape enterprise AI budgets across the software industry. Companies that continue to rely solely on rented inference will face escalating costs as their AI coding agents become more capable and more heavily used. Those that adopt hybrid models will convert AI spending from a variable expense into a controlled capital investment.

Developers will feel this change directly. Teams that demonstrate cost per merged pull request will gain budget autonomy, while those that cannot justify their token consumption will face tighter caps and slower approval cycles. The organizations that measure what ships, not what they consume, will be the ones that scale AI coding successfully.