Research-backed calculator guide

AI-Generated Code Rework Cost: Calculate Cost per Accepted Change

A provider-neutral method to calculate AI-generated code rework cost per accepted change, including review, retries, CI, human time, rejected work, and remediation.

AI-generated code rework cost is best measured as total attributable workflow cost divided by accepted or merged changes. A pull request or model call is only an attempt. The accepted change is the outcome that creates usable engineering value.

That distinction matters when a coding agent produces a change that is reviewed twice, fails CI, is rewritten by an engineer, or is abandoned. A low model bill can still sit inside an expensive delivery loop. Conversely, a large model bill may be reasonable if it replaces many review hours and produces a mergeable change on the first pass.

This guide gives you a reusable ledger for the AI-generated code rework cost per accepted change. It includes model and review usage, human review, CI and test runs, retries, engineering rework, rejected work, and a conservative remediation reserve. The numbers in the worked example are planning assumptions, not a vendor quote.

What belongs in an accepted-change ledger?

Start with one row per generated change, review pass, or clearly attributable workflow attempt. The row should have an identifier that lets you join model usage, pull-request events, CI runs, review comments, and the final outcome. Useful outcome values include accepted, accepted_after_rework, rejected, abandoned, rolled_back, and still_open.

The denominator is the first control. Define “accepted” before collecting numbers. A practical definition is a change merged into the target branch and not rolled back within the measurement window. If your team prefers “approved for release,” record that explicitly and use the same rule every month. A change that is generated, reviewed, and then discarded belongs in the numerator but not the denominator.

The numerator should contain direct cost and allocated cost. Direct cost is usually model usage, a metered review, or a CI charge that your provider exposes. Allocated cost includes review minutes, developer rework, test investigation, and a reasonable share of incident or rollback work. Keep these categories separate even when the final report shows one total. Separate lines make it possible to challenge an assumption without rebuilding the entire model.

A code-review tool may have more than one meter. GitHub’s Copilot documentation says code review uses AI credits for token consumption and GitHub Actions minutes for the agentic infrastructure. It also says the model is selected automatically for code review, so a per-token estimate can vary between reviews. ^[3] This is why a ledger should reconcile both the provider or platform bill and workflow events instead of applying a flat review price to every pull request.

Anthropic’s March 2026 Code Review announcement gives a different but equally useful signal: reviews scale with pull-request size and complexity, average about 20 minutes in its testing, and are billed on token usage at an announced average of $15–$25. Those figures are dated vendor observations, not universal rates. ^[2] If you use them for planning, label the date, currency, plan, and whether the amount covers only the AI review or the whole engineering workflow.

The calculation model

Let:

• G = generated changes or attempts during the period.
• A = accepted or merged changes during the period.
• M = model and automated-review spend attributable to those attempts.
• H = human review and approval time.
• C = CI, test, runner, and environment cost.
• R = retry and follow-up model usage.
• W = engineering rework time after review or failed tests.
• D = handling cost for rejected or abandoned changes.
• Q = rollback, remediation, or incident reserve.

Then:

total attributable cost = M + H + C + R + W + D + Q

cost per accepted change = total attributable cost / A

Also calculate the acceptance rate:

acceptance rate = A / G

If you track only generated attempts, you can calculate attempt cost, but you cannot explain whether a cheaper workflow is producing more accepted work. Keep both metrics in the dashboard. The accepted-change figure is the unit-economics measure; the attempt figure is an operational diagnostic.

Allocate shared engineering time carefully

Human time is commonly the largest line item. Measure review minutes from a sampling study, pull-request timestamps, or a time-tracking export. Do not assume that the model’s response time equals a person’s review time. A reviewer may spend five minutes reading a diff, twenty minutes reproducing a failure, and another fifteen minutes checking a follow-up patch.

Use a loaded hourly rate rather than salary alone if the decision is about team capacity. State whether the rate includes benefits, payroll taxes, management, and other overhead. If finance has no approved rate, use a planning estimate and show a sensitivity range. For example, run the same ledger at $65, $85, and $110 per hour. That range is an internal assumption, not a market benchmark.

CI cost can be measured as runner minutes multiplied by the applicable rate, plus test infrastructure or ephemeral environment charges. If those costs are immaterial for a small repository, show them as zero with an explanation instead of silently omitting them. If a shared runner cannot be attributed exactly, allocate by runner minutes or test execution count and label the method.

FinOps describes financial accountability as a collaboration between engineering, finance, and business teams, with accessible and accurate data and ownership for technology usage. That framing fits this ledger: engineering owns the event definitions, finance validates rates and allocation, and the product owner decides what outcome is valuable. ^[4]

Worked cost example

Assume a US engineering team is testing a coding-agent workflow for one month. The team generated 150 changes and accepted 120 of them. The assumptions below are deliberately visible so you can replace them with your own invoice and time-study data.

The resulting unit cost is:

$7,274.80 ÷ 120 accepted changes = $60.62 per accepted change

The acceptance rate is 120 ÷ 150, or 80%. For comparison, the cost per generated attempt is $7,274.80 ÷ 150 = $48.50. Both numbers are correct, but they answer different questions. The first asks what usable change costs. The second asks what each attempt costs before outcome loss is considered.

