Limite de rată
O limită de rată pe acest API este un plafon per bucket într-o fereastră fixă: limitatorul numără o cerere în procesul API, lasă primele să treacă și refuză următoarea cu 429 rate_limit_exceeded. Tabelul de mai jos este generat din același obiect pe care îl citește limitatorul, așa că fiecare număr de aici este o limită aplicată, nu un rezumat al unei intenții.
| Bucket | Limită | Fereastră | Contorizat |
|---|---|---|---|
| key_chat apeluri de inferență făcute cu o cheie API |
600 | 1 min | per cheie API |
| org_chat apeluri de inferență pentru o întreagă organizație |
1800 | 1 min | per organizație |
| platform apeluri API de platformă: organizație, chei, utilizare, urme, politici |
300 | 1 min | per cheie API |
| public_chat apeluri anonime în playground |
20 | 1 h | per adresă IP |
| public_page cereri pentru pagini publice |
300 | 1 h | per adresă IP — not enforced |
| public_card_request cereri de card de model trimise din formularul public |
5 | 1 h | per adresă IP |
| auth încercări de autentificare, înregistrare, recuperare și resetare a parolei |
20 | 15 min | per adresă IP |
A row marked as not enforced is defined in the limiter table but no request path checks it on this deployment. It is listed so the absence is visible rather than silent: a number in the documentation is not an applied limit.
Concurență
Cel mult 8 cereri pot fi în curs simultan pe o cheie API, contorizate per cheie și nu per organizație. O cerere peste acest număr este refuzată imediat cu același 429 — nu există nicio coadă de așteptare.
Cum arată un refuz
O cerere refuzată este HTTP 429 cu tipul rate_limit_error și codul rate_limit_exceeded. Această implementare nu setează niciun antet de răspuns retry-after și nici x-ratelimit-*, așa că corpul este singurul ceas: acolo unde limitatorul cunoaște sfârșitul ferestrei, mesajul se încheie cu acesta în ISO 8601 (Retry after 2026-10-06T12:00:00.000Z); mesajul per organizație nu indică deloc o oră. Așteptați acel moment sau aplicați backoff exponențial — o reîncercare mai devreme nu poate reuși, deoarece contorul se mișcă doar când fereastra se resetează. Tratați un 429 ca reîncercabil; orice altă eroare din această documentație necesită modificarea cererii înainte de a putea reuși.
Unde se află contorul
Ferestrele sunt contorizate în procesul API și scrise înapoi în tabelul rate_limits la fiecare 15 secunde și la oprire, astfel încât o repornire continuă fereastra în loc să ofere un buget nou. Plafonul care rezultă este declarat, nu descoperit: contorul este per nod API, așa că două noduri dublează fiecare limită efectivă. REDIS_URL este rezervat pentru versiunea partajată și încă nimic nu îl citește — rulați un singur nod API sau acceptați limite per nod.
Întrebări frecvente
What is a rate limit on this API?
A ceiling per bucket inside a fixed window. The limiter counts a request in the API process, lets the first 600 through inside a 1 min window on one API key, and refuses the next one with 429 rate_limit_exceeded. The window starts at the first request after the previous window ended, and every number in the table above is read from the object the limiter itself reads.
Which limit counts my chat calls — the key or the organization?
Both, and both have to pass. key_chat counts 600 inference calls per API key in 1 min, org_chat counts 1800 across the whole organization in the same window. A call that reaches either ceiling is refused, and the message says which one: the per-key message carries the window reset instant, the per-organization message does not.
Do I have to read the message to find out when to retry?
For a limit counted per key or per IP address, yes. This deployment sets no Retry-After header, so the reset instant inside the message text — an ISO 8601 timestamp taken from the limiter's own window end — is the only clock the response carries. For the per-organization limit the message names no time at all, so back off exponentially there. A retry before the window rolls cannot succeed: the counter only moves when the window does.
Is the counter shared across API nodes, or per process?
Per API process. Windows live in memory and are written back to the rate_limits table every 15 seconds and on shutdown, then restored on boot, so a restart continues a window instead of handing out a fresh budget. Two API nodes therefore double every effective limit. REDIS_URL is reserved for the shared version and nothing reads it yet, so run one API node or accept per-node limits.
Are all of these limits actually applied?
No. public_page is defined in the limiter table but no request path checks it on this deployment, and the table above marks it as not enforced for that reason. Every other row is named at a limiter call site, which is what applied means on this page.
How many requests may be in flight at once on one key?
8 at most. The count is kept per API key, raised when a call enters the chat handler and lowered when it finishes, and a request above the cap is refused at once with the same 429 rate_limit_exceeded — there is no queue behind it.