Every tenant is rate-limited independently, using a token bucket: 60 requests per minute by default, with bursts allowed up to that same number (a tenant who hasn't made a request in a while can spend their whole allowance at once, then waits for it to refill — the normal, expected behavior of a token bucket, not a bug). The bucket refills continuously rather than resetting once per fixed window, so there's no window boundary to time requests around for an extra burst.
This applies to POST /v1/ai/complete, checked against your per-tenant
bucket before anything else in the request runs
(before validation, before any balance check, before any database or
provider call) — a rate-limited request never spends anything else on its
way to being rejected.
An over-limit request gets:
{"error": "Rate limit exceeded — slow down and try again shortly"}
HTTP/1.1 429 Too Many Requests — captured from a real over-limit request
against a live gateway. There's no Retry-After header at this time; the
bucket refills continuously, so retrying after roughly 60 / limit
seconds (a fraction of a second at the default limit) will usually
succeed.
The 60/minute default is the gateway operator's global setting, but an operator can pin an individual tenant to a different limit (higher or lower) from the admin dashboard, independent of every other tenant's limit. A change like this takes effect on that tenant's very next request — there's no delay, and no need to wait for anything to reset. If you're consistently hitting your limit and need it raised, that's a conversation with your gateway operator, not something adjustable via the API itself.