Guides / ai usage cap calculator
Setting an AI usage cap that binds the right accounts
Set a usage cap from your 90th-percentile account so it binds the tail and almost nobody else. A cap set at the average binds half your base and protects against nothing. Culpa, a local-first LLM cost, margin, and forecast ledger, reports the spend distribution per customer, so the ceiling comes from measurement rather than instinct.
Why this happens
A usage cap has two failure modes and teams usually hit both. Set it too low and it binds ordinary customers, generating support load and churn from people who were never the problem. Set it too high, or leave it off, and the one runaway account produces an unbounded bill. The right ceiling is a percentile of your own measured distribution, and until that distribution is measured any number chosen is a guess dressed as a policy.
What this usually looks like
- No cap exists at all, so your worst-case monthly bill is unbounded by construction.
- A cap exists but was chosen from a round number rather than from usage data.
- Support handles complaints from customers hitting a limit nobody intended to bind them.
- The heaviest account has never hit the cap, which means the cap isn't doing anything.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Mistakes that cost the most
| Mistake | Why it hurts | Do instead |
|---|---|---|
| Setting the cap from average usage. | On a long-tailed distribution roughly half your customers sit above the average, so it binds broadly. | Set it at the 90th or 95th percentile so it binds the tail and leaves normal usage untouched. |
| Enforcing the cap as a hard stop with no warning. | A silent cut-off reads as an outage to the customer and generates churn rather than a conversation. | Alert on approach, then throttle or meter overage. A cap the customer can see is a pricing signal. |
| Capping requests rather than spend. | Requests vary enormously in cost, so a request cap lets an expensive workload through and blocks a cheap one. | Cap on cost. That's the quantity you're actually trying to bound. |
Run this check tonight
- Plot spend per account for last month and find the 90th and 95th percentiles.
- Check what share of accounts a cap at each level would have bound.
- Confirm your cap is expressed in spend, not request count.
- Check whether an alert fires before the cap rather than at it.
- Compute your unbounded worst case: heaviest account times a plausible growth multiple.
Where a cap binds, at three different levels
Illustrative example
500 accounts on Gemini 2.5 Flash at real rates, $0.30 per million input and $2.50 output. The modelled distribution below is a typical long tail.
A cap at the mean binds a third of your customers to control one. At the 90th percentile it binds a tenth, and the unbounded worst case still sits at $160 for a single account.
Every number, with its confidence and source
| Figure | What it means | Confidence | Source |
|---|---|---|---|
| $3.20 to $160.00 | modelled monthly spend from median to heaviest account across 500 accounts | estimated | Both endpoints at real Gemini 2.5 Flash rates per 1k tokens from the price book, effective 2026-07-02. A range because the distribution is modelled. |
| $21.50 | modelled 90th-percentile monthly account spend, the level a cap should sit at | calculated | (30 x $0.30) + (5 x $2.50) per million, using real Gemini 2.5 Flash rates. Token volumes are modelled. |
What a generic answer can’t know
A provider caps your whole account, not one customer. Per-customer ceilings need a customer identifier on every call and a running spend total against it, both of which live in your application. Culpa keeps them on your infrastructure, where your prompts and responses stay, and counts the calls to run your plan.
Questions founders ask next
Where should an AI usage cap be set?
At your 90th or 95th percentile account, measured over a full month. That binds the tail while leaving ordinary usage untouched, which is the whole point. Anything derived from the average binds far more customers than intended.
Should a cap be a hard stop?
Rarely. A silent cut-off reads as an outage. Alert on approach, then throttle or meter the overage so the customer sees a pricing signal rather than a broken product.
Cap on requests or on spend?
On spend. Requests vary enormously in cost, so a request cap lets an expensive workload through untouched while blocking a cheap one. Spend is the quantity you're actually trying to bound.
On your infrastructure
Culpa runs on your infrastructure. Your prompts and responses never leave it. Culpa counts calls to run your plan, and it fails open, so if it ever breaks your app keeps running.
Free, no card, no account
Run the free Cost Leak Scan
It shows your most expensive conversation before you install anything.
Keep reading
Sources: Anthropic pricing. Last reviewed 2026-08-01. Plain text version.