Figures on this page were verified 31 August 2026 against the providers' own documentation. Pricing, context windows and rate limits change without notice, so confirm any number against the provider before you rely on it. Tell us if something here is out of date.
A spending limit is a circuit breaker, not a budget. When it trips your API stops serving traffic, which means the limit protects you from a runaway bill by causing an outage instead. Set it well above expected spend, and put an alert far below it that gives a human time to act.
What happens when a limit is reached
Requests start failing with a quota error rather than queueing or degrading. On OpenAI that is a 429 carrying insufficient_quota; the status looks like an ordinary rate limit, so a naive retry handler will loop against a wall that will never come down. That failure mode is covered in full in 429 insufficient_quota.
The practical consequence: a limit set at your expected monthly spend will trip during your best week. Set it at a multiple of expected spend, so it only catches genuine runaways such as a retry loop or a prompt that accidentally grew tenfold.
Three thresholds, not one
| Threshold | Set at | Action |
|---|---|---|
| Notice | ~50% of expected monthly spend | Log it; no one is woken |
| Alert | ~80% | Page a human while there is still time |
| Hard limit | 2-3x expected | Stop everything; genuine emergency |
The gap between alert and hard limit is the point. It is the window in which somebody can look at a dashboard and decide whether this is real growth or a bug, rather than discovering both at once through a production outage.
Alert on balance, not on errors
Waiting for quota errors means alerting after the outage has begun. Poll usage on a schedule and compare against your own forecast.
def check_budget(spent_this_month: float, monthly_budget: float):
ratio = spent_this_month / monthly_budget
if ratio >= 0.80:
page("LLM spend at %.0f%% of budget" % (ratio * 100))
elif ratio >= 0.50:
log.warning("LLM spend at %.0f%% of budget", ratio * 100)
# Burn rate matters more than the total on any given day
day = date.today().day
projected = spent_this_month / day * 30
if projected > monthly_budget:
log.warning("Projected %.0f against budget %.0f", projected, monthly_budget)Burn rate is the signal that matters. Being at 40% of budget is fine on day 20 and alarming on day 5, and only the projection distinguishes them.
Cap spend in your own code too
Provider limits are account-wide and blunt. Your own limits can be per-feature and can degrade rather than fail.
- Cap
max_tokensper endpoint. The single most effective control, because output costs several times more than input. - Cap retries. An unbounded retry loop is the classic cause of a bill that arrives without a traffic increase to explain it.
- Rate-limit per user. One automated client should not be able to consume a month of budget in an afternoon.
- Degrade before you fail. Fall back to a cheaper model or a cached answer when spend crosses a threshold, so users keep getting something.
Set the number from evidence
Guessing a limit produces one that is either useless or dangerous. Price your actual token volumes in the API cost calculator, then set the hard limit at two or three times that figure. If the number looks higher than expected, what actually drives an LLM bill covers where it usually goes, and prompt caching is normally the fastest way to bring it down.
Frequently asked questions
What happens when a hard spend limit is reached?
Your API stops serving. Requests fail with a quota error rather than queueing, so the limit protects you from a runaway bill by causing an outage instead. Set it at two or three times expected spend, not at your budget.
What should I alert on?
Burn rate, not errors. Waiting for quota errors means alerting after the outage has started. Being at 40% of budget is fine on day 20 and alarming on day 5, and only a projection distinguishes them.
What can I cap in my own code?
max_tokens per endpoint, which is the single most effective control because output costs several times more than input; retry counts, since unbounded loops cause bills with no traffic increase to explain them; and per-user rate limits.
