Rate limits & tiers

Per-key limits (live today)

The per-key request limit is tiered by payment state, not by plan: every account starts at 60 req/min, and one successful top-up or card verification lifts the account to 180 req/min permanently (the Dodo payment.succeeded webhook sets the flag). The 429 message tells you which tier you hit.

The max_tokens ceiling is model-scoped: glm-5.3 and deepseek-v4-flash serve long-form output up to 65,536 tokens; qwen3.8-flash caps at 32,768. The cap a model enforces is the same one GET /api/v1/models advertises in max_length.

Over-limit requests get 429 with a Retry-After header. The limiter is atomic and multi-instance safe — it counts in the billing database, not in any single server's memory.

All dialects, same limits

OpenAI-dialect (/v1/chat/completions), Anthropic-dialect (/api/messages), and Responses-API (/v1/responses) calls are enforced through the same limiter and per-key caps — switching SDKs is never a way around a limit.

Spend caps (optional, per key)

At key creation you can set a daily spend cap. Once the key's 24h spend crosses the cap, requests fail with 402 daily_cap — even if the account balance is healthy. This is the blast-radius control for agent workloads: if a prompt loop runs away, the damage stops at the cap.

Model caps

Some models cap the per-request estimate (reasoning models with huge context can estimate high). If a request's worst-case exceeds the cap you'll get 400 est_too_large — lower max_tokens or pick a bigger-balance account.

Retry posture

• 429 — honor Retry-After, exponential backoff with jitter
• 503 upstream_warming — retry after the Retry-After header value (seconds; the autoscaler is provisioning capacity)
• 502 upstream_error — safe to retry immediately; the failed attempt was refunded
• Idempotency: retries create fresh reservations, so failed attempts can't double-charge even if you retry in a tight loop