Stop Counting Tokens — Start Counting How Many PRs You Merge

Once a coding agent picks up a task, it will plan, generate code, run tests, fix errors, and repeat the cycle. A single task can consume 10 to 50 times more tokens than a regular chat prompt. The more capable the agent is, the more frequently it gets called. Under token-based billing, the highest-productivity workflows often end up with the most unruly, runaway bills.

Financial pressures are already emerging. Reports show that Uber exhausted its full-year AI budget back in April 2026 after scaling up its use of Claude Code. GitHub Copilot has also shifted from a flat-rate pricing model to a usage-based credits system. According to Gartner's forecast, by 2028, token costs for AI programming will exceed the average developer's annual salary.

The most intuitive reaction is to set usage caps: upper limits on consumption, seat restrictions, pre-launch approval requirements. The problem is that one-size-fits-all caps will first bottleneck the very workflows that are delivering real value, while optimizing for the wrong metric. Cost per token measures consumption, not outcomes. Some token spend goes to failed retries and runaway loops, while other spend goes to software that actually gets shipped. The token counter cannot tell the difference, and neither can arbitrary spending caps.

A far more reliable metric is cost per merged PR: divide the total cost of AI-assisted development by the number of changes that pass review and get merged. Track rework rates and defect rates alongside this metric, to avoid cheaper changes coming at the cost of hidden quality drops. If AI usage rises while this cost falls and quality stays stable, it means the team is converting more token consumption into working, useful software. The core question becomes: how much completed, production-ready work are we getting out of this investment?

Improving this equation requires two key moves. First, reserve expensive high-end inference only for tasks that truly need it. Agent-based coding does not require the most powerful model for every single step. Use cutting-edge frontier models for difficult planning and novel inference tasks, and use on-premises flagship models when policies require data residency. Code generation, test creation, and repetitive refactoring can all be routed to self-hosted open-weight models. An inference gateway distributes requests based on task complexity, data sensitivity, cost, and latency requirements. Only meter exceptional use cases, don't wrap the entire workflow in premium pricing. Open-weight models now perform close to frontier models on some software engineering benchmarks, but that does not mean they are equivalent for every code repo and process. Evaluate them against your own codebase, test suites, and acceptance criteria before rolling them to production.

Second, restructure the economics of repeated usage. Renting inference capacity adds to your bill every single time you make a call. Owning capacity means most of your costs are paid upfront, so the more calls you make, the cheaper each individual call gets. Self-owned capacity is not free: you still have to account for power, operations, maintenance, and depreciation. The real number to track is the full-load unit cost, allocated to every merged PR. Self-hosted capacity also delivers one unlisted value that never shows up on invoices: full control over sensitive code. Code generation and test runs stay local, keeping proprietary code within the corporate firewall. Only approved planning prompts and governed exception requests get sent to external models via organization-controlled gateways. This unlocks the most sensitive code repos that were previously blocked from AI adoption over security concerns, and which hold the largest potential productivity gains.

HPE's use case works as a proof of concept for this operating model. Its hybrid AI platform routes regular workloads for more than 150 internal applications to locally run open-weight models, including HPE Private Cloud AI. The result was a 30% to 50% drop in total token costs. "Hybrid" here means owning inference capacity does not mean you abandon frontier models entirely. Run the bulk of your routine workload on your own capacity, and send the most complex, hard tasks out to frontier models via the governed gateway.

The data also shows actual usage drives spending far more than licensed headcount. The top 5% of users account for the vast majority of total consumption: under the same license, heavy users consume roughly 450x more resources than light users. If heavy users expand from a tiny minority to half of all employees, your total headcount stays the same, but monthly spending could surge roughly 4.4x. Every company has a different team structure, which is exactly why you need to measure your own actual metrics.

HPE tracks two metrics, and recommends its customers do the same. First, cost per active developer: averaging all license costs across the whole team hides the heavy users that are driving most of your overspend. Second, cost per merged PR: this ties your AI spending directly to software that actually ships to production. Establish a baseline for both of these costs before modifying your infrastructure. Then run a full development cycle on your self-owned capacity. If usage goes up and neither of the two metrics improves, your current API-based model may still be the better choice.

Self-owned capacity is not for everyone. If your usage is low or highly unpredictable, APIs are a better fit, so you do not have to tie up capital in idle infrastructure. Ownership only makes financial sense when you have sustained, steady demand that can keep your capacity fully utilized. Most enterprises will land on a hybrid model: use frontier APIs for demanding or one-off intermittent workloads, and use self-owned capacity for repeatable, high-volume tasks. A governed gateway decides what data leaves your corporate network, so you can leverage the power of frontier models without giving up full sovereignty over your code.

The more developers rely on coding agents, the more usage will continue to grow. The real choice you face is whether that growth turns into an ever-larger variable cost bill, or translates into more working software running on capacity you own. Companies leading in AI-assisted development do not control costs by capping and limiting adoption. They build a proper operating model that makes increased AI usage improve their unit economics, rather than erode them.

Note: This content is produced by MIT Technology Review sponsored by HPE. Case studies and data are sourced from public disclosures by HPE. More information on HPE Private Cloud AI is available here.