Rate limits
Limits are per key, per minute, and shared between the REST API and the MCP server. Every response carries the headers, not just the refusals, so a client that reads them never has to discover its limit by hitting it.
Limits are per API key and per minute. They are the same number whichever transport you use: the REST API and the MCP server share one counter, so switching between them does not buy you a second budget.
| Caller | Limit | Window |
|---|---|---|
| An API key (REST or MCP) | 60 requests | rolling minute |
Unauthenticated discovery — /capabilities, /coverage, /quote | 60 requests per IP | rolling minute |
Pace yourself from the headers
Every response carries them, not just the refusals — a client that can see what it has left will pace itself, and one that finds out at 429 cannot.
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 57
X-RateLimit-Reset: 1788414540
X-RateLimit-Period: minute
# and on a 429 only
Retry-After: 24Do not poll faster than you are told
Every task read returns poll_after_s. It is not a suggestion: before it elapses nothing can have changed, so an earlier read spends your budget to learn the same thing. A sandbox task returns small values because it really does finish in about 60 seconds; a live one returns minutes. Better still, register a webhook and stop polling entirely.
The sandbox is free and is not metered separately — it shares the same per-key limit, and it writes no ledger row.