What a Coding Agent Really Costs: Tokens, Energy and Rework as Delivery KPIs

The cost centre moved, the metric did not

In classic delivery planning the unit of cost is the person-day. A team has capacity, capacity has a price, and together they produce a plan a controller understands. That calculation worked for three decades because the dominant cost type was working time. Tools cost licence fees, infrastructure cost depreciation — both plannable, both largely independent of how intensively anyone worked on a given day.

Coding agents break that logic. Their cost arises not per head and month, but per request, per context processed, per iteration. A developer who runs an agent five times over the same codebase until the result fits generates cost five times — at an unchanged person-day. The cost curve detaches from the capacity curve, and that is exactly where person-day planning loses its explanatory power.

This is not a footnote for accounting. It is a steering question: anyone who does not know what a change costs cannot decide whether it is worth making. The discipline that answers this question already exists and is called FinOps — the practice of bringing financial accountability to variable spend models. The FinOps Framework published by the FinOps Foundation describes it in three phases: Inform, Optimize and Operate. On 14 September 2026 heise online placed the discipline before a wider audience under the title Kurz erklärt: Wie FinOps Kosten steuert.

How FinOps belongs in delivery governance is set out in Cost of Delivery: why FinOps is now your topic too. This article starts one level below: at the three concrete metrics that couple agent cost to delivery outcomes — and at the question of where the data for them comes from.

Why the person-day no longer works as a reference unit

The person-day measures effort, not outcome. As long as effort and outcome were tightly coupled this did no harm: more effort generally meant more delivered functionality. Coding agents decouple the two in both directions at once. Upwards, because an agent can produce in minutes what a team would have needed days for. Downwards, because an agent can produce changes that pass review, test and production and then have to be taken back.

The second direction is the more expensive and the less visible one. A reverted commit appears in no capacity plan as a loss — the time was booked, the agent delivered, the sprint closed. The cost arises downstream: in other developers’ review time, in incident remediation, in rework. Delivery organisations that do not measure this share mistake a partly relocated cost for a secured productivity gain.

On top of this comes a cost type that simply did not appear in classic delivery calculations: energy. On 16 September 2026 heise online described under Klimafaktor KI: Warum Agenten wie Claude Code echte Stromfresser sind that agentic working patterns — many iterations over large context — must be assessed differently in energy terms than a single model query. For organisations with sustainability targets this is not an academic question but one that will sooner or later become reportable.

The consequence is not to avoid agents. The consequence is to change the reference unit: away from effort, towards the delivered change.

Metric 1: cost per merged pull request

The first metric ties consumption to an outcome that is already cleanly defined and recorded in every repository: the merged pull request. The formula is deliberately simple — agent cost over a period divided by the number of pull requests merged in that period, viewed per team or per value stream, not per person.

The denominator is deliberately the merged, not the opened pull request. An opened PR is a statement of intent, a merged one is a delivery. Aborted agent runs and discarded suggestions therefore flow into the numerator but not the denominator — and that is intended: a team needing five attempts for one change should see that in the metric.

The explanatory power comes not from the absolute value but from the trend and the comparison. A rising value at constant output means more iterations are needed for the same result — a pointer to unclear requirements, poor context quality, or a use case the chosen model does not fit. A falling value at a rising change rate is the evidence a delivery lead owes the CFO.

The important limitation: this metric measures cost per delivery, not value per delivery. A pull request delivering a worthless feature is cheap and still waste. The metric does not replace prioritisation — it makes prioritisation comparable in monetary terms.

Metric 2: rework share of agent-generated changes

The second metric is the real stress test, and it has the advantage that an established frame of reference already exists. The DORA programme tracks deployment rework rate as a metric for changes that must be corrected shortly after deployment. The four classic metrics are documented at DORA; how the fifth metric works and why AI-generated code makes it more important is described in detail in Deployment Rework Rate: the fifth DORA metric.

The addition for agent cost is to break the rework share down by origin of the change: agent-generated versus hand-written. The question is not whether agents make mistakes — humans do too. It is whether the rework share of agent-generated changes sits systematically above that of manual changes, and whether that gap closes or widens over time.

