LLM-API-Rate-Limits: 13 Anbieter, 2 SDKs ohne 429-Retry
Inhalt
Vier der dreizehn untersuchten LLM-APIs, zehn Anbieter sowie Bedrock, Vertex AI und Azure OpenAI, melden bei jeder Response das verbleibende Budget. Mistral liefert nur einen einzelnen Restwert. Acht APIs geben erst Auskunft, wenn ein Request fehlschlägt. Hinter einem 429 können vier verschiedene Situationen stecken: ein Throttling, das einen Retry verlangt, ein Acceleration Limit, bei dem die Last langsamer steigen muss, ein Quota- oder Spend-Limit, bei dem ein Retry nichts bringt, oder eine Überlastung, die je nach Anbieter als 429, 503 oder 529 gemeldet wird. Das Verhalten hängt zudem stärker vom Client ab, als man vermuten würde. Die SDKs von OpenAI, Anthropic und Groq wiederholen einen 429 zweimal und geben bei einem Retry-After über 60 beziehungsweise 120 Sekunden auf. Bei den SDKs von Google GenAI und Mistral sind Retries standardmäßig deaktiviert. Diese Übersicht vergleicht anbieterübergreifend die Limit-Dimensionen, die angerechneten Tokens, die Response-Header, die Bedeutung eines 429 und das Verhalten der offiziellen SDKs auf Basis ihres Sourcecodes.
TL;DR
- LLM-APIs begrenzen Requests und Tokens pro Minute. Anthropic trennt Input und Output, DeepSeek begrenzt nur die Parallelität.
- OpenAI, Azure und Bedrock buchen
max_tokensvorab ab. Anthropic nimmt Cache Reads aus, xAI zählt Reasoning Tokens, und Bedrock verbraucht pro Claude-5-Output-Token 10 Quota-Tokens. - OpenAI, Anthropic, Groq und Azure liefern bei jedem 200 verbleibende Limits und Reset-Header. Acht APIs dokumentieren keine solchen Header.
- Die SDKs google-genai und Mistral wiederholen einen 429 standardmäßig nicht. OpenAI, Anthropic und Groq versuchen es zweimal und begrenzen Retry-After auf 60 beziehungsweise 120 Sekunden.
Was bedeuten RPM, TPM und die anderen Limits?
Alle Werte begrenzen, wie viel innerhalb eines Zeitfensters gesendet werden darf. Jeder Anbieter verwendet dafür eine eigene Kombination:
| Gruppe | Begriffe | Bedeutung und Verwendung |
|---|---|---|
| Request-Metriken | RPM, RPD, RPS, Parallelität | Requests pro Minute oder Tag. Jeder Aufruf zählt einmal, unabhängig von seiner Größe. RPS entspricht meist RPM geteilt durch 60 und dient als Schutz vor Lastspitzen (xAI, Alibaba, Mistral, Azure). Parallelität zählt gleichzeitig laufende Requests statt Requests pro Zeitfenster und ist das einzige Limit von DeepSeek |
| Token-Metriken | TPM, TPD, ITPM, OTPM, burndown rate | Tokens pro Minute oder Tag. Einige Anbieter trennen Input (ITPM) und Output (OTPM). Eine burndown rate multipliziert Output-Tokens, bevor sie auf die Quota angerechnet werden (Bedrock). Welche Tokens überhaupt zählen, legt der Anbieter fest. Details folgen im nächsten Abschnitt |
| Metriken für andere Einheiten | IPM, audio seconds, OCR pages | Bilder pro Minute bei Bildmodellen (OpenAI, Gemini), Audiosekunden pro Stunde oder Tag (Groq, Mistral), Seiten pro Minute bei Dokument-OCR (Mistral) |
| Durchsetzung des Zeitfensters | Token bucket, acceleration limit | Ein Token Bucket füllt sich kontinuierlich, statt zur vollen Minute zurückgesetzt zu werden. Deshalb kann eine Lastspitze den Bucket leeren, obwohl die Summe unter dem Minutenlimit bleibt (Anthropic; Alibaba und Azure beschreiben denselben Effekt). Ein Acceleration Limit prüft separat, wie schnell die Nutzung steigt. Ein plötzlicher Anstieg kann es auslösen, obwohl das eigentliche Limit noch nicht erreicht ist (Anthropic, OpenAIs slow_down) |
| Grundlage der Grenzwerte | Tier, spend cap oder quota, provisioned capacity | Ein Tier bestimmt die oben genannten Limits. Der Aufstieg erfolgt durch bezahlte Nutzung oder Nutzungshistorie, nicht durch das Aufladen von Guthaben. Ein Spend Cap oder eine tägliche Quota begrenzt Kosten beziehungsweise Volumen, nicht die Rate. Eine Minute zu warten hilft daher nicht. Provisioned Capacity ist reservierter Durchsatz, der pro Einheit und Stunde abgerechnet wird (Bedrock und Vertex AI Provisioned Throughput, Azure PTU). Ein 429 bedeutet hier, dass die Reservierung ausgelastet ist, nicht dass eine Quota aufgebraucht wurde |
Die angegebene Zahl ist eine Obergrenze für das Zeitfenster, kein frei verteilbares Kontingent. Anthropic weist darauf hin, dass 60 RPM “might be enforced as 1 request per second”. Azure schreibt, dass “a burst within a 1-second or 10-second window can trigger a 429 even if the per-minute total is within limits”.
Welche Größen begrenzen LLM-APIs?
Fast alle Anbieter begrenzen Requests und Tokens pro Minute. Die drei Clouds übernehmen die Regeln ihrer Anbieter nicht einfach unverändert. Die Definitionen stammen von den verlinkten Anbieterseiten mit Stand vom 2026-09-03 und 2026-09-04.
| Anbieter | Dimensionen | Wie die Limits steigen | Quelle |
|---|---|---|---|
| OpenAI | RPM, RPD, TPM, TPD, IPM, Audiominuten pro Minute; Batch-API-Queue nach wartenden Input-Tokens | Tiers 1 bis 5 nach kumulierten Zahlungen | Rate Limits |
| Anthropic | RPM, ITPM, OTPM pro Modellklasse; Token Bucket; Acceleration Limits | Start-, Build- und Scale-Tiers nach Nutzungshistorie | Rate Limits |
| Google Gemini | RPM, TPM (Input), RPD; IPM bei Bildmodellen | Kostenlos, danach Tiers 1 bis 3 mit Ausgabenlimits pro 10 Minuten | Rate Limits |
| xAI | RPS (RPM / 60) und TPM pro Modell | Tiers 0 bis 4 plus Enterprise | Rate Limits |
| Alibaba Model Studio | RPM und TPM pro Modell, mit RPS = RPM / 60 und TPS = TPM / 60 als Schutz vor Lastspitzen | Pro Modell; Batch ist bei einigen Modellen ausgenommen | Rate Limits |
| DeepSeek | Nur Parallelität: 500 Verbindungen bei V4 Pro, 2,500 bei V4 Flash | Fest pro Modell | Rate Limit |
| Mistral | RPS, Tokens pro Minute, Tokens pro Monat, jeweils pro Modell und Workspace | Tiers 1 bis 4 nach kumulierter Abrechnung; “Adding credits does not raise your rate limits” | Nutzung und Limits, Help Center |
| MiniMax | RPM und TPM pro Modell; MiniMax M3 mit 200 RPM und 10M TPM | Vertrieb kontaktieren | Rate Limits |
| Moonshot Kimi | Parallelität, RPM, TPM, TPD; Tier 0 bietet 1 parallelen Request und 3 RPM, Tier 5 bietet 100 und 300 | Sechs Tiers nach kumuliertem Guthabenkauf, $1 bis $3,000 | Limits |
| Groq | RPM, RPD, TPM, TPD, ITPM, OTPM, Audiosekunden pro Stunde und Tag | Pro Modell | Rate Limits |
| Amazon Bedrock | RPM, TPM, TPD pro Modell und Region; TPD ist standardmäßig TPM x 1,440 | Service Quotas, Erhöhung auf Anfrage; neue Accounts starten mit niedrigeren Werten | Quotas |
| Google Vertex AI | Bei Pay-as-you-go gibt es keinen festen Wert pro Projekt, sondern einen gemeinsamen Pool, in dem “your organization’s historical spend determines your Usage Tier and baseline throughput (TPM)”, mit Best-Effort-Bursts | Usage Tier nach Ausgaben; Provisioned Throughput “provides isolation from the shared PayGo pool” | Google-Cloud-Blog |
| Azure OpenAI | TPM wird pro Deployment zugewiesen, RPM daraus abgeleitet (6 RPM pro 1,000 TPM bei älteren Modellen, 1 RPM pro 1,000 TPM bei aktuellen); PTU-Deployments werden nach Auslastung begrenzt | Quota-Tiers 0 bis 6, automatische Upgrades | Quotas und Limits, Quota-Verwaltung |
Zwei Zeilen beschreiben keine Minutenfenster. DeepSeek begrenzt offene Verbindungen. Unter Last bleibt ein Request bis zu 10 Minuten offen und erhält leere Zeilen oder bei einem Stream : keep-alive-Kommentare, statt abgelehnt zu werden. Bei Vertex AI gibt es für Pay-as-you-go keinen abfragbaren Quota-Wert. Ein 429 bedeutet dort, dass der gemeinsame Pool in diesem Moment nicht genug Kapazität hatte.
Welche Tokens zählen für das Limit?
Es sind nicht dieselben Tokens, die abgerechnet werden. Dieser Unterschied entscheidet darüber, ob die tatsächliche Kapazität nur einen Bruchteil oder ein Vielfaches des angegebenen Werts beträgt:
| Anbieter | Was auf das Token-Limit angerechnet wird | Auswirkung |
|---|---|---|
| OpenAI | Der größere Wert aus max_tokens und einer Schätzung anhand des Prompts, bei Eingang des Requests abgebucht: “If you set max_tokens too high, your usage can be overestimated, even if the actual response is much shorter” (Cookbook) | max_tokens von 4,000 bei einer Antwort mit 50 Tokens verbraucht 4,000 TPM |
| Azure OpenAI | Eine Schätzung aus “prompt text and count, the max_tokens parameter setting, the best_of parameter setting”, teilweise anhand der Zeichenzahl; bei PTU-Deployments “cached tokens receive a 100% discount” (Quota-Leitfaden) | “A rate limit can be triggered prior to what might be expected”; wenn max_tokens fehlt, wird der Wert geschätzt |
| Amazon Bedrock | ”Total input tokens + max_tokens” wird zu Beginn abgezogen und am Ende auf InputTokenCount + CacheWriteInputTokens + (OutputTokenCount x burndown rate) korrigiert. Cache Reads sind ausgenommen. Der Burndown beträgt 5x bei Claude 4.7 und älter, 10x bei Sonnet 5, Opus 5, Fable 5.1 und den GPT-5.6-Modellen sowie 15x bei Claude 4.8 (Token-Zählung) | Das dokumentierte Beispiel: 1,000 Input- und 100 Output-Tokens bei einem 5x-Modell verbrauchen 1,500 Quota-Tokens, abgerechnet werden 1,100 |
| Anthropic | ITPM zählt input_tokens und cache_creation_input_tokens; cache_read_input_tokens “do NOT count toward ITPM”. OTPM zählt den tatsächlichen Output; “max_tokens does not factor into OTPM” (Dokumentation) | Das dokumentierte Beispiel: 2M ITPM verarbeiten bei einer Cache-Hit-Rate von 80% pro Minute 10M Input-Tokens |
| xAI | ”All tokens consumed by a request count toward the TPM limit: prompt tokens (text, image, and audio), completion tokens, reasoning tokens (on reasoning models), cached prompt tokens” | Reasoning verbraucht TPM für Tokens, die nie sichtbar werden. Caching erhöht den Durchsatz nicht |
| Google Gemini | Input-Tokens | Die Länge des Outputs verringert das Limit nicht |
| Alibaba, Mistral, MiniMax | Input plus Output | |
| Kimi, Groq, DeepSeek, Vertex AI | Nicht angegeben | Groq misst ITPM und OTPM getrennt. DeepSeek hat kein Token-Limit. Vertex AI veröffentlicht nur eine Baseline pro Usage Tier |
Derselbe Request ist für jedes Limit unterschiedlich groß, im Beispiel oben zwischen 800 und 6,000 Tokens. Ein Router, der eine Workload auf mehrere Anbieter verteilt, braucht deshalb einen separaten Zähler pro Anbieter.
Welche Header liefern die Anbieter zurück?
Vier APIs liefern den Zustand der Limits in jeder Response. Mistral sendet ein einzelnes Feld. Bei den übrigen acht muss der Client selbst zählen.
| Anbieter | Header bei einer normalen Response | Format |
|---|---|---|
| OpenAI | x-ratelimit-limit-requests, x-ratelimit-limit-tokens, x-ratelimit-remaining-requests, x-ratelimit-remaining-tokens, x-ratelimit-reset-requests, x-ratelimit-reset-tokens sowie das -project-tokens-Trio | Reset ist “the time until the rate limit resets”; Retry-After bei 429 |
| Azure OpenAI | Dieselben sechs x-ratelimit-*-Namen bei jedem Aufruf; retry-after-ms und retry-after bei 429 | Wenn x-ratelimit-limit-tokens unter dem konfigurierten TPM-Wert liegt, ist eine “temporary rate limit adjustment” aktiv |
| Anthropic | anthropic-ratelimit-requests-{limit,remaining,reset}, dasselbe Trio für tokens, input-tokens und output-tokens, außerdem anthropic-priority-* und anthropic-fast-*, sofern diese Tiers gelten | Reset im RFC-3339-Format; Remaining wird auf Tausender gerundet; das tokens-*-Trio zeigt “the most restrictive limit currently in effect” |
| Groq | x-ratelimit-limit-requests (täglich), x-ratelimit-limit-tokens (pro Minute), x-ratelimit-remaining-*, x-ratelimit-reset-*; “always included” | Reset als Zeitdauer, "2m59.56s", "7.66s"; retry-after in Sekunden, nur bei 429 |
| Mistral | X-RateLimit-Remaining | |
| Gemini, xAI, Alibaba, DeepSeek, MiniMax, Kimi, Bedrock, Vertex AI | Keine dokumentiert | Gemini, Alibaba und Bedrock nennen den Grund im Error Body. Kimi dokumentiert Retry-After bei Überlastung. Die AWS-SDKs lesen x-amz-retry-after in Millisekunden, wenn ein Service den Header sendet |
Das praktische Problem sind drei Formate für denselben Wert: OpenAI liefert eine Zeitdauer, Anthropic einen Zeitstempel und Groq Werte wie 2m59.56s. Dafür sind drei Parser nötig. Auch deshalb lesen die SDKs nur retry-after. Am 2026-09-03 wurden zwei Intermediäre mit jeweils einem Request gemessen. Ein großer Multi-Provider-Aggregator lieferte bei einem 200 überhaupt keinen Rate-Limit-Header und verwendete solche Header nur bei 429-Responses. Das Synthorai Gateway lieferte neben den Kosten des Requests x-ratelimit-remaining-requests und x-ratelimit-reset-requests.
Was bedeutet ein 429, und sollte der Request wiederholt werden?
Hinter einem 429 können vier verschiedene Ursachen stecken. Nur bei zwei davon ist ein Retry sinnvoll:
| Bedeutung | Retry? | Bezeichnung bei den Anbietern |
|---|---|---|
| Throttling: Ein Limit wurde überschritten | Ja, nach Retry-After oder Backoff | OpenAI und Anthropic 429 rate_limit_error, bei Anthropic mit retry-after; Gemini und Vertex AI 429 RESOURCE_EXHAUSTED, bei Vertex AI bedeutet das fehlende Kapazität im gemeinsamen Pool; Kimi rate_limit_reached_error; Bedrock ThrottlingException, außerdem ModelNotReadyException, das vom SDK bis zu 5-mal wiederholt wird; Azure “Rate limit is exceeded”; xAI RateLimitError; Alibaba “Requests rate limit exceeded”; DeepSeek und Mistral 429 |
| Acceleration: Die Last ist zu schnell gestiegen | Anstieg verlangsamen, dann erneut versuchen | OpenAI slow_down; Anthropic “acceleration limits”; Alibaba “Request rate increased too quickly”; Azure, eine Lastspitze innerhalb eines 1-Sekunden- oder 10-Sekunden-Fensters |
| Quota oder Spend Cap: Warten gibt keine Kapazität frei | Nein, Abrechnung korrigieren oder bis zum Reset-Datum warten | OpenAI insufficient_quota, credit_balance_exhausted, organization_spend_limit_exceeded; Anthropic enforced_spend_limit_reached ohne retry-after, während ein eigenes Spend Limit als 400 zurückkommt; Gemini quota_exceeded (täglich); Kimi exceeded_current_quota_error; Bedrock 400 ServiceQuotaExceededException; Aggregator und DeepSeek 402. Bei Azure wird die Quota bei der Deployment-Erstellung zugewiesen, daher führt ihre Ausschöpfung nicht zu einem 429 |
| Überlastung: Die Kapazität des Anbieters ist erschöpft, nicht die eigene | Ja, mit Backoff | OpenAI 503 server_is_overloaded; Anthropic 529 overloaded_error; Gemini 503 UNAVAILABLE; Kimi 429 engine_overloaded_error mit Retry-After; Bedrock 503 ServiceUnavailableException und 529 overloaded_error; Azure “System is experiencing high demand”, eine “temporary rate limit adjustment” des gemeinsamen Pools oder 100% Auslastung bei PTU mit retry-after-ms; DeepSeek 503 |
Die Falle steckt in der dritten Zeile. Anthropic verwendet für einen Spend-Cap-429 denselben Typ rate_limit_error wie für Throttling. In der Dokumentation steht: “Retrying, including the SDKs’ automatic retries, fails until access resumes.” Auch OpenAI meldet insufficient_quota als 429. Ein Client, der nur anhand des Statuscodes entscheidet, wiederholt beide Fehler. Genau das tun alle offiziellen SDKs, wie der nächste Abschnitt zeigt. Die Entscheidung sollte anhand des Error Codes fallen. Ein 429 ohne Retry-After ist ein Hinweis darauf, dass Warten nichts bringt.
Bei der vierten Zeile unterscheiden sich die Clouds. Azure formuliert es im Troubleshooting-Leitfaden eindeutig: “Many customers misinterpret capacity-related 429s as quota problems, leading to incorrect remediation.” Bei Azure schützt ein 429 mit einem x-ratelimit-limit-tokens unter dem konfigurierten Wert den gemeinsamen Pool. Bei Vertex AI gilt das für jeden Pay-as-you-go-429. Bedrock meldet denselben Zustand als 503 oder 529, nie als ThrottlingException. Über einen Aggregator steht die eigentliche Ursache im Body. Bei der Header-Messung kam ein 429 mit provider_error_code: insufficient_quota und limit_source: upstream_provider_shared_pool zurück. Der Statuscode sagte Throttling, der Body sagte, dass die Quota eines anderen aufgebraucht war.
Was macht das SDK mit einem 429?
Das hängt vom SDK ab. Zwei der meistgenutzten SDKs tun standardmäßig gar nichts. Die Angaben stammen mit Stand vom 2026-09-04 direkt aus dem Sourcecode der offiziellen Clients, nicht aus ihrer Dokumentation:
| SDK | Standardmäßige Retries | Wiederholte Statuscodes | Backoff | Umgang mit Retry-After |
|---|---|---|---|---|
| openai-python (auch Azure OpenAI) | 2 | 408, 409, 429, 5xx oder alles, was x-should-retry vorgibt | min(0.5 × 2^n, 8) s mit Jitter | Liest retry-after-ms, dann retry-after als Sekunden oder Datum; bei mehr als 120 s erfolgt überhaupt kein Retry |
| anthropic-sdk-python, groq-python | 2 | identisch | identisch | Identisches Parsing; bei mehr als 60 s wird der Header ignoriert und die Backoff-Formel verwendet |
| openai-node, anthropic-sdk-typescript | 2 | identisch | identisch | Identisch; bei mehr als 60 s wird der Standard-Backoff verwendet |
| google-genai (Python, Gemini API und Vertex AI) | 0: retry_options ist standardmäßig None, was genau einen Versuch ergibt | Wenn aktiviert: 408, 429, 500, 502, 503, 504 | Wenn aktiviert: 5 Versuche, beginnend bei 1 s, Verdopplung bis 60 s, mit Jitter | Liest Retry-After nicht |
| mistralai (Python) | 0: retry_config ist standardmäßig nicht gesetzt | Wenn konfiguriert: 429, 500, 502, 503, 504 | Wenn konfiguriert: 500 ms × 1.5^n bis maximal 60 s, insgesamt höchstens 1 h | Beachtet jedes Retry-After, als Sekunden oder Datum |
| boto3 (Bedrock) | Legacy-Modus: 5 Versuche einschließlich des ersten; Standardmodus: 3 | ThrottlingException und verwandte Fehler, 429, 5xx | Basisfaktor 2, im Standardmodus auf 20 s begrenzt. Das Verhalten von 2026 (Opt-in über AWS_NEW_RETRIES_2026=true) verwendet Full Jitter, eine Basis von 1,000 ms bei Throttling und einen Retry Token Bucket | Kein Retry-After; das Verhalten von 2026 liest x-amz-retry-after in Millisekunden und begrenzt den Wert auf Backoff plus 5 s |
| xai-sdk (Python, gRPC) | 5 Versuche, nur bei UNAVAILABLE | RESOURCE_EXHAUSTED, also der gRPC-429, wird nicht wiederholt | 0.1 s, Verdopplung bis 1 s | n/a |
| dashscope (Alibaba) | 0 bei HTTP-Statuscodes; einmaliges erneutes Senden, wenn eine Verbindung aus dem Pool abbricht, bevor Bytes empfangen wurden | |||
| DeepSeek, Kimi, MiniMax | Kein First-Party-Chat-SDK; die DeepSeek-Dokumentation empfiehlt, “use the OpenAI/Anthropic SDK” mit einer anderen Base URL |
Daraus folgen drei Punkte. Erstens erreicht ein 429 von Gemini, Vertex AI oder Mistral den Anwendungscode bereits beim ersten Auftreten, sofern keine Retry-Optionen gesetzt wurden. Der Kommentar im google-genai-Sourcecode, der Client “will retry 4 times”, beschreibt die aktivierte Konfiguration, nicht den Standard. Zweitens widersprechen die Obergrenzen für Retry-After den langen Wartezeiten, die Anbieter tatsächlich verlangen. Soll Anthropics SDK 90 Sekunden warten, ignoriert es den Header und versucht es nach weniger als 8 Sekunden erneut. Soll OpenAIs SDK 150 Sekunden warten, führt es keinen Retry aus. Drittens beachten die von Stainless generierten SDKs, also die Clients von OpenAI, Anthropic und Groq, einen undokumentierten x-should-retry-Header, bevor sie den Statuscode prüfen. Außerdem werten sie retry-after-ms vor retry-after aus. So können Anbieter oder Gateways Retries steuern, ohne den Statuscode zu ändern.
Keines der SDKs unterscheidet einen Spend-Cap-429 von Throttling. Zwei Retries auf eine insufficient_quota-Response kosten jeweils nur einige Sekunden. Wenn eine ganze Flotte das gleichzeitig tut, erzeugt sie ihre eigene Lastspitze.
Wie verändert ein Gateway das Verhalten?
Ein Gateway ist die zentrale Stelle, an der sich diese Unterschiede einmalig behandeln lassen. Upstream liest es die jeweiligen Header der Anbieter. Damit sind die drei Reset-Formate und die vier Bedeutungen eines 429 Aufgabe des Gateways statt jedes einzelnen Clients. Downstream liefert es ein einheitliches Header-Set und ein einheitliches Fehlerformat, wie bei den oben gemessenen Synthorai-Headern. Die Abrechnungslogik des Anbieters kann ein Gateway nicht ändern. Hinter OpenAI belastet max_tokens weiterhin vorab das TPM-Limit. Hinter Bedrock verbraucht ein Claude-Output-Token weiterhin zehn Tokens. Wenn ein Gateway viele Clients über einen gemeinsamen Anbieter-Key bündelt, erreicht es das Acceleration Limit dieses Anbieters schneller als jeder einzelne Client. Dafür braucht es Buckets pro Key statt eines einzigen gemeinsamen Counters.
FAQ
Zählt max_tokens zum Rate Limit?
Bei OpenAI, Azure OpenAI und Bedrock ja: max_tokens wird beim Eingang des Requests abgebucht. Ein zu hoher Wert verschwendet TPM, auch wenn die Antwort kurz ist. Bedrock korrigiert die Abbuchung nach Abschluss der Response. Bei Anthropic nicht: OTPM zählt die tatsächlich erzeugten Tokens, und max_tokens “does not factor” in die Berechnung ein.
Zählen gecachte Tokens zum Rate Limit?
Bei Anthropic, Bedrock und Azure-PTU-Deployments nicht, dort sind Cache Reads ausgenommen. Bei xAI zählen sie vollständig. OpenAI und Gemini machen dazu keine Angabe.
Wird Retry-After bei einem 429 immer gesendet?
Nein. OpenAI, Azure als retry-after-ms und Groq senden den Header bei Throttling. Anthropic sendet ihn bei Throttling, aber nicht beim Spend Cap. Kimi und Bedrock liefern ihn nur bei Überlastung. Gemini, Vertex AI, xAI, Alibaba, DeepSeek und MiniMax dokumentieren keinen solchen Header. Für diese Anbieter braucht der Client einen eigenen Backoff.
Warum hat mein SDK einen 429 nicht wiederholt?
Beim Python-SDK von Google GenAI oder Mistral sind Retries standardmäßig deaktiviert. Dafür müssen retry_options beziehungsweise eine RetryConfig gesetzt werden. Beim OpenAI-Python-SDK wird bewusst kein Retry ausgeführt, wenn der Server mehr als 120 Sekunden Wartezeit vorgibt. Handelte es sich bei dem 429 um eine Quota oder einen Spend Cap statt um Throttling, war der Verzicht auf einen Retry korrekt.
Passend dazu: Überblick über Abrechnungseinheiten, Preisstufen für lange Kontexte, Anatomie der Token-Nutzung, Audit des Gateway-Caches.