Rate limits

Requests per minute, claims per day and claims per minute per credential, the headers that report them, what a 429 carries, and how to retry.

Last updated 12 September 2026

Rate limits

Three limits apply per credential, an API key, a connected MCP client, or a person using the playground. Each is reported on every response and each refusal says when to try again.

The three limits

| Limit | Pay as you go | Starter | Team | Scale | How it is counted | | --- | --- | --- | --- | --- | --- | | Requests per minute | 60 | 120 | 300 | 600 | A sliding window over the last minute. Every HTTP call counts. Over MCP only tools/call counts. | | Claims per minute | 60 | 120 | 200 | 300 | The claims a request carries: one for a claim check, the array length for bulk. Draft reviews are not counted here. | | Claims per day | 2,000 | 5,000 | 20,000 | 100,000 | Counted before the request runs, per UTC day, and refunded when the service fails. A draft review reserves its maxClaims up front and settles to what it checked. |

The claims-per-minute ceiling exists because the model provider's capacity is shared by every customer: one credential may not take more than its share of a minute. The day is the spend bound.

Per key. A workspace owner or admin sets requests per minute and claims per day on each key from the API keys page, up to the workspace's plan. A key made under a bigger plan is capped the moment the plan shrinks. A connected MCP client has no limits of its own and runs at the workspace's. A contract workspace keeps the limits Quorum set for it.

MCP handshake. Initialize, capability listings, pings, discovery and notifications are the protocol talking to itself. They are counted apart from your work, never against the limits above, and have their own lane of ten times your request limit with a floor of 300 a minute, refused with 429 protocol_rate_limited beyond it.

The headers

| Header | Meaning | | --- | --- | | RateLimit-Limit | Requests this credential may make per minute. | | RateLimit-Remaining | Requests left in the current minute. | | RateLimit-Reset | Seconds until the oldest counted request leaves the window. | | X-Claims-Limit | Claims this credential may check per UTC day. On responses that spent claims. | | X-Claims-Remaining | Claims left today. | | Retry-After | On a 429: seconds to wait before trying again. |

The refusals

| Code | Meaning | Retry | | --- | --- | --- | | rate_limited | Over the requests-per-minute limit. | After Retry-After, at most a minute. | | claims_rate_limited | Over the claims-per-minute ceiling. A single request carrying more claims than the whole minute allows is told to send fewer at once. | After Retry-After, or split the request. | | claim_budget_exhausted | The day's claims are spent. | At midnight UTC. Raise the key's limit if the plan allows. | | protocol_rate_limited | Too many MCP protocol messages in a minute. | After Retry-After. | | monthly_cap_reached | The month's credit cap, on a plan or metered. | On the first of the month, or an admin raises the cap. See Credits and billing. | | too_many_running | The review service has no room for another draft review right now. | After Retry-After. |

Every 429 carries Retry-After. A request the minute refuses gets its daily claims back. A request refused later keeps its minute, since the minute is about capacity and a refusal cost none of it.

Retrying well

  • Honour Retry-After. Retrying sooner spends the same window again.
  • Retry 429, 502, 503 and 504 with exponential backoff and jitter, starting at a second. Do not retry other 4xx responses: the request will fail the same way.
  • Claim checks are idempotent. A retried check costs a credit again, so wait for the first attempt's answer rather than firing two.
  • For volume, use POST /attest/v1/attest/bulk with up to 100 claims a call rather than 100 calls, and keep the array under your claims-per-minute figure.
  • For long reviews, let POST /attest/v1/attest/draft answer 202 and poll every few seconds. Polls are free and never count as claims.

Watching your limits

The Usage page shows, per credential, how much of this minute and today is spent, refreshed every few seconds, and the number of requests held back by a limit over the last day, week or month.

Still need help?

Ask Quincy in the chat bubble below, or write to support@quorumtech.ch and we will help you directly.