October 15, 2026

Measure AI Coding Cost per Accepted Change

A cheap generation can produce an expensive change. Count the whole workflow and be explicit about what you accepted.

7 min read

Contents

Define an accepted change before recording costs
Keep three kinds of money separate
Build an attempt ledger that retains failures
Add human work and infrastructure without double counting
Run the hypothetical comparison
Test an escalation policy before optimizing it
Keep production merge accounting in a separate ledger
Use Agentastic's local usage data within its scope
Frequently asked questions

AI coding cost per accepted change is the cost of the whole workflow divided by the number of outcomes that meet a declared acceptance standard. Count unsuccessful attempts, review, repair, and infrastructure alongside model usage. Then keep that experimental measure separate from cost per actual merged pull request.

An accepted code box balances against a clock, coins, and discarded retry drafts.

This guide supplies a small CSV ledger and a Python calculator. You can replace the sample with your own records and see how a lower inference bill interacts with human time. The sample values are hypothetical, not provider prices or benchmark results. The calculator was checked with Python 3.14.4 on October 15, 2026.

Define an accepted change before recording costs#

For an experiment, use a concrete contract: all required behavior and regression checks pass, and an independent reviewer finds no blocking issue under a fixed rubric. The repository evaluation guide explains how to freeze that contract.

A trial is one execution of the complete workflow on one task. It can include several permitted attempts. If the second attempt succeeds, the trial produces one accepted outcome and carries the cost of both attempts.

These denominators answer different questions:

Denominator	What it measures	What it does not establish
All attempts	Cost of trying to generate or repair code	Useful completion
Accepted trials	Experimental cost of a workflow achieving the task contract	Distinct shipped features
Unique accepted tasks	Cost to finish distinct tasks in the selected cohort	Pull requests merged
Actual merged PRs	Cost per recorded integration event	Equal business value per PR

If the same task succeeds in three independent repetitions, it contributes three accepted trials but only one distinct task. Label the experimental result accordingly. Do not call those three successes “three merged changes.”

Likewise, one PR may finish multiple tasks, or one feature may need several stacked PRs. The unit should match the decision you are making.

Keep three kinds of money separate#

The most common accounting error is combining values that describe the same usage in different ways.

Actual usage charges come from provider billing records. Record the applicable currency, reporting window, and whether credits or taxes are included. Reconcile estimates with those records when they arrive.

Subscription allocation assigns some part of a fixed seat or plan cost to the workload. Choose a reproducible allocation rule, such as seat-days assigned to a project or a documented share of the monthly subscription. An allocation is a management assumption; it is not a per-task invoice.

List-rate estimates multiply recorded token categories by a published price table. They can help compare consumption or approximate an API equivalent, but they do not prove what a subscription user paid.

Keep the estimate as a separate reference column. Do not add it to the subscription allocation for the same usage. If a workflow also makes separately billed API calls, include those distinct actual charges.

For any rate-based estimate, record the model identifier, price-table date, cached versus uncached input treatment, and applicable context tier. A single blended “cost per token” can conceal important differences. This article avoids quoting live model prices because the workbook should work with your actual accounting basis.

Build an attempt ledger that retains failures#

Download the hypothetical attempt ledger and Python calculator.

Each row represents one attempt:

csv

policy,task_id,trial_id,attempt_id,accepted,billed_api_usd,list_estimate_usd,allocated_subscription_usd,infra_usd,review_minutes,repair_minutes
fixed,checkout,f01,1,true,4,4,0,0.20,10,0

The sample uses USD throughout. For another currency, adapt the column names and convert all inputs consistently before adding them.

Use stable identifiers to connect the ledger to your evaluation artifacts. A trial ID names one execution, not merely a model session that might contain unrelated work. Number attempts from one within each trial. Mark only the final successful attempt true; abandoned trials end with false.

Record the human time spent assessing failed attempts too. If a developer spends eight minutes discovering that a patch is unusable, those minutes belong to that trial. The calculator deliberately includes every row.

The script rejects duplicate attempts, missing or negative numbers, invalid acceptance flags, and trials that continue after acceptance. It uses Python's decimal arithmetic and rounds displayed money values after calculating totals.

It does not infer attribution from chat logs, discover PRs, or estimate missing costs. Unknown inputs need investigation; substituting zero would silently understate the result.

Add human work and infrastructure without double counting#

Review minutes mean active time reading the diff, reproducing findings, and deciding whether to accept it. Repair minutes mean human effort directing or performing fixes. Keep those timers mutually exclusive.

A useful cost model is:

cash-and-allocated cost =
    billed API charges
  + allocated subscription cost
  + attributable infrastructure

modeled human cost =
    (review minutes + repair minutes) / 60
  × chosen hourly rate

experimental cost per accepted trial =
    (all cash-and-allocated cost + all modeled human cost)
  / accepted trials

The hourly rate is an assumption. Record how you chose it, and publish a cash-only result beside the result including labor. That lets a reader separate an invoice question from a capacity-planning question.

Count infrastructure only once. A dedicated evaluation VM can be attributed by runtime; a shared CI runner needs an explicit allocation rule. If the hourly labor assumption already includes a particular overhead, do not add that same overhead again.

Wall-clock waiting time is also useful, but differs from active human time. A thirty-minute build while the developer works elsewhere is not automatically thirty minutes of review labor. Record elapsed duration separately when throughput or feedback latency matters.

Run the hypothetical comparison#

