Rate limits
60 requests per minute per key, the headers that tell you where you stand, and how to back off correctly.
60 requests a minute, counted per key, across both REST and MCP. Generous for a paid API — it exists to bound a runaway loop, not to ration you.
The limit
- 60 requests per minute per key. Fixed window, not a rolling one.
- Counted per key, not per account — five keys means five separate budgets, which is another reason to give each environment its own.
- Every call counts, including free ones: listing agents and reading your balance share the budget with runs.
- Need more? Ask. Per-key limits can be raised without a deploy.
Headers
| Header | Description |
|---|---|
X-RateLimit-Limit | Your ceiling for the current window |
X-RateLimit-Remaining | Requests left in this window |
X-RateLimit-Reset | Unix seconds when the window resets. Sent with a 429 |
Retry-After | Seconds to wait. Sent with a 429 — honour this rather than inventing a delay |
HTTP/1.1 429 Too Many Requests
Retry-After: 24
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1786742400
{ "error": "Rate limit exceeded.", "retry_after": 24 }Backing off properly
async function withBackoff(fn, tries = 3) {
for (let i = 0; i < tries; i++) {
const res = await fn();
if (res.status !== 429) return res;
// Guessing an interval is how a queue ends up hammering
// a limit it could have waited out once.
const wait = Number(res.headers.get("retry-after") ?? 60);
await new Promise((r) => setTimeout(r, wait * 1000));
}
throw new Error("Still rate limited after retries");
}// One request per second keeps a batch job comfortably inside 60/min.
for (const job of queue) {
await job();
await new Promise((r) => setTimeout(r, 1000));
}Credits are the real brake
The rate limit bounds speed; your balance bounds total spend. A stolen key cannot cost more than the credits sitting in the account — which is why a working balance is worth keeping modest and topping up as you go.
Counters are per instance, and reset on deploy
The limiter is in memory. On a multi-instance deploy the effective limit is a little looser than 60, and a deploy clears the window. Treat 60/min as the contract to design against, not a wall to probe.
Rate limiting applies identically to the MCP
server, where a tools/list is one request just like
a run.