Start → Hilfe

Concurrency limit exceeded for user, please retry later – was das bedeutet

Was Sie sehen

• 429 Too Many Requests
• Concurrency limit exceeded for user, please retry later
• A batch script that works with 1 worker and fails with 20
• An agent that fails only when it starts several subtasks at once
• Two apps on the same account that break each other

Warum das passiert

Die Meldung stammt von sub2api, dem Open-Source-Gateway, auf dem viele API-Relay-Dienste laufen – Sie können ihr also bei mehreren Anbietern begegnen. Das Limit gilt pro Benutzerkonto, nicht pro Schlüssel: Zwei Schlüssel desselben Kontos teilen sich einen Pool. Der sub2api-Standard sind 5 gleichzeitige Anfragen.

Das Gateway lehnt die sechste Anfrage nicht sofort ab. Es stellt sie in eine Warteschlange und startet sie, sobald ein Platz frei wird. Wir haben das am 14. Oktober 2026 an unserem eigenen Gateway mit Limit 5 gemessen: 10 gleichzeitige Anfragen – alle 10 erfolgreich, die langsamste brauchte 8,3 Sekunden; 25 gleichzeitige – alle 25 erfolgreich, die langsamste 18,8 Sekunden. Die zusätzlichen Anfragen warteten, statt zu scheitern. Wenn Sie den Fehler sehen, lagen Sie also nicht nur kurz über dem Limit, sondern so lange, dass eine Anfrage nicht rechtzeitig einen Platz bekam.

Deshalb tritt er bei langen Anfragen auf, nicht bei vielen kurzen. Eine gestreamte Antwort, ein Reasoning-Modell, das eine Minute nachdenkt, oder ein Agent, der auf ein Tool wartet, belegt seinen Platz die ganze Zeit. Fünf davon gleichzeitig füllen das Konto, alles dahinter wartet, bis es aufgibt.

Prüfen, ob es daran liegt

Senden Sie zehn identische Anfragen gleichzeitig und schauen Sie auf die Zeiten:

seq 1 10 | xargs -P 10 -I{} curl -s -o /dev/null \
  -w '%{http_code} %{time_total}s\n' \
  'YOUR_BASE_URL/chat/completions' \
  -H 'Authorization: Bearer YOUR_KEY' \
  -H 'Content-Type: application/json' \
  -d '{"model":"YOUR_MODEL","messages":[{"role":"user","content":"Count from 1 to 150."}]}'

Kommen die ersten schnell zurück und der Rest in späteren Wellen, sind die Wellen Ihr Limit. Kommt bei manchen 429 mit dieser Meldung, ist die Warteschlange übergelaufen – senken Sie den Wert bei -P, bis keiner mehr kommt. Das ist die Parallelität, die Ihr Konto wirklich trägt.

So beheben Sie es

1. Offene Anfragen im Client begrenzenLegen Sie eine Semaphore um den API-Aufruf, so groß wie Ihr Kontolimit: asyncio.Semaphore(5) in Python, p-limit in Node. Eine langsamere Retry-Schleife hilft nicht; das Limit zählt offene Anfragen, also helfen nur weniger offene Anfragen.
2. Alle Schlüssel des Kontos mitzählenTeilen sich ein Coding-Agent, eine Chat-App und ein Skript ein Konto, teilen sie sich ein Limit. Geben Sie großen Batch-Jobs ein eigenes Konto oder planen Sie sie für Zeiten, in denen der Rest ruht.
3. Diesen Fehler wiederholen – mit Backoff und JitterAnders als ein 429 wegen leerem Guthaben löst sich dieser von selbst, sobald laufende Anfragen fertig sind. Warten Sie ein bis zwei Sekunden, addieren Sie einen Zufallsversatz, damit Ihre Worker nicht im Gleichschritt wiederholen, und versuchen Sie es erneut.
4. Parallelität in Agenten senkenAgenten-Tools, die Teilaufgaben starten, können viele Anfragen auf einmal öffnen. Die meisten erlauben in den Einstellungen eine Obergrenze für gleichzeitige Aufgaben oder Worker; setzen Sie sie auf oder unter das Kontolimit.
5. Höheres Limit nur für Dauerlast anfragenBraucht Ihre Arbeit wirklich den ganzen Tag mehr gleichzeitige Anfragen, fragen Sie Ihren Anbieter. Für Lastspitzen ist eine Warteschlange auf Ihrer Seite billiger und schneller als ein höheres Limit.

Verwandte Themen

Zuletzt geprüft am 2026-10-14. Geschrieben aus Problemen, die auf einem laufenden OpenAI-kompatiblen Gateway diagnostiziert wurden – nicht von anderen Seiten zusammengetragen.