Chapter 4: Measure what you bought
Connect spend to accepted work. Build a forecast you can defend.
- Write down what counts as accepted for each task class before you count anything.
- Calculate model-only and fully loaded cost per accepted task inside one accounting boundary.
- Run a weekly view that pairs spend with delivery, including median and p90 session cost and unattributed spend.
- Give finance a baseline, a stress case, and a measured improvement, each with its assumptions written next to it.
Connect spend to accepted work
A smaller bill is easy to celebrate. It is harder to notice that the team shipped less, or spent Friday repairing generated code. Your measurement has to catch both, and minware’s framing is the right one: delivery per dollar is the number the board cares about.
Define “accepted” before you count
An accepted task satisfies the intended change and passes your review bar. A pull request that exists is not the same as a task that is done. For a documentation task, acceptance might mean a factual review. For a migration, it might mean validation against production-like data. Write the bar down before you count anything.
Model-only cost per accepted task
= model spend across all attempts / accepted tasks
Fully loaded cost per accepted task
= (model spend + allocated tool fees
+ repair hours × loaded hourly rate) / accepted tasksUse the same accounting boundary for every comparison, and allocate shared fees the same way each time. If no tasks pass, report the spend and zero accepted work. Do not let a dashboard show a reassuring zero-dollar unit cost.
Calculate what the work actually cost
Your pilot spends $240 on model calls across all attempts. Thirty tasks meet the quality bar. Reviewers spend two hours repairing output at an illustrative loaded cost of $60 per hour. What is the fully loaded cost per accepted task?
Choose an answer. You can retry after reading the explanation.
Build a weekly view a team can act on
| Measure | Why it belongs | What to do when it worsens |
|---|---|---|
| Total spend and accepted tasks | Shows the bill beside what was delivered. | Check whether workload or task difficulty changed. |
| Cost per accepted task by task class | Prevents easy tasks from hiding expensive failures. | Inspect failed attempts and repair work in that class. |
| Median and p90 session cost | The median is the middle session. The p90 marks the cost below which 90% of sessions fall. | Read traces from the costly tail. Averages can conceal it. |
| Cycle time and rework rate | Checks whether cheaper output creates slower delivery. | Pause an efficiency change if it moves work onto reviewers. |
| Unattributed spend | Shows what you cannot connect to a team or task. | Fix the missing identity or task mapping before declaring ROI. |
Higher delivery next to higher AI spend is a clue, not proof. Teams differ in workload and staffing, so compare similar work over time and run a controlled pilot when you can. Faros makes the same point about leading indicators: the share of traffic on frontier models should fall as routing matures.
Never turn this view into a ranking of engineers by token usage or raw pull-request count. Uber did, and it ended with a cap.
Stress-test the budget
A forecast should answer “what if” before it pretends to answer “how much.” Nobody, including the provider, knows what a request costs before it returns, which is why the 2026 FinOps Framework asks for a range with stated assumptions rather than a single number.
Start with your active engineers and your observed monthly spend, then change one assumption at a time. The calculator keeps headcount fixed and grows the active share only until everyone is active.
The baseline is consumption spend only. Add fixed subscriptions and infrastructure separately. Set the shock inputs to zero to see today’s envelope, and turn every savings lever off before you estimate an improvement.
For calibration, one major provider’s enterprise data puts the average at $150 to $250 per developer per month. Uber saw $150 to $2,000 before its cap, and Gartner warns of $2,000 to $5,000, with extremes at $20,000.
This is a sensitivity model, not a savings promise. Each lever reduces the remaining spend. Routing and cheaper defaults may overlap: switch one off unless you have measured separate gains. Fixed fees and human time are excluded. Adoption growth is capped at 100% of engineers.
Take three numbers to finance
Save three numbers: a baseline, a stress case, and a measured improvement. Write the assumptions next to each one. Then name the person who will respond if actual spend leaves that range, because finance will ask.
Key terms
- Accepted task
- Work that satisfies the intended change and passes your review bar. A pull request that exists does not qualify.
- Cost per accepted task
- Model spend across all attempts divided by accepted tasks. The fully loaded version adds allocated tool fees and repair hours.
- p90 session cost
- The cost below which ninety percent of sessions fall. It exposes the expensive tail that an average hides.
- Unattributed spend
- Spend you cannot connect to a team or a task. Fix it before declaring a return on investment.
Further reading
- minwareBest practices for AI coding tool cost management
Where delivery per dollar comes from as the number to report.
- Faros AIAI coding cost optimization
Leading indicators to watch as routing matures.
- The RegisterAI coding agents could soon cost more than the developers using them
The Gartner range finance will quote back at you.
- Claude Code docsManage costs
Per-developer calibration figures and the fields to export.
Chapter 5: Remove the waste
Reduce repeated work without teaching the agent less.