The most important insight is not the two-decimal result. It is the shape of the total. Human review is $4,675, or about 64% of the ledger. Rework is $1,377, or about 19%. The model and automated-review line is $330, or about 5%. If the team tries to optimize only model pricing, it may miss the larger opportunity: reduce avoidable review minutes, increase first-pass acceptance, or prevent repeated CI cycles.

If acceptance rises from 80% to 90% while the numerator stays at $7,274.80, 135 accepted changes produce a cost of about $53.89 each. If rework minutes fall by one-third, the numerator falls by $459 and accepted-change cost falls to about $56.80. These are scenario calculations, not promises. They show why process quality and outcome rates should sit beside token prices in the same model.

How to collect better inputs

Create a stable event schema before creating a dashboard. At minimum, capture a change ID, repository, author type, model or reviewer, token usage if available, review-pass count, CI attempts, human review minutes, rework minutes, final status, merge timestamp, and rollback or incident link. A lightweight spreadsheet is enough for a pilot if every row has an owner and a date.

Reconcile model usage with invoices. For token-based APIs, store input, output, and cached-token quantities separately. For a platform that hides model selection or bundles features, store the platform’s usage event and the plan or credit rate used on the invoice date. Do not backfill a vendor’s advertised average into historical rows unless you label those rows as estimates.

Measure rework as effort caused by the generated change, not every edit that happens afterward. A reviewer may improve naming during normal development; that is not necessarily AI rework. Count rework when a defect, failed test, unmet requirement, security concern, or review finding requires additional engineering work attributable to the generated change. Record the rule in your methodology notes.

Treat rejected work as a real outcome. If the agent writes three alternative implementations and only one is merged, the two discarded attempts still consumed model, review, and developer attention. If you cannot identify rejected work reliably, sample a representative set and use an explicit rejection-rate estimate. Show the confidence or uncertainty beside the result rather than presenting it as a precise invoice fact.

Use the AI agent budget guardrail and P95 calculator when the accepted-change ledger reveals long-tail spending. Averages can hide a few unusually large reviews, context-expansion retries, or failure loops. For scope and staffing assumptions, compare the result with the AI agent development cost estimator. When your estimate and invoice disagree, the AI API invoice reconciliation calculator can help map usage rows back to the workflow.

Common mistakes and limitations

Dividing by pull requests instead of accepted changes. One pull request may receive several automated reviews, contain multiple generated changes, or be closed without merging. Define the unit first, then aggregate.

Counting only provider charges. Provider spend is useful, but it omits human review, CI, rework, and remediation. Arnica’s inspected calculator makes this boundary explicit by describing provider-token spend and excluding engineering time, orchestration, storage, CI, alert routing, and triage. That is a valid scope for a provider budget, not a full cost-per-outcome measure.

Using a vendor average as a guarantee. A dated vendor average can anchor a scenario. It cannot predict your rate for every repository, diff size, model, plan, or review depth. Pricing and product behavior change. Recheck pricing on the date of analysis and preserve the units.

Hiding uncertainty in a single blended rate. Keep the inputs editable. At minimum, show a low, base, and high case for loaded hourly rate, review minutes, acceptance rate, retry count, and remediation reserve.

Treating a rollback reserve as an actual incident bill. A reserve is an estimate for risk not yet observed. Keep it separate from realized remediation cost. Once an incident occurs, replace or supplement the reserve with attributable evidence.

Comparing teams with different quality gates. A team that accepts only fully tested changes may show a higher cost per accepted change than a team that merges quickly and fixes defects later. The metric is meaningful only when the acceptance and rollback rules are comparable.

FAQ

What is the right denominator for AI code review rework cost?

Use accepted or merged changes, not model calls or pull requests. If a merged change is later rolled back, either remove it from the accepted denominator or add a rollback penalty according to a rule documented before measurement. Keep an attempt-level metric as a companion, but do not call it cost per accepted change.

Should human review time be included in AI code review cost?

Yes, when the question is the cost of delivering an accepted change. Include review and approval minutes at a stated loaded hourly rate. If you are building a narrow provider-spend budget, you can exclude people, but label the result “provider cost per accepted change” and do not present it as total engineering cost.

How do I price a rejected AI-generated change?

Assign the rejected attempt the model, review, CI, and any rework or investigation cost it consumed. It stays in the numerator and does not enter the accepted denominator. If rejection data is incomplete, estimate the rate from a dated sample and show the sample size and uncertainty.

Are retries part of rework cost?

Usually, yes. Separate automatic model retries, human-requested follow-up calls, CI reruns, and full engineering rewrites. A retry that changes only the prompt has a different cost from a rewrite that consumes an engineer’s hour. Keeping categories separate makes optimization decisions more reliable.

How often should the ledger be updated?

Reconcile usage and outcomes monthly for finance reporting, with a weekly operational view for anomalies. Recheck rates when a model, review product, plan, CI runner, or workflow policy changes. Preserve the assumptions and checked date so a later month can be compared fairly.

Can this method prove that AI coding saves money?

No. It calculates an attributable unit cost. A savings or ROI claim also needs a counterfactual, such as the cost and cycle time of a comparable human-authored change at the same quality standard. This guide does not assume that a lower model bill, a faster merge, or a higher acceptance rate automatically creates business value.