Three caps, and what each one counts
Usage-based AI spend makes people nervous for a reason that has nothing to do with the size of the bill: it is the variance rather than the number. A quiet week and a launch week can differ by an order of magnitude, and the first you hear of it is normally the invoice.
Your account carries three caps to answer that, and they are genuinely independent — you can set one, two, all three, or none. Each is unset by default, and an unset cap is treated as no cap at all rather than as a cap of zero.
- A monthly budget, in US dollars. Compared against the cost recorded so far this calendar month.
- A daily token limit. Compared against today's tokens, counting what was sent to the model and what came back, added together.
- A calls-per-minute limit. Compared against the number of AI calls in the trailing sixty seconds — a rolling window, not a clock minute that resets on the hour.
They answer different questions on purpose. The budget is about the month you are having. The token limit is about the day. The per-minute limit is about right now, and it is the only one that will notice an automated visitor hammering your AI chat within the minute it starts happening.
One detail matters for the two longer windows: the month and the day are both counted in UTC, not in your local time. If you are ten hours away from that, your daily token count rolls over in the middle of your afternoon, and your monthly budget starts fresh several hours before or after your own calendar month does. That is worth knowing before you conclude a number looks wrong.
A cap tells you where you are, not where to stop
This is the part to be plain about, because it changes how you should use the feature.
Reaching a cap today does not stop an answer from being generated. The caps are evaluated, and the result is surfaced in three places — the cap strip on the AI usage screen in your dashboard, a dedicated limits resource in the REST API, and a single flag in the account health response — but the path that answers a visitor does not consult them before calling the model.
The policy layer for enforcement exists and is stored alongside the caps: a setting that chooses between a soft response, which records that you went past the cap and lets the answer through, and a hard one, which refuses the call and falls back to a knowledge-base search for the bot and to nothing at all for agent-side assistance. What is not yet in place is the gateway that reads that setting on the way to the model. Until it is, treat the caps as an alarm rather than a brake.
That is less useless than it first sounds, and it is a good deal more useful than an unmonitored account. An alarm you actually read on the day it fires prevents most of the damage a brake would prevent, because AI spend rarely explodes in an hour — it drifts over days after a configuration change nobody connected to cost. But it does mean the cap should be paired with something of yours: a check on the usage screen at a fixed time, or a scheduled call to the limits endpoint from whatever already watches your systems. Our REST API reference documents the resource and the fields it returns.
Where the numbers come from, and when they move
Two of the three caps read from a daily rollup of your usage rather than from raw events. The rollup is what the usage screen charts, so a cap and the chart above it can never disagree — they are the same numbers. The per-minute cap is the exception: a trailing sixty-second count cannot come from a daily grain, so it counts raw call records directly.
The whole result is then cached for thirty seconds per account. That is the reason a reload two seconds after a burst of chats can show the same figure as before: you are being served the cached answer, and it will refresh on its own shortly. Changing a cap through the API clears that cache immediately, so a new limit takes effect on the next read rather than up to half a minute later.
Caps are set through the API rather than through a form in the dashboard. Each cap has three states when you send it: leave the field out and it is unchanged, send it as null and the cap is cleared, send a number and that becomes the cap. The dashboard side is a display — the cap strip appears only once at least one cap exists, which is why an account that has never set one sees no bars rather than three empty ones.
Reaching a cap means at it, not over it
The comparison is greater-than-or-equal. A daily token limit of one hundred thousand is reached at exactly one hundred thousand, not at one hundred thousand and one. The same is true of the budget and the per-minute count.
That is the conventional reading of the word limit, and it is worth stating because the alternative would be quietly worse: a cap you can sit exactly on forever without it ever registering is a cap that fails on the one number a person is most likely to choose.
The usage screen colours each bar by how much of the cap is consumed, moving through amber and into red as you approach it, and the bar stops at full rather than continuing past. So a bar pinned at the end tells you that you are at or past the cap, not how far past. If the distance matters — and for a monthly budget it usually does — read the actual month-to-date figure rather than the bar.
One more consequence of the caps being independent: the account-level exceeded flag is true when any of the three is reached. If you are watching that single flag from a monitoring system, it will not tell you which cap fired. The per-cap detail is in the same response, one level down.
Choosing a number for each one
The three caps suit different failure modes, and setting all three at similar strictness wastes two of them.
The monthly budget is a business number. Set it to the figure at which you would want a conversation rather than the figure you expect to spend, and set it above your worst normal month rather than at your average one — a cap that fires most months is one people learn to ignore.
The daily token limit is a runaway detector. Its value is that it fires within hours rather than at month end, so the number that works is a few times a busy day rather than a headroom-free ceiling. A long prompt, a knowledge base that just tripled in size, or a loop that re-asks the model shows up here first. If you are unsure what a normal day looks like for you, what actually drives AI cost is the better place to start than a guessed number.
The per-minute limit is an abuse detector. A public chat widget attracts automated traffic, and the shape of automated traffic is a rate no human conversation produces. Set it well above your busiest genuine minute; it is not a tuning knob for cost.
If you are on managed billing rather than your own model key, the reply pack you have purchased is already a hard ceiling of a different kind, and the caps sit alongside it as an early-warning layer — managed replies or your own API key explains which of those two positions you are in.
When a cap reads zero
Every one of these checks is deliberately failure-soft. If the usage tables are not present, if a query times out, or if anything else goes wrong, the answer returned is the same shape as no caps configured: nothing exceeded, no limits, no enforcement. The reasoning is sound — a monitoring feature must never be the thing that breaks answering a visitor — but it has a consequence you should know about.
A cap reading zero usage can mean zero usage, or it can mean the reporting behind it did not answer. The two look identical from the outside. The way to tell them apart is to look at the usage screen itself: if the charts and the per-feature table also show nothing for a period you know was busy, the problem is reporting rather than genuine quiet.
The failure path deliberately does not cache its result, so a brief database hiccup does not silently disable the readings for the next thirty seconds — the following request tries again. That is the right trade, and it also means a transient blank usually fixes itself before you finish reading this paragraph.
What to measure
Three things, checked on a schedule you will keep:
- Month-to-date cost against your budget once a week, early enough in the month that the trend still leaves you options.
- Daily tokens after every change to a prompt, a knowledge source or a scope setting — the day after is when a bad assumption is cheapest to correct.
- Whether the exceeded flag has ever been true, which is the cheapest possible thing for an external monitor to watch and the one that requires no judgement to interpret.
And one thing to decide before you need it: what you would actually do if the budget cap fired tomorrow. Narrow where AI answers, hand more conversations to people, or accept the number. Deciding that on a calm day is the whole point of having the cap, and it matters more while reaching one does not stop anything by itself. Measuring whether AI chat is working covers the other half of that decision — what the spend is buying you.
Caps and balances are separate things: a cap observes your spend, while the balance is what actually runs out. What happens after you buy an AI reply pack covers topping the balance back up.