In this note
A cheap model can sit inside an expensive workflow. Someone still checks the source, reviews the result, deals with exceptions, and fixes the integration when it changes. The model bill can look excellent while the service loses money.
I’d agree on a budget for the whole service before choosing the model. How much work will people use it for? How often will the result pass review? What benefit would justify the people, tools, and maintenance it needs?
We'll use a hypothetical invoice-exception service. Its benefit estimate puts a price on hours the team might free up. That is a planning estimate, not reduced payroll or customer evidence. We haven't priced possible harm or error losses, so the calculation cannot establish the full business value.
Work backward from the accepted result
Suppose 500 invoice exceptions a month fit the proposed service. The team expects to use it for 60%, or 300 cases. Assume 80% finish with both an approved result and confirmation from the source system, giving 240 independently accepted results. Count that completed path, not drafts the model marks complete.
Each accepted result is expected to free six minutes, after allowing for review and correction. That adds up to 24 hours. At a reviewer cost of $55 an hour, including employment costs, those hours are worth $1,320 for planning. Payroll may stay the same. The owner still needs to show what useful work those hours will support or which paid expense they will remove.
- Reached cases
- 500 × 60%300
- Accepted results
- 300 × 80%240
- Capacity planning value
- 240 × 6/60 × $55$1,320
- Allocated and variable cost
- $850 + 300 × $0.50$1,000
- Conditional balance
- $1,320 − $1,000$320
All figures use the same illustrative dollar currency and month. The $850 covers allocated delivery, assurance, support, and operation costs. The $0.50 covers model, tool, and compute use for each of the 300 cases, including the 60 rejected results. Failed work still costs money.
Reserve some room before setting the ceiling
Suppose the owner wants at least $200 left from the $1,320 planning value. That sets a monthly service ceiling of $1,120. The $1,000 forecast sits $120 below it. The $200 is a choice for this example, not a recommended return or insurance against losses we haven't estimated.
The ceiling works out to about $4.67 per accepted result, including the whole service. After the $850 allocation, only $270 remains for usage across 300 cases: $0.90 per case. Giving every model call a $4.67 budget would spend money already needed for people and other costs.
The balance depends on useful hours and complete costs. The owner still needs to check the benefit and possible losses. Until then, use the ceiling to limit an investigation, not to approve production on its own.
Change one assumption at a time
Change one input at a time to see how easily the $320 balance disappears. Lower use saves some usage cost, but the $850 allocation stays. More rejected results reduce the benefit without refunding what you spent producing them.
| Change from the original forecast | Conditional balance and cause |
|---|---|
| Reach falls from 60% to 40% | −$70: 160 accepted results produce $880 of capacity value; cost is $950 |
| Acceptance falls from 80% to 60% | −$10: 180 accepted results produce $990; cost remains $1,000 |
| Review takes two extra minutes per accepted result | −$120: net time falls from six to four minutes; value falls to $880 |
| Support costs $350 more that month | −$30: capacity value stays $1,320; full cost rises to $1,350 |
The extra-review row reduces the time saved from six minutes to four. Don't also charge those same two minutes as another labor cost. Count any additional work on rejected cases or recovery too, but decide where it belongs in the calculation so you subtract it once.
These rows change one assumption each. In practice, use can fall while support costs rise. Test a plausible combination next. To replace a guess with evidence, time a review session or watch whether people can find and use the service. Another model benchmark won't answer either question.
Price the months after the demonstration
Break down the $850 before trusting it. In this example it contains $300 of delivery cost, $100 for assurance, $250 for support, and $200 for operation. The delivery row spreads a $3,600 build over 12 months. That helps compare monthly costs; it doesn't reduce the bill you pay upfront.
If the owner pays the full $3,600 build bill in month one, plus $550 of other fixed costs and $150 of usage, that month's cash payment is $4,300. The allocated monthly cost is still $1,000. Keep these two views separate: adding both the build payment and its monthly share would count delivery twice.
Now suppose a later month needs $200 more support, $300 to handle a dependency change, and $150 for recovery. That adds $650. Monthly cost rises to $1,650 against the same $1,320 planning value, leaving a $330 shortfall. Say which costs recur and which belong only to that month before multiplying by twelve.
Assign the maintenance work and its budget before rollout. Even a cheaper model takes time to test and integrate. Revisit costs when the service or its assumptions change.
Set run limits and a service limit
Set limits on each run's calls, retries, time, and spend. Then check the monthly service budget, including people and fixed costs. A limit on one request won't stop a service from losing money across thousands of requests.
Stop a run at its limit and use the agreed fallback. If the whole service exceeds its ceiling, the owner can reduce intake, remove unnecessary work, try a cheaper approach, or pause expansion. Continue supporting cases already in progress. A budget alert doesn't make those obligations disappear.
Keep access checks, source checks, approval, and recovery in the budget. Look for duplicate input, needless explanations, or work that can wait for a batch. After changing the design, check quality and reviewer workload on the same cases.
Agree on the next cost test
Take the worksheet to the business owner. Agree what counts as an accepted result, list all costs for the period, and test the assumption most likely to erase the margin. Leave unproven benefits and unknown losses visible. Fund a small investigation if that's all the evidence supports; decide about rollout after it.