Usage

Rate limits and quota

Per key there are request and token ceilings per minute; per organisation the plan's monthly usage quota applies.

Limits per key

The values follow the organisation's plan and are operational ceilings against bursts, not a feature tier.

Plan	Requests / minute	Tokens / minute
Trial	60	200,000
Basic	60	200,000
Advanced	60	200,000
Ultra	300	1,000,000

Both surfaces count the same requests per minute per key. If you need more, spread load over several keys or talk to us.

Response headers

The App API sends three headers on every authenticated answer; on 429 additionally retry-after.

Header	Meaning
`x-ratelimit-limit`	Requests allowed in the current window.
`x-ratelimit-remaining`	Requests left in the window (absent when the counter is momentarily unavailable).
`x-ratelimit-reset`	Seconds until the next window starts (upper bound).
`retry-after`	Only on 429: seconds before a retry makes sense.

HTTP/1.1 429 Too Many Requests
retry-after: 60
x-ratelimit-limit: 60
x-ratelimit-remaining: 0
x-ratelimit-reset: 60

{ "error": { "code": "rate_limited", "message": "Too many requests. Retry after the indicated delay.", "request_id": "…" } }

Quota

Every organisation has a monthly usage quota derived from its plan and number of seats. API calls count against it. Once it is exhausted the API answers 429 budget_exceeded until the window resets.

Plans and quotas on the pricing page.

Recommendations

Back off exponentially on 429 and 503; honour retry-after.
Stream long answers — the connection stays lean and timeouts become rarer.
Request embeddings in batches rather than one by one.
One key per application: limits and consumption stay attributable.