Das Symptom
Mitten in der Arbeit bricht der KI-Dienst ab. Auf dem Bildschirm steht je nach
Anbieter etwas wie „zu viele Anfragen“, „Kapazität erschöpft“, rate limit oder,
wenn man sich die Antwort selbst ansieht, schlicht:
HTTP/1.1 429
{"type":"error","error":{"type":"rate_limit_error","message":"..."}}
Der Reflex ist überall derselbe: noch einmal senden. Und noch einmal. Dann die
Seite neu laden, den Browser wechseln, den Rechner neu starten – wobei jeder dieser
Versuche selbst wieder eine Anfrage ist, die auf denselben Zähler geht.
Die „Layer 8“-Wahrheit
Der Fehler ist kein Ausfall, sondern eine Rechnung. 429 heißt seit RFC 6585 nichts
anderes als: In einem bestimmten Zeitraum kamen zu viele Anfragen. Der Dienst
funktioniert tadellos – er weigert sich nur, in diesem Moment noch mehr zu tun. Layer 8
sitzt an zwei Stellen zugleich. Erstens im Wort „Anfragen“: Gezählt wird nicht nur, wie
oft gefragt wurde, sondern auch, wie viel Text dabei hin- und herging. Anthropic misst
getrennt in Anfragen, Eingabe-Token und Ausgabe-Token pro Minute, Google in Anfragen pro
Minute, Eingabe-Token pro Minute und Anfragen pro Tag – und eine einzige gerissene Grenze
genügt, während alle anderen Zähler noch fast leer sind. Wer ein Buch als Anhang
hochlädt, hat eine Anfrage gestellt und ein Kontingent geleert.
Zweitens im Wort „Wiederholen“. Es gibt zwei Wände mit derselben Nummer, und sie
verlangen das genaue Gegenteil voneinander. Die Ratenbegrenzung ist eine Warteschlange:
Die Antwort trägt eine retry-after-Kopfzeile, die nach RFC 9110 entweder Sekunden oder
ein Datum enthält, und wer sie abwartet, kommt durch. Die erreichte Ausgabengrenze des
Kontos ist dagegen ein geschlossener Schalter: derselbe Fehlertyp, derselbe Code, aber
keine retry-after-Kopfzeile – und Anthropic schreibt ausdrücklich, dass Wiederholungen
einschließlich der automatischen Wiederholungen der SDKs so lange scheitern, bis der
Zugriff von selbst zurückkehrt. Die Antwort sagt einem also, welcher Fall vorliegt; man
muss sie nur lesen, statt sie wegzuklicken.
Deshalb ist der Wiederholen-Knopf hier ausgerechnet das schlechteste Werkzeug. Im ersten
Fall scheitert er ohnehin – zu frühe Versuche schlagen laut Anthropic fehl, und das SDK
wiederholt im Hintergrund längst selbst. Im zweiten Fall tut er nachweislich gar nichts.
Was tatsächlich hilft, ist unspektakulär: die Wartezeit aus der Antwort nehmen, statt sie
zu schätzen. Weniger Text pro Anfrage schicken – Google nennt kleinere
Kontextfenster und kürzere Ausgaben selbst als Abhilfe. Bei mehreren Versuchen exponentiell
länger warten und einen Zufallsversatz einstreuen, damit nicht alle Clients im Gleichschritt
anklopfen. Und Lastspitzen verteilen statt sie zu stapeln, weil Anthropic zusätzlich
Beschleunigungsgrenzen kennt und wörtlich empfiehlt, den Verkehr allmählich hochzufahren.
Kurz: Der Dienst hat nicht Nein gesagt, sondern „nicht so viel auf einmal“.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.Die Meldung zu Ende lesen, bevor irgendetwas gedrückt wird
In der Meldung steht fast immer mehr als das Wort „Limit“: eine Zahl (429), ein Fehlertyp, oft ein Zeitpunkt, ab dem es weitergeht. Genau dieser Satz entscheidet über alles Weitere. Anthropic nennt bei erreichter Ausgabengrenze im Klartext das Datum und die Uhrzeit, ab der wieder Zugriff besteht; Google gibt bei ausgabenbasierten Grenzen einen 429 mit dem Zusatz RESOURCE_EXHAUSTED aus. Wer die Meldung wegklickt, wirft die einzige Information weg, die er gerade bekommen hat.
2.Nachsehen, ob eine Wartezeit mitgeliefert wurde
Bei einer echten Ratenbegrenzung schickt die Schnittstelle laut Anthropic-Dokumentation einen 429 zusammen mit einer `retry-after`-Kopfzeile, die angibt, wie lange zu warten ist. Der Standard erlaubt dort zwei Formen: eine Sekundenzahl oder ein festes Datum (RFC 9110, Abschnitt 10.2.3). Wer eigenen Zugang hat, macht die Kopfzeilen sichtbar, statt zu raten – bei Anthropic stehen daneben auch die verbleibenden Anfragen und Token sowie der Zeitpunkt, zu dem das Kontingent wieder voll ist.
# -D - schreibt die Kopfzeilen der Antwort auf die Standardausgabe,
# -o /dev/null wirft den Rumpf weg.
curl -sS -D - -o /dev/null -X POST "$ENDPUNKT" -H "content-type: application/json" -d @anfrage.json
3.Fehlt die Wartezeit, ist Wiederholen sinnlos
Das ist der Unterschied, den fast niemand kennt. Ist die monatliche Ausgabengrenze des Kontos erreicht, kommt bei Anthropic derselbe Fehlertyp `rate_limit_error` mit demselben Code 429 – aber ohne `retry-after`-Kopfzeile, und die Dokumentation ist unmissverständlich: Wiederholungen scheitern, „including the SDKs' automatic retries“, bis der Zugriff von selbst zurückkehrt. Erkennungszeichen auf der Messages-API ist `enforced_spend_limit_reached`. Hier hilft nur eine höhere Stufe oder der nächste Monat, und jeder Klick auf „Nochmal“ ist verlorene Lebenszeit.
4.Herausfinden, welche der Grenzen getroffen wurde
„Zu viele Anfragen“ ist ein irreführender Name, denn gezählt wird mehrfach. Anthropic misst Anfragen pro Minute, Eingabe-Token pro Minute und Ausgabe-Token pro Minute getrennt; Google misst Anfragen pro Minute, Eingabe-Token pro Minute und Anfragen pro Tag und schreibt dazu, dass das Überschreiten einer einzigen dieser Größen den Fehler auslöst – auch wenn alle anderen weit unter der Grenze liegen. Eine einzige Anfrage mit einem riesigen Anhang kann die Token-Grenze reißen, während der Anfragezähler bei eins steht.
5.Die Menge senken, nicht die Schlagzahl erhöhen
Google nennt als Abhilfe ausdrücklich, die Rate teurer Anfragen zu senken, etwa durch kleinere Kontextfenster und kürzere Ausgaben. Übersetzt fürs Chatfenster: nicht das ganze Archiv in eine Nachricht kippen, lange Gespräche neu anfangen statt endlos weiterschleppen, Ausgaben knapp halten. Bei eigenem Zugang kommt hinzu, dass bei Anthropic für die meisten Modelle nur ungecachte Eingabe-Token auf die Minutengrenze zählen – aus dem Cache gelesener Kontext zählt also nicht jedes Mal erneut gegen das Minutenkontingent.
6.Wiederholen mit System – und die Last verteilen
Wenn wiederholt wird, dann nach den Regeln, die Google in seiner Fehlersuche aufschreibt: erst kurz warten, dann die Pause exponentiell verlängern, einen Zufallsversatz einstreuen, damit nicht alle gleichzeitig wieder anklopfen, und eine Obergrenze für die Versuche festlegen. Nur bei 429, 408 und 5xx wiederholen – bei 400 oder 403 nie, das sind eigene Fehler und keine Warteschlange. Eine mitgelieferte `retry-after`-Angabe hat immer Vorrang vor der eigenen Rechnerei. Und für das nächste Mal: Anthropic dokumentiert neben den Minutengrenzen noch Beschleunigungsgrenzen, die bei einem plötzlichen starken Anstieg der Nutzung greifen, und empfiehlt wörtlich, den Verkehr allmählich hochzufahren und gleichmäßig zu halten. Wer am Montagmorgen tausend Dokumente auf einmal durchjagt, den bremst nicht die Minutengrenze, sondern die Steigung.