Rate limits
// two meters, one ceiling each
Every request is rate-limited, but which ceiling applies depends on how the key is metered. A key on credit metering is bounded by your workspace's tier rate limit, or by its own lower per-key override if you set one. A key attached to an unlimited pass is bounded by that pass's cap — which is pooled: every key on the same pass draws from one bucket. Both return 429 rate_limited, and neither is ever billed.
| Meter | Scope | Limit |
|---|---|---|
| credits | per key, capped by your workspace tier | your tier's solves/sec (or the key's own lower override) |
| pass | per pass — shared by every attached key | the plan's limit / window, e.g. 600 / 30s |
Both your current tier rate and any pass cap are shown in the dashboard under Settings → Usage & limits, alongside live utilisation.
Every solve response carries the ceiling, so you can pace proactively instead of discovering it by hitting it:
| Header | Example | Meaning |
|---|---|---|
| RateLimit-Limit | 600 | requests permitted in the current window |
| RateLimit-Remaining | 3 | requests left in the current window |
| RateLimit-Reset | 12 | whole seconds until a slot frees |
| RateLimit-Policy | 600;w=30 | the policy in force — limit;window seconds |
| Retry-After | 12 | 429 only — whole seconds to wait. Always at least 1. |
A cap is not a quota. Hitting it costs you nothing and doesn't consume the pass. Back off for the window and you're through the gate again. Both official SDKs honour Retry-After automatically.
Ready to pour through the gate?
// free sandbox keys · no card required to start