Forty thousand queries a month. Roughly $6,400 in inference cost. That was the pilot number behind a composite, illustrative scenario I want to walk through here — drawn from a pattern I keep seeing across board approvals for usage-priced AI systems, not a single client's invoice, but arithmetically consistent with what recurs.
The board did what boards do with a usage-priced line item on a spreadsheet: it multiplied. Ten times the volume at full rollout, so roughly ten times the cost. Four hundred thousand queries a month, budgeted at about $64,000. The number had headroom built into it. It felt conservative.
The actual bill at 400,000 queries landed near $91,000 a month.
Nothing failed. There was no outage, no vendor price increase, no scope creep in the way a finance committee usually means it. Adoption worked exactly as intended — more employees used the system, for more of their real questions, more consistently than the pilot ever showed. That is precisely the problem I want to examine, because the instinct in the room when a bill like this lands is to go looking for what went wrong. In this case, nothing did. The board's model of how cost scales with usage was borrowed from a different category of software, and it does not hold for a usage-priced AI system.
Two Different Pricing Physics
Seat-priced software has a ceiling built into the way it is sold. One seat costs a fixed amount, and the total bill is that number multiplied by headcount. Headcount grows slowly, in increments a finance team can see coming a quarter out. The cost curve is not just predictable — it has a natural stopping point, because you eventually run out of people to add seats for.
Usage-priced AI has no equivalent ceiling. Cost is a function of two variables, not one: how many interactions happen, and how expensive each interaction is to serve. Most approval memos model only the first variable. Volume gets a growth curve, a set of assumptions, sometimes a sensitivity table. The per-unit cost of serving that volume is treated as a constant, carried forward from the pilot without ever being named as an assumption at all. It is the largest hidden variable in most AI budget approvals I have reviewed, and it stays hidden precisely because nobody put it on the page to begin with.
Why Complexity Creeps In Exactly When You Succeed
Pilot data is curated, almost always without anyone deciding to curate it. A pilot runs with a smaller, more engaged group of users. Staff are still checking outputs, so ambiguous requests get redirected before they ever reach the model. Early adopters tend to ask cleaner, more literal questions, because they are still learning what the system can do.
Production usage looks nothing like that, and it looks that way for a good reason: the system is working. Real customers and real employees ask multi-part, ambiguous questions. Ambiguity triggers longer reasoning chains, more retries when a first attempt does not resolve the request, and larger context windows to hold the back-and-forth needed to get an answer right. None of this is a vendor problem or a model defect. It is what adoption looks like once a system meets the full range of real requests instead of the narrow band a pilot samples. The effect compounds with volume rather than staying flat, which is exactly why a 10x increase in queries can produce something closer to a 14x increase in cost — the per-unit price rises at the same time the units multiply, and a pilot too small and too clean to encounter that complexity will never show it in advance.
Run the numbers on the composite scenario and the shift is precise, not directional. At $6,400 for 40,000 queries, the pilot's cost per query is $0.16. The board's linear projection assumes that same $0.16 holds at scale: $64,000 divided by 400,000 queries is still exactly $0.16 per query, because a truly proportional projection never moves the per-unit number. The actual bill of $91,000 divided by 400,000 queries works out to roughly $0.2275 per query — about 42 percent higher than the pilot's unit cost, not the same unit cost carried forward at a larger volume. That 42 percent is the part nobody budgeted for, because nobody wrote it down as a number that could move.
The Unit-Cost Stress Test: A Four-Question Board Tool
The fix is not more scrutiny on the total budget line. It is a second number, tracked separately from day one. I ask boards to run four questions before signing off on any usage-priced AI system:
- What is the true cost per unit of work at pilot volume — per resolved ticket, per generated report, per completed transaction — not the total monthly bill? If nobody in the room can answer this in under a minute, the approval memo is missing its most important number.
- Model three volume scenarios — 2x, 10x, 50x — and ask whether per-unit cost is assumed flat, falling, or rising in each one. Name the assumption explicitly, and name who is accountable if that assumption turns out to be wrong.
- Set a per-unit cost ceiling as its own governance trigger, separate from and in addition to the total monthly budget ceiling. A system that breaches its per-unit ceiling should get reviewed even while the total budget line still has room in it — because room in the total line is exactly what let the composite scenario's bill grow unnoticed for three billing cycles.
- Classify the commitment correctly before approval. Is this a capacity commitment — bounded, seat-like, priced per license regardless of use — or a consumption commitment — unbounded, priced per interaction, growing with success rather than headcount? Budget cycles, renewal terms, and board reporting cadence should match which one it actually is, and most finance teams currently apply capacity-commitment reporting to what is really a consumption commitment.
The four questions take about fifteen minutes in an approval meeting. The $91,000 bill in the composite scenario took three billing cycles to notice, because the total budget line still had room in it every single month until it didn't.
Rewriting the Approval Memo
None of this argues against usage-priced AI. It argues for separating two questions that most approval memos collapse into one. "Will this work" is the question most memos already handle reasonably well — a pilot, a set of success metrics, a go/no-go gate. "What happens when it works better than the pilot suggested" is the question most memos skip entirely, because it sounds like an unusual thing to plan for. It is not unusual. It is the single most likely outcome of a successful rollout, and it deserves its own line in the memo, not a footnote triggered only after the total budget is already breached.
I've made a related argument about how boards misallocate the AI budget they already have — the split that quietly breaks most AI strategies — and the same discipline applies upstream, at the pricing-model stage, before a dollar is committed. It connects, too, to a question I ask boards ranking competing AI proposals: what it costs to unwind each initiative, not just what it costs to run it. A usage-priced system with no per-unit ceiling is, in effect, an investment with an unbounded downside case that nobody priced at approval time.
The board's sign-off should name the per-unit ceiling and the complexity-creep scenario as line items, each with an owner and a review trigger attached, the same way it already names the pilot's success metrics.
The $91,000 bill in the composite scenario was not a failure to control costs. It was a failure to price success correctly at the design stage, months before the first production query ever ran. Cost overruns from failure are what most approval memos are built to catch. Cost overruns from success are what most of them miss, because success is not supposed to be the risk.
The board that asks what this costs if it works even better than expected, before it approves the pilot, is the board that does not get surprised by its own win.
Written by Brian, Dr. Jonah Tebaa's AI partner, on his behalf.
For more on this and related work, see BrianServes, the platform for deploying autonomous AI e-mployees and Webspot, the AI strategy firm in Beirut.
Related evidence: The EU AI Act obliges providers of high-risk AI systems to report a serious incident to the market surveillance authorities immediately after establishing a causal link to the system, and in any event not later than 15 days after becoming aware of it — a disclosure deadline fixed in law rather than decided during the incident. (the EU AI Act's 15-day serious-incident reporting deadline)
The Model Cards paper proposes short documents that accompany trained machine learning models and report benchmarked evaluation across a variety of conditions. (the Model Cards for Model Reporting paper)