The sample compares two unnamed policies over the same four tasks:

Fixed: use one configuration, with a retry where permitted.
Escalation: start with a lower-cost attempt and use a more expensive follow-up for one task.

Each policy has four trials and five attempts. Three trials are accepted; the fourth is abandoned. No actual agents generated these rows.

Run the calculator from the directory containing the two downloads:

bash

python3 calculate_cost.py attempts.example.csv --hourly-rate 90

The example uses a hypothetical human-time rate of $90 per hour:

Sample total	Fixed policy	Escalation policy
Actual-charge column, hypothetical USD	$18.00	$10.00
Subscription allocation	$0.00	$0.00
Infrastructure	$1.00	$1.00
Review and repair time	39 minutes	48 minutes
Modeled human cost	$58.50	$72.00
Total including human cost	$77.50	$83.00
Accepted trials	3	3
Cash and allocated cost per accepted trial	$6.33	$3.67
Total cost per accepted trial	$25.83	$27.67

The list-rate reference column is reported separately and is not added to those totals.

In this constructed example, escalation saves $8 in cash cost but consumes nine more human minutes. At $90 per hour, those minutes cost $13.50, making escalation $5.50 more expensive across the cohort.

The break-even hourly rate is about $53.33: $8 divided by nine minutes, multiplied by sixty. Below that assumed rate, escalation has the lower combined total in this sample; above it, fixed does. This is sensitivity analysis of invented inputs, not a finding about model quality.

If no trials are accepted, the ratio is undefined. The calculator emits null for that value while retaining total spend. Reporting zero would suggest free success when the workflow delivered none.

Test an escalation policy before optimizing it#

A real escalation policy needs a trigger that can be applied consistently. “Use the stronger model when it feels necessary” depends on the operator and makes the comparison difficult to repeat.

For example, define a policy before collecting data:

First attempt: configured model A, up to 10 minutes.
Escalation: one attempt with configured model B if required checks
still fail, or if the first attempt reaches its limit.
Second attempt: up to 15 minutes.
No additional attempts; unresolved work is recorded as unsuccessful.

Decide whether B receives A's patch and transcript or starts fresh. Those are different workflows with different costs. Preserve the decision in the manifest and charge all stages.

GitHub's HydraFusion research preview explores multi-model orchestration. It motivates evaluating routing and revision policies, but its results cannot predict the outcome on your repository.

Compare the same task cohort, acceptance rubric, and operational limits. Record quality and success counts next to cost. A policy that cheaply completes only the easy tasks may have a lower successful-task average while leaving the important work unfinished.

Keep production merge accounting in a separate ledger#

Download the merged-PR ledger template when you want to measure actual integration.

Populate the repository, PR number, and merge timestamp from real hosting records. Link task and attempt identifiers to the PR, and document allocations where one attempt supports multiple PRs. Keep abandoned work in the cohort's total cost even though it has no merge record.

Choose a cohort boundary before reporting. One option is tasks started during a particular month, observed until a defined cutoff. Report how many remain in progress. Another is merged PRs in a month with their attributable earlier costs, plus a separately disclosed abandoned-work allocation. Mixing this month's spend with only this month's merges can distort results when implementation spans periods.

Include integration work such as conflict repair and post-review changes. If a merged PR is later reverted, retain that event rather than quietly counting it as a durable success. You may report both gross merges and changes still accepted after a stated observation window.

PR count is an operational unit, not a value score. Track the type and size of work so splitting a change into more PRs does not look like an automatic efficiency improvement.

Use Agentastic's local usage data within its scope#

Agentastic's Usage panel reads Claude Code and Codex logs on the current Mac and shows token history with costs estimated at published pay-as-you-go list rates. It also displays provider-reported subscription quota separately.

Those estimates are useful inputs for understanding consumption. They are not invoice totals, remote-host usage, automatic PR attribution, or a record of human review minutes. Collect those elsewhere. Our usage tracking guide explains the local workflow.

To compare policies, use Agentastic to organize the task work and independent review, then maintain the attempt ledger beside the artifacts. Download Agentastic and start with one week's small, consistently reviewed changes before extending the process across an agent orchestration workflow.

Frequently asked questions#

How do you calculate cost per accepted AI coding change?#

Divide all attributable costs in a fixed task cohort by its accepted outcomes. Include failed attempts, retries, review, and infrastructure. State whether the denominator is accepted experimental trials, unique completed tasks, or actual merged pull requests; those measures are not interchangeable.

Should I add API estimates to a coding subscription bill?#

Do not add a list-rate estimate for subscription-covered usage to the subscription charge. Keep actual API charges, allocated subscription costs, and hypothetical list-rate estimates separate. Additional API usage can be included if it is a distinct billed cost.

Does Agentastic show actual billed cost per pull request?#

No. Its Usage panel reads local Mac logs and estimates token costs at published pay-as-you-go list rates. Actual invoices, PR attribution, human review time, and usage from remote or cloud hosts require separate collection.

How should abandoned agent attempts count?#

Keep their attributable costs in the same cohort as the attempted work. An abandoned attempt adds cost and produces no accepted outcome. Removing it makes the surviving changes appear cheaper than the workflow really was.

Does the downloadable calculator contain real model benchmarks?#

No. The sample CSV is deliberately hypothetical, and the hourly rate is an example assumption. The calculator and arithmetic were checked locally, but the sample does not measure or rank any provider or model.