What does a merged agent pull request actually cost?

The run cost a dollar. Then a reviewer spent forty minutes untangling its changes.

That is an illustrative example, but it captures the problem with treating the number beside a thread as the price of the finished work. A useful cost calculation follows the Hoplite cloud agent through retries and review, including the attempts you decide to close.

Pick the unit you want to buy

For a team adopting coding agents, an accepted change is often a better unit than a prompt or a token. Define accepted before measuring it. You might require a merged PR that passes the team's checks and survives an agreed follow-up period without an attributable regression.

Use a batch of comparable tasks. Dividing one unusually easy change by its cost will produce an unusually flattering answer. Keep the abandoned attempts in the batch, since you paid for them too.

The basic calculation is straightforward:

Cost per accepted change = total batch cost / accepted changes

If no changes were accepted, report the total spend and zero accepted changes. There is no meaningful cost-per-accepted-change number to display yet.

Follow every billing route

Hoplite's cost card exposes thread-level usage and attribution. Its billing documentation distinguishes workspace credits from connected subscription and provider-key routes. A zero workspace-credit charge therefore does not mean the work has no economic cost. Another account or subscription may be paying for the inference.

Keep a ledger of which account paid each component. Allocate a subscription once across the period you are measuring. Don't charge its full monthly price to every PR and don't erase it because it appears outside Hoplite's credit balance.

Compute needs similar care. Hoplite documents that provider metering is available only when the provider exposes the required detail. A missing authoritative compute charge should stay marked as unavailable in your analysis. Treating it as zero would make the result look more complete than the records support.

Count the human work explicitly

Track minutes spent briefing, supervising and reviewing each task. If a run gets stuck on setup, include the time someone spends fixing the environment. That improvement may benefit later runs, so record it as setup work rather than hiding it inside the first successful PR.

Choose a consistent hourly rate for the calculation. It can be an internal planning rate; you do not need individual salary information. State which rate you used and keep it the same across the comparison.

Here is a hypothetical batch. Ten attempts incur $30 of total tool and infrastructure costs and two hours of human work valued at $75 per hour. Six changes are accepted. The batch costs $180 or $30 per accepted change. These numbers illustrate the accounting only. They are not Hoplite pricing or measured performance.

Separate expensive tasks from expensive mistakes

A large migration can justify more spend than a dependency bump. Group tasks by scope before comparing them. Then inspect the costly outliers.

A task may have consumed extra tokens because it repeatedly lost the failing test output. Another may have spent most of its time waiting for an external service. The fixes differ. One needs a better task record; the other may need a smaller local reproduction.

Hoplite supports lifetime thread spend limits. Use a limit to bound an attempt and define what the agent should report when it cannot finish. Hoplite parks the run when its recorded charges reach the limit. The limit covers model charges and available sandbox charges; it is not a cap on every external bill or on reviewer time.

Measure one week's delegated work with the failed runs included. Bring the largest outlier to your next engineering review. It will usually give you a more useful next step than debating token prices in isolation.