AI coding agents plan, write code, run tests, and revise their work. That makes them useful for complex software tasks, but it also means a single task can consume 10 to 50 times more tokens than a basic chat prompt. As usage grows, token-based bills can rise alongside the value teams get from the tools.
The key question for companies is how to manage that growth. An article produced by HPE argues that usage caps and seat limits can constrain useful work because token counts measure consumption rather than finished software. It proposes tracking development cost against changes that pass review and are merged.
Connect spending to completed work
Cost per merged pull request is the total cost of AI-assisted development divided by the number of changes accepted and merged. It offers a way to relate spending to software that has made it through review, rather than treating every token as equally useful.
The metric needs context. A lower cost could reflect efficiency, but it could also come from cutting corners. Tracking rework and defects alongside it helps teams see whether savings come with a decline in quality.
This measure also changes the management question. Instead of asking how much AI usage to permit, leaders can examine whether more use produces more completed work for the investment. That makes it possible to distinguish productive development from waste such as repeated retries or runaway loops.
Reserve powerful models for the work that needs them
Not every step in an agentic coding workflow needs the most powerful model available. The HPE article suggests using frontier models for difficult planning and novel reasoning, while routing suitable work such as code generation, test creation, and repeated refactoring to open-weight models operated by the organization.
A gateway can select where requests go based on task complexity, data sensitivity, cost, and latency. In this approach, teams reserve premium inference for tasks that justify it and track those exceptions rather than applying premium pricing to an entire workflow.
Open-weight models can approach frontier performance on some software-engineering benchmark tasks, according to the article. That does not establish that they perform equally well across all codebases or workflows. Companies should evaluate them against their own code, tests, and acceptance criteria before relying on them in production.
Compare rented inference with owned capacity
With rented inference, each call adds to the bill. With owned capacity, much of the cost is committed upfront, so additional calls can become less expensive as usage grows. The comparison depends on steady demand: capacity that sits idle still carries costs.
Ownership also brings expenses that a simple token price may not capture, including power, operations, maintenance, and depreciation. For that reason, the article recommends comparing fully loaded cost per merged pull request, rather than looking only at the price of inference.
Running code generation and testing on premises can also keep proprietary code inside the enterprise. A controlled gateway can send only approved planning prompts and governed exceptions to external models. This can make it easier to use coding agents with sensitive repositories while maintaining control over what leaves the organization.
Measure usage before changing the model
HPE says its 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 company reports token costs down 30 to 50%.
The article also points to uneven usage as a reason to measure before setting policy. It says the top 5% of users generated most of the consumption, and the heaviest used roughly 450 times more than the lightest on the same license. If power users grow from a small minority to half the workforce, monthly spend can rise about 4.4 times with flat headcount. An organization’s own usage mix may differ.
HPE tracks cost per active developer as well as cost per merged pull request. The first highlights heavy users whose costs can disappear in averages across all licenses; the second links spending to software that ships.
Teams can establish a baseline for both measures, then run a complete development cycle on owned capacity and compare the results as usage grows. The article’s case for hybrid deployment is that companies can use frontier APIs for demanding or intermittent tasks and owned capacity for repeatable volume. Whether that arrangement pays off depends on the organization’s workload and fully loaded costs.