Limits and the balance
Two things bound a request: the rate limits, which bound how fast a key and an account can spend, and the balance, which bounds how much can be spent at all.
Rate limits#
| Limit | Scope | Behaviour |
|---|---|---|
| Requests per minute | per key and per account | 0 means no per-key limit. A burst up to a whole minute is fine, and the allowance refills evenly |
| Tokens per minute | per key | An estimate of input plus the output the request may ask for. 0 means none |
| Daily and monthly spend cap | per key and per account | An optional cap in EUR on settled spend, per UTC day and per calendar month. Requests in flight still finish; past the cap the key is refused with 429 daily_cap_reached or monthly_cap_reached until the period turns |
| Concurrency | per account | At most 32 requests in flight by default. One more is a 429 rate_limited with a one second retry-after |
A key created without rates of its own starts with 60 requests and no token rate limit. Set a token rate on the key at any time; a lower one applies.
A refused request still carries the x-ratelimit-* headers: x-ratelimit-limit-requests, x-ratelimit-remaining-requests and x-ratelimit-reset-requests, and the same three for -tokens. A reset is a duration such as 1s, 6m0s or 120ms.
If a limit cannot be checked, the request is refused with a 503 rather than let through.
Endpoint scopes#
A key carries a set of scopes, and each /v1 endpoint needs the scope it belongs to. A request outside the key's set is refused 403 insufficient_scope, naming the scope to add.
| Scope | Endpoints |
|---|---|
inference | POST /v1/chat/completions, POST /v1/messages, POST /v1/responses and their token counters |
models | GET /v1/models |
usage | GET /v1/usage |
tools | POST /v1/tools/search and POST /v1/tools/browse |
A key created in the dashboard starts with inference and models. The dashboard sets and edits the scopes of a key. The MCP endpoint is not gated by them: it reads and writes a vault rather than generating.
The balance#
Credit is bought in crypto and kept in EUR. A request reserves its estimated cost before dispatch, the input plus the output it may ask for, and settles the real usage after. A balance that cannot cover the hold is a 402 insufficient_balance, and nothing reaches a model.
When the balance covers less output than the request asked for, the output cap is lowered to what it covers and x-token-notice says so. A hold that outlives its request is dropped after 15 minutes. A negative balance is owed and is offset against the next top-up.
The balance is the only limit on how much can be spent. There is no monthly allowance, no overage fee and no automatic refill. A refusal costs nothing.