Cost per accepted result: how to count it, and what a ledger cannot say

🧮 The formula

Cost per accepted result is total spend on the task divided by the number of results that passed acceptance. Total spend includes every attempt: the first try, retries, a fallback to another model, work that was rejected, and the time of the person who reviewed it. If you leave out the rejected work, the number looks good and says nothing.

Two things sit on the bottom of the fraction that are easy to confuse. A model call that returned an answer is not an accepted result. A result that passed an automatic check is closer. A result that a person read and signed is the strongest. Say which one you count.

📒 What our ledger shows

Every paid model call in our metered transport writes one row, including retries and fallbacks. Since 2026-09-21 the ledger holds 10,150 rows with a total cost of $16.17. Of those rows, 9,860 have the outcome "ok", 220 were refused before the provider generated anything, and 70 ended in an error.

Dividing the total by the number of "ok" rows gives about $0.0016 per answered call. That figure is real arithmetic and it is not the cost per accepted result. "Ok" here means the provider answered. It says nothing about whether the answer was used.

🧩 What is missing, and where it lives

The bottom of the fraction comes from acceptance records: a check that passed, a judge's verdict, a reviewer's sign-off. In our setup those live beside the task, not in the billing ledger. Joining the two is the work. Until it is done, any figure from the ledger alone is a cost per call.

A second gap is people. A cheap run that needs twenty minutes of review can cost more than an expensive run that needs two. We do not have measured review time in the ledger, so we do not publish a total.

🛠️ Practice: start measuring in an afternoon

1. Pick one repeating task, for example "summarise a ticket" or "draft a release note".
2. For the last two weeks, count the attempts, including retries. Your provider dashboard or ledger has this.
3. Define acceptance in one sentence, and make a script check what it can: format, length, required fields, links that resolve.
4. Count how many results passed. Mark those a person also signed.
5. Divide total spend by passed results. Write the date and the definition next to the number.
6. Put review minutes on the top of the fraction using a flat hourly rate that you state. Show the result with and without review time.
7. Re-measure after you change the model or the prompt, and compare like with like.

✅ Check yourself

• You can state the definition of "accepted" in one sentence and show the script behind it.
• The number changes when you include retries. If it does not, you have probably not counted them.
• You can tell a reader how many results were rejected and what they cost.
• Two runs with different models are compared on the same tasks with the same acceptance check.

🚧 When this does NOT work

• Tiny samples. Ten tasks do not give a stable figure. Report the count next to the number.
• Acceptance that changes. If the check is loosened during the measurement, the result is meaningless. Freeze it first.
• Hidden costs. Subscription plans, shared pools and free tiers do not show a price per call. Mark such figures as unknown. Unknown is not zero.
• Quality you cannot check by script. Tone, judgement and taste need a person, and then the cost of the person dominates.
• Averages. A few expensive failures can hide behind a low average. Show the worst ten as well.

📊 Evidence

➡️ Next

Set limits before you measure with Costs, budgets and limits, and compare unit costs in How much does an AI coding agent cost per task?.

Sources

• Costs, budgets and limits: setting a budget per task.
• How much does an AI coding agent cost per task?: tokens, limits and free starts.
• Agent task receipts: what they prove: evidence per run.
• AI judging: why “it says it is done” is not acceptance: how to decide that a result is accepted.