OpenAI API Usage Tiers: Build, Launch, and Grow
OpenAI simplified paid API usage tiers to Build, Launch, and Grow on October 6. The new labels separate purchase qualification from balance, monthly ceilings, and throughput planning.
OpenAI API usage tiers changed on October 6, 2026: the five paid tiers were replaced by Build, Launch, and Grow. The update concerns API organizations and their capacity planning, not a new ChatGPT subscription. Teams should check the new tier label alongside their available credits, approved monthly usage ceiling, and project controls before increasing traffic. The event was announced in the API changelog; this article was first published on October 8.
OpenAI API usage tiers: Build, Launch, and Grow
Organizations upgrade automatically when total credit purchases reach the documented thresholds. The current usage-tier table lists:
| Paid tier | Total credit purchases | Monthly usage ceiling |
|---|---|---|
| Build | $5 | $500 |
| Launch | $100 | $5,000 |
| Grow | $500 | $200,000 |
The guide also retains a Free row with an allowed-geography requirement and a $100 monthly ceiling. Three paid tiers therefore does not mean that the Free row disappeared. A ceiling is permission to use up to an approved amount, not credit deposited into your account.
For a team updating its operating checklist, the useful change is replacing old numbered labels with the current named tier and recording the relevant organization. Keep the date beside that record. An internal note saying “Tier 3” is now ambiguous unless it identifies the document and date it came from.
The announcement does not supply an old-to-new migration map or confirm the tier shown in every customer’s account. Record what your organization’s Limits page actually displays instead of translating an old label by guesswork.
Separate purchase history from spendable balance
A qualifying purchase and the credits remaining after usage are different accounting facts. OpenAI’s prepaid billing instructions explain that API usage reduces the balance. Purchased credits expire after one year, and the optional monthly automatic-recharge limit controls automatic purchases rather than the use of existing credits. Manual purchases do not count toward that recharge limit.
Consider this original bookkeeping example: a team has purchased $100 in total and used $70, leaving $30. Its purchase-history record remains $100; the credits available for subsequent prepaid usage are $30. Entering $5,000 into a spreadsheet as available credit would overstate the balance dramatically. Keep separate columns for cumulative purchases, current balance, approved monthly ceiling, and the team’s own budget.
The prepaid guide uses “trust tier” when describing maximum credit balance and recharge amount. This article does not equate that terminology with a particular Build, Launch, or Grow label. Check the controls shown for your account before configuring automatic purchases.
A depleted prepaid balance can also involve a processing delay and negative balance. Do not treat it as an instantaneous spending cutoff. The documented billing code credit_balance_exhausted identifies missing prepaid credits; repeatedly buying credits is not a general solution to every capacity error.
Check throughput independently of the monthly ceiling
The Standard table gives Build’s Astra, Sol, and Terra group 5,000 requests per minute and 1,000,000 tokens per minute; Build’s Luna row has 5,000 requests and 2,000,000 tokens per minute. Standard and Ultrafast limits differ. These are the guide’s group labels, not newly discovered exact Model IDs.
For planning, first measure the workload you intend to send. This original example uses a team’s own proposed budget of 1,000 requests and 800,000 tokens per minute. A workload of 800 requests averaging 1,500 tokens would require 1,200,000 tokens per minute. It fits that team’s request budget but exceeds its token budget. Reducing the number of parallel workers without checking token volume could still leave the plan oversized.
Use the token counter to examine representative text, then estimate calls across the entire workflow, including repeated model turns. This is a planning exercise, not a benchmark or a guarantee that a particular account will accept the workload. Review the actual model and project limits before scheduling a load test.
Set project controls before scaling a release
OpenAI’s production guidance recommends separate staging and production projects, with project-level access, rate, and spend controls. It distinguishes alerts from hard limits: an alert notifies the team, while a hard spend limit stops affected API traffic when tracked spend reaches the configured amount.
For a small release, write down who owns the API organization, which project serves customers, and which project runs evaluation jobs. Give each workload a budget and an escalation owner. If a test suite unexpectedly expands, the team should know which project to inspect without first changing the customer-facing application’s capacity settings.
Build a cost estimate from expected interactions, input and output token volume, and the selected model’s price. Our pricing calculator can support that estimate. The calculation answers a cost question; the tier table answers an organization-capacity question. Neither replaces the other.
Keep ChatGPT billing and API operations separate
OpenAI’s billing overview states that ChatGPT and API billing are separate. A Plus or Pro subscription is not an API credit purchase, and changing a ChatGPT plan does not establish one of these API purchase thresholds.
Before the next deployment, update the team’s tier terminology, confirm the intended API organization, and record its visible limits and balance. Use the API setup guide for integration steps and the pricing guide for unit-cost comparisons. This October 6 change reorganizes paid usage tiers; it does not establish a new token price, remove account controls, or prove that an existing deployment has already migrated.