OpenAI-API-Ratenlimits – welches Limit Sie erreicht haben, wie Sie es lesen und welcher Retry es behebt

Ein 429 von OpenAI bedeutet, dass Sie eine von fünf Obergrenzen überschritten haben – und die erste Aufgabe besteht darin, herauszufinden, welche, denn die Lösungen weisen in entgegengesetzte Richtungen. Diese Seite erklärt, was jedes Limit misst, wie Sie die Antwort direkt aus den Response-Headern ablesen, welche Wiederholungslogik die Fehler tatsächlich beendet und was zu tun ist, wenn korrektes Backoff nicht ausreicht.

Verifiziert 30. September 2026 anhand der Dokumentation zu OpenAI-Ratenlimits.

Fünf Limits, von denen jedes einzelne auslösen kann

Das zuerst erschöpfte Limit löst den Fehler aus. Daher ist „wir sind noch weit vom Tokenlimit entfernt“ kein Grund, ein Ratenlimit auszuschließen – möglicherweise sind Sie noch weit von TPM entfernt und liegen exakt auf RPM. Limits gelten pro Organisation und pro Modell, nicht pro Schlüssel: Das Erstellen zusätzlicher Schlüssel erstellt kein zusätzliches Kontingent.

Wie ein 429 aussieht

HTTP/1.1 429 Too Many Requests
retry-after: 12
x-ratelimit-limit-requests: 500
x-ratelimit-remaining-requests: 0
x-ratelimit-reset-requests: 12s
x-ratelimit-limit-tokens: 200000
x-ratelimit-remaining-tokens: 143820
x-ratelimit-reset-tokens: 17s

{
  "error": {
    "message": "Rate limit reached for gpt-5.4 in organization org-... on requests per min (RPM).",
    "type": "requests",
    "code": "rate_limit_exceeded"
  }
}

Alles, was Sie brauchen, befindet sich in dieser Antwort. Der Body nennt die Dimension („requests per min (RPM)“), und die Header geben die genaue Obergrenze, den verbleibenden Spielraum und den Zeitpunkt der Erholung an.

Nutzungstiers

Ihre Obergrenzen werden durch Ihr Nutzungstier festgelegt, das OpenAI automatisch hochstuft, sobald sich die kumulierten Ausgaben erhöhen:

Die RPM- und TPM-Zahlen pro Modell werden hier bewusst nicht wiedergegeben. Sie unterscheiden sich je nach Modell, ändern sich mit der Veröffentlichung neuer Modelle und können pro Konto angepasst werden. Jede Tabelle mit diesen Werten auf einer Drittanbieter-Seite ist daher eine datierte Vermutung. Die beiden maßgeblichen Quellen für Ihr eigenes Konto sind die Limits-Seite im OpenAI-Dashboard und die x-ratelimit-*-Header jeder Antwort, die Sie bereits senden. Lesen Sie die Header.

Die Lösung: Retry-After beachten, dann Jitter

Die dokumentierte Empfehlung von OpenAI lautet exponentielles Backoff mit Jitter, wobei Retry-After befolgt wird, wenn die Antwort diesen Header enthält. Beide Teile sind wichtig. Ohne den Header wiederholen Sie die Anfrage möglicherweise zu früh; ohne Jitter wiederholt jeder Client, der im selben Moment ausgefallen ist, die Anfrage ebenfalls im selben Moment und fällt gemeinsam aus – ein Thundering-Herd-Effekt, der aus einer schlechten Sekunde eine schlechte Minute macht.

import random, time
import openai

client = openai.OpenAI()

def call_with_backoff(fn, *, max_attempts=6, base=0.5, cap=30.0):
    """Retry 429s: honour Retry-After when present, jittered backoff otherwise."""
    for attempt in range(max_attempts):
        try:
            return fn()
        except openai.RateLimitError as err:
            if attempt == max_attempts - 1:
                raise
            # The server's own answer beats any formula you invent.
            retry_after = (err.response.headers or {}).get("retry-after")
            if retry_after:
                delay = float(retry_after)
            else:
                # Full jitter: sleep a random point in [0, 2^n * base], capped.
                # Without the randomness every client that failed at the same
                # instant retries at the same instant and fails again together.
                delay = random.uniform(0, min(cap, base * 2**attempt))
            time.sleep(delay)

resp = call_with_backoff(lambda: client.responses.create(
    model="gpt-5.4",
    input="Summarise this changelog in three bullets.",
))

Dieselbe Struktur in TypeScript:

import OpenAI from "openai";

const client = new OpenAI();
const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));

export async function callWithBackoff<T>(
  fn: () => Promise<T>,
  { maxAttempts = 6, baseMs = 500, capMs = 30_000 } = {},
): Promise<T> {
  for (let attempt = 0; ; attempt++) {
    try {
      return await fn();
    } catch (err) {
      const status = (err as { status?: number }).status;
      if (status !== 429 || attempt === maxAttempts - 1) throw err;

      const retryAfter = (err as { headers?: Headers }).headers?.get("retry-after");
      const delay = retryAfter
        ? Number(retryAfter) * 1000
        : Math.random() * Math.min(capMs, baseMs * 2 ** attempt);
      await sleep(delay);
    }
  }
}

