OpenAI API: Build, Launch und Grow ersetzen die alten Usage Tiers

OpenAI vereinfacht die Usage Tiers seiner API. Aus fünf bezahlten Stufen werden drei: Build, Launch und Grow. Für bestehende Organisationen erfolgt die Umstellung automatisch, teilweise mit höheren Rate Limits.

Aus fünf OpenAI API Usage Tiers werden drei

Wer die OpenAI API produktiv nutzt, begegnet früher oder später den Usage Tiers. Sie bestimmen unter anderem, wie viele Requests und Tokens eine Organisation innerhalb eines bestimmten Zeitraums verarbeiten kann.

OpenAI reduziert das bisherige System aus fünf bezahlten Tiers nun auf drei Stufen:

Die Migration erfolgt automatisch. Bestehende Organisationen müssen ihre Konfiguration nicht ändern und auch keine zusätzliche Zahlung leisten, nur um in den entsprechenden neuen Tier übernommen zu werden.

Auch die regulären API-Preise ändern sich durch die neue Einteilung nicht.

Für Entwickler ist deshalb vor allem eine andere Frage interessant: Welche Rate Limits gelten künftig?

OpenAI API Rate Limits für Build, Launch und Grow

Die neuen Standard-Limits unterscheiden sich nach Usage Tier und Modellgruppe.

Gerade zwischen Launch und Grow steigt damit nicht nur die Zahl möglicher Requests. Besonders deutlich wächst die verfügbare Token-Kapazität.

Bei Astra, Sol und Terra erhöht sich das TPM-Limit von 4 Millionen in Launch auf 40 Millionen in Grow. Bei Luna steigt es von 10 Millionen auf 180 Millionen Tokens pro Minute.

Was bedeuten RPM und TPM?

Bei den Rate Limits der OpenAI API sind vor allem zwei Werte wichtig.

RPM steht für "Requests per Minute". Der Wert gibt an, wie viele API-Anfragen innerhalb einer Minute verarbeitet werden dürfen.

TPM steht für "Tokens per Minute". Dieses Limit betrifft die Menge der Tokens, die innerhalb einer Minute verarbeitet werden kann.

Beide Grenzen sind unabhängig voneinander relevant. Eine Anwendung kann deshalb beispielsweise noch ausreichend freie Requests haben, aber trotzdem an das Token-Limit stoßen.

Das spielt besonders bei Anwendungen eine Rolle, die große Kontexte, lange Ausgaben oder viele parallele AI-Workloads verarbeiten. Für die praktische Softwareentwicklung ist ein hohes RPM-Limit allein daher nicht automatisch ausreichend.

Tier 1 und Tier 3 erhalten höhere Limits

Nicht jede Organisation bekommt durch die Umstellung tatsächlich mehr Kapazität.

OpenAI unterscheidet hier nach dem bisherigen Usage Tier:

• Organisationen aus Tier 1 wechseln zu Build und erhalten höhere Rate Limits.
• Organisationen aus Tier 2 wechseln ebenfalls zu Build, behalten aber ihre bisherigen Limits.
• Organisationen aus Tier 3 wechseln zu Launch und erhalten höhere Rate Limits.
• Organisationen aus Tier 4 wechseln zu Launch und behalten ihre bisherigen Limits.
• Organisationen aus Tier 5 wechseln zu Grow und behalten ihre bisherigen Limits.

Die neue Bezeichnung bedeutet also nicht automatisch, dass sich das verfügbare Kontingent einer bestehenden Organisation verändert.

Für Nutzer aus Tier 1 und Tier 3 ist die Umstellung dagegen unmittelbar interessant, weil OpenAI ihre Limits anhebt.

Grow wird für größere API-Workloads interessant

Besonders auffällig ist Grow bei Luna.

Mit bis zu 30.000 Requests und 180 Millionen Tokens pro Minute liegt das Limit deutlich über den anderen Standard-Tiers. Das kann bei Anwendungen relevant werden, die sehr viele parallele, vergleichsweise kleine Modellaufrufe verarbeiten.

Bei Astra, Sol und Terra liegt Grow bei 15.000 RPM und 40 Millionen TPM.

Solche Limits sind beispielsweise für größere KI Pipelines, Agentensysteme, Batch-Verarbeitung oder stark frequentierte SaaS-Anwendungen relevanter als für klassische Einzelanfragen.

Trotzdem sollte die Architektur einer Anwendung nicht einfach davon ausgehen, dass ein höherer Tier jedes Skalierungsproblem löst. Queues, Backoff-Strategien und eine saubere Behandlung von Rate-Limit-Fehlern bleiben sinnvoll.

Die neuen Tiers ändern nicht die API-Preise

Die Umstellung von Tier 1 bis 5 auf Build, Launch und Grow sollte nicht mit einem neuen Preismodell verwechselt werden.

Die Usage Tiers definieren in erster Linie, welche Nutzungs- und Rate-Limits für eine Organisation gelten. Die eigentlichen Kosten der API-Nutzung werden dadurch laut OpenAI nicht verändert.

Auch für die automatische Migration in einen der neuen Tiers verlangt OpenAI keine zusätzliche Zahlung.

Das macht die Änderung vor allem zu einer Vereinfachung des bisherigen Systems und nicht zu einer grundlegenden Änderung der API-Abrechnung.

Eigene OpenAI API Limits prüfen

Welche Limits tatsächlich für eine Organisation gelten, lässt sich in den Organisationseinstellungen der OpenAI API Platform überprüfen.

Dort zeigt OpenAI sowohl den aktuellen Usage Tier als auch die jeweiligen modellabhängigen Rate Limits an.

Das ist wichtiger als die allgemeinen Tabellenwerte, weil konkrete Limits vom Modell und von der jeweiligen Organisation abhängen können.

OpenAI bietet dort außerdem Möglichkeiten zur Kostenkontrolle. Dazu gehören Spend Alerts, mit denen sich bei bestimmten Ausgaben Benachrichtigungen auslösen lassen, sowie ein optionales Hard Spend Limit.

Gerade bei produktiven Anwendungen lohnt es sich, diese Einstellungen nach der Umstellung kurz zu kontrollieren.

Was Entwickler jetzt tun müssen

Für bestehende API-Nutzer gibt es zunächst wenig zu tun. OpenAI verschiebt Organisationen automatisch auf Build, Launch oder Grow.

Sinnvoll ist trotzdem ein Blick in die eigenen Limits. Besonders Organisationen aus den bisherigen Tiers 1 und 3 sollten prüfen, wie viel zusätzliche Kapazität ihnen nun zur Verfügung steht.

Wer bereits eigene Rate-Limit-Werte in Monitoring, Capacity Planning oder interner Dokumentation hinterlegt hat, sollte außerdem kontrollieren, ob diese Werte noch aktuell sind.

An der eigentlichen Integration der OpenAI API ändert sich durch die neuen Usage Tiers nichts.

Die wichtigste Veränderung liegt damit weniger in der API selbst als in ihrer administrativen Struktur: Statt fünf abstrakter Nummern gibt es mit Build, Launch und Grow künftig drei klarer abgegrenzte Stufen.