If you run a brand, you're buying AI tools now (for content, for research, for measurement) and you've probably noticed that the pricing feels like a guess. An uncomfortable fact from the building side: it often is. The AI industry's least-discussed problem is that most AI products do not know what a single run costs them. Every AI feature fires paid calls to expensive models, the bills arrive as monthly lump sums, and the per-run arithmetic never happens. When a vendor doesn't know their costs, somebody is eating the difference, usually you, usually invisibly.
This piece is about the machinery that fixes that, told through ours, because the shape of it hands you a question to take to every AI vendor you evaluate.
Start here: there's a gatekeeper inside our product whose whole job is to tell our own product no.
Nothing expensive gets to run without getting past it.
And when it refuses, it says why and when to come back: the refusal carries the number of seconds until the budget rolls over. There's even a small kindness buried in the checking order. The note we wrote beside it: "Daily is checked before monthly so users see the tighter feedback ('today's budget reached') first." A no with a reason and a timestamp. That's the whole philosophy, and everything else in this piece is that sentence, applied.
Reserve pessimistically, settle truthfully
Every expensive operation starts by reserving its worst case: not its average, its ceiling.
Then the paid request actually fires.
If it succeeds, the operation settles at the actual cost and the difference goes back to the budget.
If it fails, the whole reservation comes back.
Our free public audit reserves a ceiling we labeled a "generous worst-case," and a typical run settles at roughly half of it.
Which means the question "can we afford this?" gets answered before the money leaves the building, against the worst case, never reconstructed afterward from an invoice. If you've ever managed trade spend, you know this discipline by feel: you commit budget when the program is approved, not when the deduction shows up.
The humblest run we offer is free: a stranger types a URL into our visibility grader. Before anything is reserved, the grader checks whether it already answered this exact question for this exact person recently, because a repeat visit should cost nothing. Then it reserves the worst case, sends the question to the answer engines all at once, and waits.
It settles at what the run cost and the rest goes back.
It settles at the cost of the ones that did and marks the result as partial rather than pretending.
The entire reservation comes back and the visitor gets an error instead of a bill.
The refusal travels all the way out to the visitor's browser as a plain "try again after," with the seconds attached, the same number the gatekeeper computed.
The interesting decisions are in the failure paths, because that's where metering systems usually lie. What if a job dies between reserving and settling (a crash that spent nothing but still holds a reservation)? The money stays charged against the budget until the day rolls over, and we wrote down that this is a choice: "This is intentional — fail-safe favors over-counting briefly over the possibility of unbounded spend during a process crash." We would rather briefly believe we spent money we didn't than ever spend money we didn't count.
The refund path gets the same suspicion. When a run fails and its reservation is handed back, the handing-back can itself fail, and when it does we record it loudly, because a quiet failure there would hold the money until the reservation expired and drift the ceiling lower with no signal. A metering system has to count its own mistakes.
And what if the budget system itself is unreachable? In most metering setups, the meter is an observer, and when observers fail, the spending continues, unmetered, quietly. Ours is not an observer. The note on that case is a line I'd put on a poster: "Fail closed — KV unavailability blocks all paid AI calls." KV is the store that keeps the tallies; if the system that counts the money can't be reached, nothing spends.
The product gets slower before the bill gets weirder.
One more, because AI spend has a signature failure mode you should know about as a buyer: it multiplies. A single feature fans out into dozens of simultaneous requests, each individually under the cap, collectively way past it. Naive budget checks have a gap between "check the balance" and "spend the money," and fan-outs live in exactly that gap. So the check and the reservation happen as one indivisible step (the note at the top of that part of the system says "Atomicity is non-negotiable."), and the whole thing is built and reviewed the way you'd build the part of a product that handles money, because that's what it is.
Budgets with names on them
One ceiling for everything would still leave you blind, because a spike is only diagnosable if you know which feature spiked. So there isn't one budget; there are more than twenty named ones across the suite. Every expensive feature (the DNA inference, the competitor crawl, the keyword briefs, the reputation synthesis, the discovery sweeps) meters under its own name, and the same phrase recurs through the list like a chorus: each budget exists for "separate budget accounting + a clean kill switch." If one feature misbehaves, you can see it, cap it, or turn it off, without touching anything else.
One pair shows why the names matter. Our reputation feature has two halves.
| The synthesis you ask for | The pass that runs on its own | |
|---|---|---|
| What it is | A synthesis a customer asks for by pressing a button. | An automatic pass that fires on its own after every audit and scores the tone of each mention. |
| What starts it | A customer presses a button. | It runs whether or not anyone asked. |
| Why it has its own budget | It could share one with the pass; it does not. | A thing that runs on its own needs its own switch. |
If that pass ever ran hot, we could switch it off without touching the button. The same thinking puts the ceiling third in line on our discovery feature, behind a per-workspace rate limit and a day-long memory of recent answers, so the reservation is the last brake, not the only one.
My favorite detail is the humblest one. Our free visibility grader, the give-the-diagnosis-away front door, runs under a dedicated sub-budget that is a small slice of the platform's daily ceiling, so a burst of anonymous free traffic can never drain the day's budget out from under paying customers. And that sub-budget is clamped: even a mistyped setting can't widen it past the platform ceiling, because, as the note beside it says, a bad setting that widened it "would defeat the carve-out." Somebody asked what happens if the safety setting itself is wrong, and then made the wrong setting unable to matter.
The free door has a perimeter, too, and it runs before the budget is even consulted. Every visitor to a free tool proves they're human before we do paid work, and if that check itself breaks, the answer is no. A submitted address is inspected before anything is fetched; a private or malformed one is rejected. Per-person rate limits apply, and when the system enforcing them can't be reached, they refuse rather than admit. And a pass to use a free tool works exactly once. Each check says no before the next one runs, which means the budget only ever meets requests that have already earned the right to spend it.
That's what I mean by metered honesty: a hierarchy of named budgets where the free tier structurally cannot cannibalize the paid tier, enforced at the moment of spend, robust to our own fat fingers.
The receipts, to the cent
When a reservation settles, the same step can carry its attribution (which product, which feature, which brand) into a suite-wide cost ledger, so the dollar that just left is immediately answerable to whose dollar it was. We can itemize what a single customer report cost to compute.
While writing the piece this one grew from, we queried that ledger, young as it is. In its first two weeks of life, nearly 97 cents of every metered dollar arrived through the reservation step, each entry stamped with the reservation that authorized it before it fired. I can quote that to the cent, which is rather the point: nearly every dollar of AI spend in the suite asked permission first.
A vendor's internal bookkeeping matters to you, the buyer, because cost attribution is the precondition for every honest sentence a vendor says to you about pricing. A vendor who knows a run's worst case can cap it. A vendor who knows a run's actual cost can price it. A vendor who knows neither is guessing, and their pricing is a bet that the average customer subsidizes the chaotic one — which works right up until you're the chaotic one, or you're the one subsidizing.
The question to take to your vendors
This machinery isn't free. Every new feature pays a plumbing tax: pick a budget, estimate a worst case, connect the loop, tune the caps. Some caps start as honest placeholders (one note says outright to tune it "after the first metered run, not here"), because an honest guess beats a confident one. And a refusal at the ceiling is real friction for a real user; a customer who hits a cap is having a worse day than one who doesn't.
It also isn't a blanket. Not every surface fails closed; one of our demo rate limiters is documented as fail-open, and we let it be, because it sits inside a spend ceiling that bounds the worst it can do. The rule is scoped on purpose: the surfaces that spend your money refuse when unsure, and everything else is judged on its own.
But the alternative just hides the same costs somewhere worse. An AI product without ceilings doesn't have no limit — it has an undeclared one: the invoice that makes someone gasp, the margin quietly bleeding out, the free tier that dies without warning because nobody could see which feature was eating it.
The refusal at the ceiling is the surprise invoice moved earlier in time, given a reason, and handed to the party who can actually do something about it.
So, one question for your AI vendors: what does one run of your product cost you? Not pricing. Cost. Worst case and actual. A vendor with this machinery answers immediately, because their own product refuses to fire without knowing. A vendor without it will talk about tokens for a while, and now you know what their pricing is: a guess, with you as the buffer.
Every AI product has a spend ceiling somewhere. The only question is whether it's written in the code or discovered on your invoice.
See where the noes happen
The perimeter that runs before the budget is ever consulted, laid out check by check.
See how the guards workWhy reserve the worst case instead of an average?
Because the question "can we afford this?" has to be answered before the money leaves the building, against the ceiling, never reconstructed afterward from an invoice. A typical run settles at roughly half the ceiling it reserved, and the difference goes straight back to the budget.
What does hitting a cap look like from the outside?
A refusal that says why and when to come back. It carries the number of seconds until the budget rolls over, and on a free tool that refusal travels all the way out to the visitor’s browser as a plain "try again after," with the seconds attached.
Can a rush of free traffic drain the budget out from under paying customers?
No. The free visibility grader runs under a dedicated sub-budget that is a small slice of the platform’s daily ceiling, and that sub-budget is clamped, so even a mistyped setting cannot widen it past the platform ceiling.
Does everything fail closed?
No, and the rule is scoped on purpose. The surfaces that spend money refuse when they are unsure: if the system that counts the money cannot be reached, nothing spends. One demo rate limiter is documented as fail-open, and it stays that way because it sits inside a spend ceiling that bounds the worst it can do.