Rate limits
Rikaii uses token buckets so shared infrastructure stays reliable. Developer-facing documentation here covers POST /v1/chat/completions only—that is the RPM surface you integrate against from your servers.
Dashboard-only actions (saving BYOK secrets, editing profile, API key CRUD) have separate internal throttles; they are not part of the public Chat API contract and may change without notice on this page.
Chat completions — requests per minute
POST /v1/chat/completions is metered per workspace (resolved from the API key → owning account) using a one-minute sliding window.
Default tiers
| Plan | Requests per minute (RPM) |
|---|---|
| Standard (pay-as-you-go, non‑Pro) | 60 |
| Pro | 120 |
Workspace RPM override (support / operations)
The database may store a custom RPM (positive integer) on your workspace. When present, the gateway uses that value as the per-minute bucket capacity for all API keys on the account (minimum 1 RPM). When it is empty, defaults apply: 120 RPM for Pro, 60 for Standard (non‑Pro).
You cannot set this in the Dashboard or public API—there is no customer-facing control wired to this field in the app or gateway today. Values are applied by Rikaii operations / support (for example capacity planning). If you need a different sustained throughput, email support@rikaii.com.
No quota hint headers on 429
When chat RPM is exceeded, the gateway returns 429 Too Many Requests with an OpenAI-compatible JSON body (error.code typically rate_limit_exceeded). The response does not include reliable Retry-After, X-RateLimit-Remaining, or similar quota headers—implement exponential backoff with jitter and treat the JSON message as advisory copy, not a machine quota clock.
HTTP behavior
- 429 — Workspace chat RPM exceeded; slow down and retry.
- 503 — Rate-limiting backend temporarily unavailable; limits fail closed (the gateway refuses traffic rather than bypassing limits).
Best practices
- Cap concurrent outbound calls; serialize bursty fan-out jobs.
- On 429, back off exponentially (for example 0.5s → 1s → 2s …) with random jitter; do not tight-loop the same payload.
- For long-running workloads, batch prompts or use streaming without opening more concurrent requests than your RPM allows.