OpenAI spend limits — hard, soft, and what they miss
Last verified
Set a hard limit. Turn off auto-recharge. Do both today. Together they bound your worst case, which nothing else on this page does.
Then read the gaps, because a spend limit is a backstop rather than a monitor, and people routinely mistake it for one.
Soft vs hard
Soft limit (spend alert). Notifies you when tracked spend passes a threshold. Changes nothing about your traffic. It is a smoke alarm.
Hard limit. Stops API traffic once tracked spend reaches the configured amount. Requests start failing. It is a circuit breaker.
They work together — alerts stay active when a hard limit is configured, which is the sensible setup: warned at 50%, stopped at 100%.
Both are configured in the billing section of platform.openai.com, at organisation level and optionally per project.
The four gaps
1. Limits are per organisation, not per key
A leaked key draws from the same budget as your production traffic. It cannot be capped separately, which means the limit that protects you from an attacker is the same one that will stop your product.
Project-level limits help — put risky or experimental work in its own project — but there is no per-key cap.
2. Enforcement lags usage
Limits act on _tracked_ spend, and tracking is not instantaneous. A sharp enough spike can overshoot before enforcement engages. Set the limit meaningfully below the number that would actually hurt, rather than exactly at it.
3. Auto-recharge can defeat the point
This is the big one. With auto-recharge on, a drained prepaid balance tops itself up from your card and traffic continues. You configured a cap; the billing system routes around it.
If you do one thing from this page, make it this one. How to turn off OpenAI auto-recharge.
4. Hitting the limit is an outage
When a hard limit trips, your product stops working. Requests fail. For a side project that is the correct trade. For a production service it is a decision you should make deliberately, with the number set high enough that only a genuine emergency reaches it — and with alerts set low enough that you hear about it first.
A configuration that works
For a solo developer or side project:
- Hard limit: what you'd be genuinely annoyed to lose. $50–100 for most personal projects.
- Alerts: 50% and 90%.
- Auto-recharge: off.
- Payment method: remove anything you don't need on file.
For a small team in production:
- Hard limit: roughly 3× a normal month, set at the organisation level. High enough that only an emergency reaches it.
- Project limits: a lower cap on experimental and prototype projects, so a stray script can't consume the production budget.
- Alerts: 50%, 75%, 90%.
- Auto-recharge: off, or on with a low top-up amount and someone watching.
- Plus a daily spend review, because a monthly limit does nothing about a bad Tuesday until it's a bad month.
What a limit does not do
It does not tell you _why_. A limit trips at a number — it cannot distinguish a launch from a runaway loop from a stolen key, and by the time it trips, the money is spent.
The gap between "something changed" and "the cap engaged" is where the loss actually happens. Closing it needs something looking at daily spend and comparing it to normal — which is what spend alerts and TKN are for.
Use both. The limit bounds your worst case; the daily number means you rarely get near it.
Other providers
- Anthropic: organisation-level limits and credit configuration — how to cap Anthropic API spending
- Google Gemini: Cloud Billing budgets with threshold alerts, which notify rather than stop by default — Gemini budget alerts
- xAI: team-scoped billing controls in the console