How to Calculate Autonomous Coding Agent Cost per Merged Pull Request

The most useful economic unit for an autonomous coding agent is not cost per prompt or even cost per session. It is cost per accepted outcome. For repository work, a merged pull request is observable, reviewable, and tied to delivery, provided you also track quality after merge.

The budgeting mistake is to look at one visible rate and treat it as the whole system. Coding work crosses planning, context retrieval, tool calls, file edits, execution, validation, repair, and review. Every stage can add tokens, runtime, or people. A useful model preserves those layers and then rolls them into cost per accepted result.

What Matters for the Cost Model

• Abandoned branches consume spend but create no merged outcome.
• Human review and CI are part of the production cost.
• A large PR and a tiny fix should be segmented into task classes.
• Post-merge regressions must be charged back to the originating cohort.

These facts change the shape of spend, but they do not determine whether the product is economical. A higher-priced run can be the cheaper outcome if it merges on the first attempt and needs little review. A low-cost run becomes expensive when it wakes repeatedly, occupies compute while idle, or produces a patch that experts must rewrite.

Build the Equation Before the Forecast

Cost per merged PR equals all agent inference, sandbox, tool, CI, and reviewer cost for a cohort divided by merged PRs. If 100 attempts cost $420 in automation and $900 in review, and 72 merge, the full cost is $18.33 per merged PR.

Keep cached input, uncached input, and output separate because their rates can differ by an order of magnitude. Add tool fees, search calls, image or screenshot processing, and regional premiums only when the workflow actually uses them. For runtime, model billing minimums and rounding explicitly. A spreadsheet that assumes perfect per-second billing can understate a block-priced service.

A Worked Monthly Example

Split the cohort: 50 bug fixes merge at 84%, 30 refactors at 60%, and 20 documentation tasks at 95%. Aggregate acceptance is 79%, but the refactor class is the problem. Routing a stronger model only for refactors can improve economics without raising the price of every task.

Run a sensitivity range around the estimate. Use a low, expected, and high case for acceptance rate, output length, retry count, and runtime. Those variables usually move the answer more than a tiny difference in input-token price. The high case should represent a difficult but plausible sprint, not an impossible catastrophe.

Controls That Preserve the Savings

• Assign every run a task and project ID. Make this visible in the run record so the team can connect the control to dollars and accepted output.
• Accumulate retries under the original attempt. Make this visible in the run record so the team can connect the control to dollars and accepted output.
• Import CI minutes and reviewer time. Make this visible in the run record so the team can connect the control to dollars and accepted output.
• Track rollback and defect cost for 30 days. Make this visible in the run record so the team can connect the control to dollars and accepted output.

Give every automated run a durable identifier that follows retries, branches, builds, and review. Without that join key, invoices remain disconnected from engineering outcomes. Aggregate by task class, repository, team, model, and trigger so a change in workload mix does not masquerade as a price change.

The Failure Mode to Watch

Merged does not always mean valuable. Agents can optimize for easy, low-impact PRs or create review load through unnecessary changes. Pair cost per merge with severity, cycle time, change size, defect rate, and business value.

Set a stop condition before the run begins. Repeated failure on the same test, no material repository change, a spend ceiling, or a deadline can all trigger escalation. Stopping is not failure; it protects the budget and gives a human the evidence needed to change the approach instead of financing another identical loop.

How to Decide

Use the metric to compare models, prompts, and orchestration policies on the same task mix. Do not compare one team doing dependency updates with another doing architectural migrations. A stable denominator turns token optimization into an engineering decision.

Start with a bounded pilot and preserve a control group using the current process. Track model dollars, runtime dollars, tool charges, reviewer minutes, acceptance, cycle time, and post-merge defects. After enough comparable tasks, calculate total cost per accepted result. Use the AI Cost Calculator for the token component, then add the operational layers the API invoice does not show.