const resp = await callWithBackoff(() =>
  client.responses.create({ model: "gpt-5.4", input: "Hello" }),
);

Die offiziellen SDKs wiederholen Anfragen bei 429-Fehlern bereits automatisch für Sie. Die meisten Anwendungen benötigen dies daher nur, wenn sie Aufrufe in einen eigenen HTTP-Client einbinden oder ein anderes Verhalten wünschen – eine längere maximale Wartezeit für Hintergrundaufgaben oder ein sofortiges Fehlschlagen einer nutzerseitigen Anfrage, bei der 12 Sekunden Wartezeit schlimmer sind als ein Fehler.

Überwachen, bevor es ausfällt

Die Zähler befinden sich in jeder Antwort, nicht nur in Fehlerantworten. Wenn Sie die verbleibenden Werte protokollieren, wird Ratenbegrenzung von einem Vorfall zu einer Messgröße – Sie sehen, wie der Spielraum Tage vor einer Erschöpfung durch einen Launch schrumpft.

# Log the remaining counters on every response, not just on failures.
# By the time you see a 429 the useful signal is already an hour old.
resp = client.responses.with_raw_response.create(model="gpt-5.4", input="…")
h = resp.headers

log.info(
    "openai_quota model=%s req_left=%s tok_left=%s reset_req=%s reset_tok=%s",
    "gpt-5.4",
    h.get("x-ratelimit-remaining-requests"),
    h.get("x-ratelimit-remaining-tokens"),
    h.get("x-ratelimit-reset-requests"),
    h.get("x-ratelimit-reset-tokens"),
)

parsed = resp.parse()   # the normal response object

Zwei Gewohnheiten lohnen sich zusätzlich: Alarmieren Sie, wenn x-ratelimit-remaining-tokens unter einen bestimmten Anteil des Limits fällt, statt nur auf die Anzahl der 429-Fehler zu reagieren, und fügen Sie Jitter zu Zeitplänen hinzu, nicht nur zu Wiederholungen. Ein Cronjob, der alles um :00 ausführt, erzeugt seine eigene Spitze.

Wenn Backoff nicht die Antwort ist

Korrektes Backoff behebt Spitzen. Bei anhaltender Nachfrage oberhalb Ihrer Obergrenze bewirkt es nichts – dort verschieben Wiederholungen den Fehler nur nach hinten. Die strukturellen Lösungen, grob nach Aufwand geordnet:

• Output begrenzen. Reasoning-Tokens werden berechnet und als Output gezählt. Eine unbegrenzte Generierung ist daher der schnellste Weg, TPM aufzubrauchen.
• Abgerufenen Kontext kürzen. Bei einer TPM-Obergrenze verdoppelt das Halbieren der abgerufenen Chunks Ihren Durchsatz kostenlos.
• Das Modell passend dimensionieren. Ein Klassifizierungsschritt benötigt kein Frontier-Modell, und kleine Modelle haben ihr eigenes separates Budget.
• Workloads trennen. Batch-Jobs und latenzkritischer Traffic, die um eine Obergrenze auf Organisationsebene konkurrieren, sind die häufigste selbst verursachte Variante dieses Problems.
• Tier erhöhen. Tiers steigen mit kumulierten Ausgaben, daher geschieht dies häufig ohnehin bereits.

Last über Modellfamilien verteilen

Der letzte Punkt dieser Liste ist der Bereich, in dem ein Gateway seinen Nutzen zeigt. Kunavo stellt eine OpenAI-kompatible API bereit – dasselbe SDK, dieselbe Aufrufform, ein Schlüssel – über mehrere Modellfamilien hinweg. Dadurch wird das Verlagern einer Workload von einer ausgelasteten Obergrenze zu einer Änderung des Modellstrings statt zu einer zweiten Integration:

from openai import OpenAI

client = OpenAI(
    api_key="sk-kn-...",
    base_url="https://api.kunavo.com/v1",
)

# Same SDK, same call shape — the model string chooses the family.
client.chat.completions.create(
    model="gpt-5-6-terra",            # or claude-sonnet-5, claude-haiku-4-5, …
    messages=[{"role": "user", "content": "Hello"}],
)

Konkret: Der Batch-Job zur Zusammenfassung, der mit Ihrem Produktions-Traffic konkurriert hat, kann auf claude-haiku-4-5 zu $0.70 / $3.50 pro 1 Mio. laufen, während der latenzkritische Pfad auf gpt-5-6-terra ($0.70 / $4.20) oder claude-sonnet-5 ($1.40 / $7.00) bleibt. Andere Familie, andere Warteschlange.

Machen Sie sich klar, was dies leistet und was nicht. Es beseitigt den Engpass „ein Konto – ein Modell“ und bietet Ihnen eine Ausweichmöglichkeit. Es erzeugt keine Kapazität: Wenn Ihr Gesamtvolumen tatsächlich das übersteigt, was ein einzelnes Tier erlaubt, müssen Sie weiterhin das Tier erhöhen oder weniger Arbeit ausführen. Die Preise für jedes Modell finden Sie auf der Preisseite; die entsprechende Anleitung für die Limits von Anthropic finden Sie unter Claude API 429 rate_limit_error.

Häufig gestellte Fragen