If it widens, that is a solid signal that speed gains are being consumed again downstream. If it closes, that is evidence the organisation has learned how to deploy agents. Both are steering signals a pure cost view does not provide.

The methodological pitfall lies in attribution: anyone who does not mark agent-generated changes as they are created cannot separate them cleanly afterwards. The marking therefore belongs in the workflow, not in a later analysis — as a convention in the commit trailer or a label on the pull request, set at creation time.

Metric 3: cost per value stream, not per tool

The third metric answers the question actually asked in budget discussions: what does this product cost us? Not: what do coding agents cost us? The second question reliably leads to a tooling debate that misses the point, because it isolates one cost type instead of relating it to the outcome.

In practice this means assigning agent cost to the same cost centre as cloud resources, licences and personnel cost of the respective value stream. The FinOps phase Inform describes exactly this step: visibility and cost allocation as the precondition for any steering. Only when agent cost appears in the same report as the remaining cost of the value stream does the relevant question become decidable — whether its share of total effort stands in a defensible relation to the delivered outcome.

This allocation also exposes an effect a tool-level view conceals: agent cost usually does not replace personnel cost one for one, but is added to it first. Whether an efficiency gain results depends on whether capacity is actually redeployed — a leadership decision, not a property of the tool.

For the portfolio view, structured capture per initiative works well; the project portfolio template maps budget, risk and dependency views into one grid that cost allocation per value stream plugs into directly.

Where the data comes from — without new tooling

The most common objection to additional metrics is that the data foundation is missing. For these three metrics that is not true in most organisations. All required raw data already exists; it is simply not brought together.

The numerator comes from the provider’s billing data, ideally separated by project or key. The number of merged pull requests comes from the platform API of GitHub, GitLab or Azure DevOps. Rework attribution comes from commit metadata combined with deployment timestamps that every CI/CD pipeline logs anyway. Cost allocation per value stream comes from the same tag or label structure that already exists for cloud cost.

The effort lies not in acquisition but in convention: a consistent marking for origin and value stream, applied consistently. Anyone starting should not wait for completeness. A roughly correct view, available weekly and discussed in the existing delivery review, steers better than a perfect analysis published quarterly that reaches no one.

Equally important is where the numbers land: in the existing delivery review, next to deployment frequency and change failure rate. A separate AI cost report produces a separate discussion — and with it exactly the split between technical and economic decision-making that FinOps is meant to dissolve.

Three gates before an agent enters the production path

Metrics alone change no behaviour. For measurement to take effect it needs decision points at which it triggers something. Three gates have proven practicable because they attach to existing processes rather than creating new ones.

The first gate is origin marking: no agent-generated contribution reaches the main branch without it. Without that foundation metrics two and three cannot be built, and traceability is also missing where compliance requires it.

The second gate is a cost ceiling per value stream with defined escalation. Not as a block that stops work, but as a threshold at which a decision becomes due — comparable to a budget alert in cloud cost management.

The third gate is a rework threshold: if the rework share of agent-generated changes persistently and clearly exceeds that of manual changes, the use case is reviewed — the agent is not abolished, the scope is corrected. How ready your own delivery organisation is for such gates can be assessed in minutes with the free DevOps maturity check; the full assessment across all dimensions is provided by the delivery audit template.

Conclusion: one reference unit, three metrics, one review

Coding agents are not a tooling topic but a change in the cost structure of delivery. Steering them with the metrics of the person-day model measures the wrong quantity and will neither evidence nor limit their effect.

The switch is smaller than it sounds. One origin marking on the commit, three metrics from existing data, one existing review as the place to discuss them. No new committee, no new tool, no new bureaucracy — just the steering logic long established for lead time and change failure rate, applied to a cost type that did not exist three years ago.

The standard remains the same as in the rest of delivery governance: a metric is only useful once someone does something differently because of how it moves. Anyone who collects the three values but attaches no gates to them has built reporting, not steering.