Research-backed calculator guide
OpenAI API Usage Tiers and Approved Limits: Budget Control vs Capacity Control
Understand OpenAI API approved monthly usage limits, usage tiers, rate limits, spend alerts, hard caps, prepaid credits, and the right way to calculate a safe budget control.
Quick answer
An OpenAI API approved usage limit is an OpenAI-assigned monthly ceiling for an organization. It is tied to the organization’s usage tier and describes how much monthly API usage OpenAI will approve. It is not the same thing as a budget that you choose, and it is not the same thing as requests-per-minute or tokens-per-minute capacity. OpenAI’s rate-limit guide explicitly separates the approved monthly usage limit from spend limits that an organization or project can configure. [1]
A spend limit is your control surface. A spend alert notifies you while traffic continues. An enforced hard spend limit is intended to stop affected requests after tracked spend reaches the configured organization or project amount; the resulting API error identifies the scope. [2] The safe operating rule is therefore: treat the approved usage limit as the provider ceiling, use rate limits for throughput planning, use prepaid balance as a funding constraint, and set a lower hard spend limit when a workload must not exceed a budget.
As observed on 2026-11-02, the current OpenAI documentation lists Free, Build, Launch, and Grow usage tiers, with the paid thresholds and monthly limits shown below. These values are dated product observations, not a promise that the dashboard or tier schedule will remain unchanged. Check your organization’s Limits page before relying on them.
The limits are different control surfaces
The phrase “OpenAI usage limit” is ambiguous because several controls can stop or slow an API request. Start by naming the control before changing it.
Approved monthly usage limit. OpenAI assigns this limit at the organization level based on the usage tier. It is a provider-side ceiling. If the organization reaches it, a request can fail with an organization_usage_limit_exceeded code. You do not make this ceiling equivalent to a project budget by typing a number into a project setting; an increase is an approved-limit request or a tier-related change, subject to OpenAI’s current process. [1] [3]
Request and token rate limits. These govern how quickly requests can be made. Common meters include requests per minute (RPM), requests per day (RPD), tokens per minute (TPM), and tokens per day (TPD). They can be reached even when the organization has plenty of monthly budget headroom. A temporary throughput limit normally calls for pacing, batching, or backoff rather than a billing change. [1]
Spend alert. An alert is a notification threshold. It is useful for early warning but does not enforce a cap. A team that wants an alert at 80% of its budget should not mistake that notification for a shutdown mechanism. [2]
Hard spend limit. This is a configurable monthly cap at organization or project scope. When enforced and reached, affected traffic can receive a 429 response with organization_spend_limit_exceeded or project_spend_limit_exceeded. OpenAI notes that enforcement is not instantaneous, so recorded spend may slightly exceed the configured amount while the limit state propagates. [2]
Prepaid credit balance. A credit balance is funding, not a tier ceiling. If prepaid credits are exhausted, the error code is credit_balance_exhausted; adding credits addresses that condition. A higher approved usage limit or a higher project hard cap does not replenish an empty balance. [3]
This separation matters operationally. “Raise the usage limit” is the wrong response to a project hard cap. “Retry with exponential backoff” is the wrong response to exhausted prepaid credits. “Set an alert” is not enough when a runaway batch must be stopped.
What usage tiers tell you
The rate-limits guide currently lists these organization-level monthly approved usage ceilings and purchase thresholds. The “total credit purchases” column is a qualification threshold shown by OpenAI; it is not the amount you should assume will be consumed by your application during the month.
| Tier | Qualification shown in the guide | Approved monthly usage limit | What it controls | What it does not control |
|---|---|---|---|---|
| Free | Allowed geography | $100/month | Organization’s approved monthly ceiling | A project-specific budget or RPM/TPM |
| Build | $5 in total credit purchases | $500/month | Organization’s approved monthly ceiling | A guarantee that $500 will be spent or a hard stop at exactly $500 |
| Launch | $100 in total credit purchases | $5,000/month | Organization’s approved monthly ceiling | Project isolation or request pacing |
| Grow | $500 in total credit purchases | $200,000/month | Organization’s approved monthly ceiling | A substitute for alerts, hard caps, or balance management |
The table is useful for capacity planning, but it is not a budget recommendation. A Grow organization could still choose a $2,000 project hard spend limit for an unattended workflow. Conversely, a Build organization cannot assume that setting a $2,000 project limit makes $2,000 of monthly use approved; the OpenAI-assigned organization ceiling can remain the smaller boundary.
The same guide also shows that higher usage tiers generally provide higher rate limits, but monthly approval and throughput are still separate dimensions. A workload can be under its monthly spend budget and still receive a rate-limit response because it sends too many requests or tokens in a short window. [1]
For a pricing estimate based on input tokens, output tokens, model mix, and call volume, use the OpenAI API pricing calculator. For a provider-neutral view of monthly model assumptions, see the LLM cost calculator, and use the AI token cost calculator when your uncertainty is primarily token volume rather than control scope.
Worked cost example: choose the smallest applicable ceiling
Suppose a team operates one production project and wants a predictable monthly stop for an automated document workflow. These are planning assumptions, not a vendor quote:
- The organization is on the Build tier, so the dated approved monthly ceiling is assumed to be $500.
- The project hard spend limit is configured at $200 and enforcement is enabled.
- The organization hard spend limit is configured at $300 and enforcement is enabled.
- A spend alert is configured at $160, which is an alert only.
- Forecast usage for the month is $187.50, calculated from the team’s token and request assumptions in its own cost model.
- The project is the only workload included in this example; other projects could still contribute to an organization-level limit.
| Step | Assumption or input | Calculation | Output |
|---|---|---|---|
| 1. Approved capacity check | Build ceiling = $500/month | Provider ceiling = $500 | $500 |
| 2. Organization control | Organization hard limit = $300 | Applicable org cap = $300 | $300 |
| 3. Project control | Project hard limit = $200 | Applicable project cap = $200 | $200 |
| 4. Alert threshold | Alert = $160 | Notification only; no subtraction from caps | $160 alert point |
| 5. Forecast remaining under project cap | Forecast = $187.50; project cap = $200 | $200 − $187.50 | $12.50 headroom |
| 6. Forecast remaining under org cap | Forecast = $187.50; org cap = $300 | $300 − $187.50 | $112.50 headroom |
| 7. Effective planned stop | Smallest of $500, $300, and $200 | min($500, $300, $200) | $200 project cap |
The effective planned stop is $200 because the project limit is the smallest applicable hard cap. The $500 approved usage limit is not a reason to raise the project limit. It only tells the team that the provider-side monthly ceiling is not the first boundary in this scenario. The $300 organization cap remains relevant because all projects share it at organization scope, while the project cap only covers traffic billed to that project. [2]
At a forecast of $187.50, the project has $12.50 of nominal headroom. That is not a guarantee of exactly $12.50 of additional service. The forecast may be wrong, usage can be recorded with some delay, and hard-limit enforcement is not instantaneous. A responsible plan leaves an operational buffer instead of scheduling work up to the last cent. For example, the team might pause new batch work when its internal ledger reaches $175, review the alert at $160, and reserve the remaining amount for in-flight requests and reconciliation. Those internal thresholds are planning choices, not OpenAI settings.
If the project returns project_spend_limit_exceeded, inspect the project’s current usage and its configured limit. If the organization returns organization_spend_limit_exceeded, changing only the project limit will not resolve the organization boundary. If the response says organization_usage_limit_exceeded, the issue is the OpenAI-assigned monthly ceiling. If it says credit_balance_exhausted, the funding balance needs attention. [2] [3]
A practical diagnosis workflow
First, record the HTTP status and error.code. A broad insufficient_quota error type is not specific enough to decide what to change; the code carries the useful distinction among approved usage, organization spend, project spend, and credit balance. [3]
Second, identify scope. Organization limits cover traffic across projects. Project limits apply to traffic billed to that project. A request can be subject to both, so the effective hard boundary is the lower applicable cap. This is why an organization-wide budget review should aggregate projects rather than looking at one project’s dashboard in isolation.
Third, check whether the problem is money or throughput. If the code indicates a request or token rate limit, inspect RPM, TPM, response headers, and recent traffic shape. Reduce concurrency, queue work, batch compatible tasks, or honor Retry-After when supplied. Do not keep retrying a billing or quota error that requires a setting or credit change; repeated retries can add load without restoring access. [1] [3]
Fourth, compare current usage with both the approved ceiling and configured spend controls. The comparison should include a timestamp, timezone, project identifier, model mix, and whether the figure is provider-reported usage or an internal estimate. Your estimate is useful for planning, but the dashboard and response codes are the evidence for the provider’s current state.
Fifth, choose the least disruptive fix. If an alert fired early, investigate the change in volume or model mix. If a hard project cap was reached and the spend is authorized, raise it only after reviewing the workload. If the approved usage ceiling is the boundary, request a higher approved limit rather than pretending a project setting can override it. If credits are exhausted, replenish the balance and confirm that the new balance is visible before restarting a queue.
How to set a safer budget control
Start with an expected monthly cost rather than with the maximum OpenAI tier. Estimate calls by workload, input and output tokens, model price, retries, tool calls, and batch or background jobs. Then add a documented variance reserve for volume spikes and estimation error. The result is an internal planning budget, not a statement of what OpenAI will approve.
Set the project hard limit below the organization hard limit when you need blast-radius control for one service. Set the organization hard limit at a level that protects the total account, including projects owned by other teams. Add alerts below both thresholds so a person has time to investigate. Keep an internal stop threshold below the vendor hard cap to account for propagation and in-flight work.
Review limits after any change in model, prompt length, retry policy, concurrency, or customer traffic. A token estimate that was safe for a short prompt can become unsafe when context windows grow. Likewise, a higher usage tier can remove a capacity boundary without improving unit economics. The correct question is not “How high is my tier?” but “Which boundary will this workload reach first, and how will I know before it does?”
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
FAQ
Is the OpenAI approved usage limit the same as a spend limit?
No. The approved usage limit is an OpenAI-assigned monthly organization ceiling based on the usage tier. A spend limit is a configurable organization or project control. A hard spend limit can be enforced to stop affected traffic, while an alert only sends a notification. [1] [2]
Does a higher usage tier automatically increase my project budget?
No. A higher tier can increase the organization’s approved monthly ceiling and generally provide higher rate limits, but it does not set a project hard spend limit for you. Configure project controls separately, and remember that the organization ceiling can still be the smaller boundary. [1]
Why did I receive a 429 when my monthly budget was not exhausted?
A 429 can represent different conditions. You may have reached a project or organization hard spend limit, or you may have hit a temporary request or token rate limit. Inspect error.code and relevant headers before deciding whether to change billing controls or throttle traffic. [1] [2] [3]
Does a spend alert stop OpenAI API requests?
No. The documented behavior of a spend alert is notification while API traffic continues. If you need an enforceable monthly boundary, configure an enforced hard spend limit and still keep a lower internal operational threshold because enforcement and recorded spend are not instantaneous. [2]
What happens when prepaid credits run out?
The troubleshooting guidance identifies this as credit_balance_exhausted. Adding credits addresses the balance condition. Raising a usage tier or changing a project hard cap does not, by itself, add prepaid funds. [3]
Should I use rate limits as my cost-control mechanism?
No. Rate limits control speed, such as requests or tokens per minute. They can reduce burst risk, but they are not a monthly budget. Use rate-limit handling for throughput and spend alerts or hard caps for financial control. [1]
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.