OpenAI API-gebruikstiers uitgelegd: Build, Launch, Grow en bestedingslimieten
Bijgewerkt October 7, 2026 · eerst gepubliceerd October 7, 2026
OpenAI vereenvoudigde op 6 oktober 2026 zijn betaalde API-tiers tot Build, Launch en Grow. Organisaties stijgen automatisch door zodra de cumulatieve creditaankopen elke drempel passeren, wat doorgaans hogere rate limits ontgrendelt. De tier is een signaal voor capaciteit en maandelijkse gebruiksruimte; het staat los van project- of organisatiebrede bestedingslimieten, die als budgetcontroles moeten worden ingesteld.
Wat is er veranderd in de OpenAI API-gebruikstiers?
De changelog van 6 oktober van OpenAI zegt dat het API-platform is overgegaan van vijf betaalde tiers naar drie: Build, Launch en Grow. De huidige rate-limitgids noemt deze kwalificatieniveaus: Build bij $5 aan totale creditaankopen, Launch bij $100 en Grow bij $500. Ook staat er een gebruikslimiet van $100 per maand voor in aanmerking komende gebruikers van de gratis tier. OpenAI zegt dat hogere tiers doorgaans hogere modellimieten krijgen.
De aankoopbedragen zijn cumulatieve drempels om tierrecht te bepalen. Het zijn geen maandelijkse abonnementsprijzen, en ook geen belofte dat je organisatie elke maand precies dat bedrag uitgeeft. De gepubliceerde gids beschrijft ze als totale creditaankopen. Controleer het dashboard van je organisatie voor de werkelijke tier, de goedgekeurde maandelijkse gebruikslimiet en de limieten per model; de status van de organisatie telt voor operationele planning.
Wat levert een hogere tier een team op?
Rate limits kunnen requests per minuut (RPM), tokens per minuut (TPM), dagvolume, beeldverwerking of Batch-werk in de wachtrij begrenzen. Een job kan onder zijn maandelijkse gebruikslimiet blijven en toch een limiet per minuut raken. De huidige gids toont modelspecifieke verschillen: voor GPT-6 Astra, Sol en Terra stijgen de standaardvoorbeelden voor RPM/TPM van 5.000 RPM en 1 miljoen TPM bij Build naar 10.000 RPM en 4 miljoen TPM bij Launch, en 15.000 RPM en 40 miljoen TPM bij Grow. De vermelde standaardlimieten van GPT-6 Luna wijken weer af. Dit zijn gepubliceerde referentiewaarden, geen vervanging voor de limieten die voor jouw organisatie, model en project worden getoond.
Dat onderscheid doet ertoe bij lanceringen. Een team kan genoeg maandelijkse ruimte voorspellen en toch worden afgeknepen als een nieuwe workload te snel verkeer stuurt of de doorvoer van requests/tokens overschrijdt. Rate limits kunnen ook op organisatie- en projectniveau gelden, en verschillende modellen kunnen een limiet delen. Lees de responseheaders en het dashboard voordat je een tiernaam als capaciteitsgarantie behandelt.
Zijn gebruikstiers een manier om de maandelijkse uitgaven te begrenzen?
Nee. OpenAI documenteert goedgekeurde maandelijkse gebruikslimieten apart van configureerbare bestedingslimieten voor organisatie of project. Een bestedingsalert stuurt een melding terwijl het API-verkeer doorgaat. Een harde bestedingslimiet blokkeert de betrokken API-requests met een 429-respons zodra het ingestelde bedrag is bereikt. Kies de harde limiet als handhaving ertoe doet; een alert is zichtbaarheid, geen stroomonderbreker.
Dat betekent ook dat het kopen van credits om een tierdrempel te passeren op zichzelf geen veilig kostenbeheersingsbeleid is. De tier kan de doorvoer verbeteren, maar vervangt geen eigenaarschap per project, alertrouting, gebruiksprognoses of een bewuste harde limiet. Een engineeringgroep die meer lanceringscapaciteit nodig heeft, moet zowel de aankoopdrempel modelleren die nodig is om te kwalificeren als het aparte maandelijkse bestedingsplafond dat Finance wil afdwingen.
Hoe beheren Finance en engineering tierupgrades?
- Inventariseer de organisatie en projecten. Leg de tier, de maandelijkse gebruiksruimte, modelspecifieke RPM/TPM, gedeelde limieten en eigenaren voor elk productieproject vast.
- Stel expliciete bestedingscontroles in. Configureer harde limieten op projectniveau waar verkeer bij een vast budget moet stoppen, en alerts waar teams vroege waarschuwing nodig hebben. Ga er niet van uit dat de tierruimte deze controle biedt.
- Raam een workloadgroei in. Voorspel requests en tokens per minuut, naast de maandelijkse tokenuitgaven. Een service kan een doorvoerlimiet raken lang voordat hij een maandelijks dollarplafond bereikt.
- Poort tiergerelateerde aankopen. Behandel extra creditaankopen die de cumulatieve drempel vooruit helpen als een toegangs- of capaciteitsbeslissing. Vraag om een workloadprognose, een eigenaar en een review van bestaande controles voordat ze worden aangevraagd.
- Observeer de werkelijke respons. Gebruik rate-limitheaders en logs om uitputting van request-, token- en andere limieten te onderscheiden. Pas backoff toe op tijdelijke rate-limitresponsen in plaats van een retry-storm te veroorzaken.
Stel bijvoorbeeld hypothetisch dat een productteam verwacht dat een lanceringscampagne de requests per minuut verdrievoudigt, maar het maandelijkse tokengebruik onder het plafond van Finance houdt. De operationele vraag is of de modelspecifieke RPM en TPM van het project de groei aankunnen. De financiële vraag is of de harde bestedingslimiet op het goedgekeurde campagnebudget staat. Dat zijn verwante reviews, maar het zijn verschillende controles.
Hoe beslist een team of het van Build naar Launch gaat?
Begin bij workloadbewijs in plaats van het tierlabel. Als productielogs herhaalde uitputting van limieten laten zien op de huidige tier, raam dan de benodigde RPM- en TPM-ruimte, bepaal welke model- en projectlimieten gelden en bevestig het effect van de tier in het dashboard. Vergelijk dan de creditaankoop die nodig is om te kwalificeren met de bedrijfswaarde en het budgetbeleid. Als de huidige limieten volstaan, levert upgraden alleen omdat de volgende tier bestaat geen operationeel voordeel op.
OpenAI merkt op dat hogere tiers doorgaans limieten verhogen, en de gepubliceerde drempels kunnen veranderen. Controleer de rate-limitgids en het dashboard opnieuw voor een budgetcyclus of een wezenlijke verkeerswijziging. Houd de review van bestedingsalerts en harde limieten in dezelfde maandelijkse FinOps-routine als modelmix, nieuwe pogingen en kosten per geslaagde taak.
Wat is de praktische les?
Build, Launch en Grow beantwoorden een capaciteitsvraag: welke limieten en gebruiksruimte kunnen gelden naarmate de cumulatieve aankopen van een organisatie stijgen? Je bestedingscontroles beantwoorden een budgetvraag: wanneer moeten teams worden gewaarschuwd en wanneer moeten requests stoppen? Volg beide. Een tierupgrade kan doorvoer ontgrendelen, maar alleen een apart geconfigureerde harde limiet dwingt een maandelijkse kostengrens af.
Welk verwant onderzoek moeten teams lezen?
- Rate limits zijn een kostenbeheersing
- Committed spend is een gok op je prognose
- Een productierunbook voor een piek in LLM-kosten
Gerelateerd
Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit →