Snelheidslimieten

De limieten die deze deployment toepast, weergegeven op basis van de tabel die de limiter leest, met wat elke bucket telt.

Bucket Limiet Venster Geteld
key_chat
inferentieaanroepen met één API-sleutel
600 1 min per API-sleutel
org_chat
inferentieaanroepen over een hele organisatie
1800 1 min per organisatie
platform
platform-API-aanroepen: organisatie, sleutels, gebruik, traces, beleid
300 1 min per API-sleutel
public_chat
anonieme playground-aanroepen
20 1 h per IP-adres
public_page
openbare paginaverzoeken
300 1 h per IP-adres
public_card_request
modelcard-verzoeken vanaf het openbare formulier
5 1 h per IP-adres
auth
pogingen tot inloggen, registreren, wachtwoordherstel en wachtwoordreset
20 15 min per IP-adres

Gelijktijdigheid

Er mogen maximaal 8 verzoeken tegelijk onderweg zijn op één API-sleutel. Een verzoek daarboven wacht in plaats van te mislukken, tot de wachtrij vol is.

Hoe een weigering eruitziet

429 met code rate_limit_exceeded en type rate_limit_error. Er zijn vandaag geen x-ratelimit-* of retry-after-headers: het bericht noemt het tijdstip waarop het venster opnieuw begint, en dat is het enige signaal. Behandel een 429 als opnieuw te proberen met backoff; behandel elke andere fout in deze documentatie als een verzoek dat moet veranderen voordat het kan slagen.

Waar de teller staat

Vensters worden geteld in het API-proces en elke paar seconden teruggeschreven naar de database, zodat een herstart het venster voortzet in plaats van een nieuw budget uit te delen. Het plafond dat daaruit volgt wordt vermeld in plaats van ontdekt: de teller is per API-node, dus twee nodes verdubbelen elke effectieve limiet. REDIS_URL is gereserveerd voor de gedeelde versie en niets leest het nog — draai één API-node, of accepteer limieten per node.