Rate Limits
Die Limits dieser Installation, gerendert aus der Tabelle, die der Limiter liest, mit der Angabe, was jeder Eimer zählt.
| Eimer | Limit | Fenster | Gezählt |
|---|---|---|---|
| key_chat Inferenz-Aufrufe mit einem API-Schlüssel |
600 | 1 min | pro API-Schlüssel |
| org_chat Inferenz-Aufrufe einer ganzen Organisation |
1800 | 1 min | pro Organisation |
| platform Aufrufe der Plattform-API: Organisation, Schlüssel, Verbrauch, Traces, Richtlinien |
300 | 1 min | pro API-Schlüssel |
| public_chat anonyme Playground-Aufrufe |
20 | 1 h | pro IP-Adresse |
| public_page Aufrufe öffentlicher Seiten |
300 | 1 h | pro IP-Adresse |
| public_card_request Modellkarten-Anfragen aus dem öffentlichen Formular |
5 | 1 h | pro IP-Adresse |
| auth Anmelde-, Registrierungs-, Wiederherstellungs- und Zurücksetzungsversuche |
20 | 15 min | pro IP-Adresse |
Parallelität
Pro API-Schlüssel dürfen höchstens 8 Anfragen gleichzeitig laufen. Eine Anfrage darüber wartet, statt zu scheitern, bis die Warteschlange voll ist.
Wie eine Ablehnung aussieht
429 mit dem Code rate_limit_exceeded und dem Typ rate_limit_error. Header wie x-ratelimit-* oder retry-after gibt es derzeit nicht: Die Meldung nennt den Zeitpunkt des Fensterwechsels, und das ist das einzige Signal. Behandeln Sie 429 als wiederholbar mit Backoff; jeden anderen Fehler in dieser Dokumentation als Anfrage, die sich ändern muss, bevor sie gelingen kann.
Wo der Zähler lebt
Fenster werden im API-Prozess gezählt und alle paar Sekunden in die Datenbank zurückgeschrieben, damit ein Neustart das Fenster fortsetzt statt ein frisches Budget auszugeben. Die daraus folgende Grenze wird benannt statt entdeckt: Der Zähler gilt pro API-Knoten, zwei Knoten verdoppeln also jedes wirksame Limit. REDIS_URL ist für die gemeinsame Variante reserviert, und noch liest es niemand — betreiben Sie einen API-Knoten oder akzeptieren Sie Limits pro Knoten.