Rate limits
The limits this deployment applies, rendered from the table the limiter reads, with what each bucket counts.
| Bucket | Limit | Window | Counted |
|---|---|---|---|
| key_chat inference calls made with one API key |
600 | 1 min | per API key |
| org_chat inference calls across a whole organization |
1800 | 1 min | per organization |
| platform platform API calls: organization, keys, usage, traces, policies |
300 | 1 min | per API key |
| public_chat anonymous playground calls |
20 | 1 h | per IP address |
| public_page public page requests |
300 | 1 h | per IP address |
| public_card_request model card requests sent from the public form |
5 | 1 h | per IP address |
| auth sign-in, sign-up, password recovery and reset attempts |
20 | 15 min | per IP address |
Concurrency
At most 8 requests may be in flight on one API key at a time. A request above that waits rather than failing, until the queue is full.
What a refusal looks like
429 with code rate_limit_exceeded and type rate_limit_error. There are no x-ratelimit-* or retry-after headers today: the message names the window reset time, and that is the only signal. Treat a 429 as retryable with backoff; treat every other error in this documentation as a request that has to change before it can succeed.
Where the counter lives
Windows are counted in the API process and written back to the database every few seconds, so a restart continues the window instead of handing out a fresh budget. The ceiling that follows is stated rather than discovered: the counter is per API node, so two nodes double every effective limit. REDIS_URL is reserved for the shared version and nothing reads it yet — run one API node, or accept per-node limits.