Rate limits

Rate limits here are anti-abuse guardrails on the control plane, not usage quotas on your work. Nothing on this page meters how many issues the agent triages or how many CI minutes you burn — those are covered by your seat, and your only variable cost is your own token bill (see BYOK).

What is limited is how fast a client may call the API.

The buckets

Three sliding windows, all one minute wide.

The per-IP bucket is applied before your credential is resolved. That is deliberate: it bounds credential probing and keeps an unauthenticated flood from reaching the database at all.

Read and write are separate budgets, not a shared pool. Spending your ten writes does not stop you polling.

What counts as a write

By default, the class is the HTTP method: POST, PUT, PATCH and DELETE are writes, everything else is a read.

MCP is the exception. Every MCP call is a single POST /v1/mcp, so charging them all to the 10-per-minute write bucket would rate-limit read verbs like box list almost immediately. MCP requests are classified by the verb's scope instead: a read verb spends from the read budget.

Endpoints with their own limit

POST /v1/runners/heartbeat is not rate-limited. It is our own runner code on a 30-second cadence — two requests a minute per box — and throttling it would only produce false "box offline" readings.

What a 429 looks like

Errors are RFC 9457 problem details:

HTTP/1.1 429 Too Many Requests
content-type: application/problem+json
retry-after: 37

{
  "type": "https://api.developerz.ai/problems/rate-limit",
  "title": "Too Many Requests",
  "status": 429,
  "detail": "rate limit exceeded",
  "instance": "/v1/repos",
  "extensions": { "retry_after": 37 }
}

Back off for retry-after seconds. The same number is repeated inside extensions.retry_after so a client that only parses the body still has it.

There are no RateLimit-* headers

We do not emit RateLimit-Limit, RateLimit-Remaining, X-RateLimit-Reset, or any variant of them, on any response. If you are writing a client, do not build a budget tracker against headers that are not there — count your own calls, and treat the retry-after on a 429 as the authoritative signal.

This is called out explicitly because an earlier version of the API reference documented X-RateLimit-* headers and a 1000-per-minute per-account limit. Neither was ever implemented.

Limits you may feel that are not rate limits

Two other ceilings are easy to mistake for throttling:

• Concurrency. One paid seat admits one concurrent AI-dev runner. Work above that waits in the queue rather than being rejected. See billing.
• Spend caps. A monthly USD cap protects your own inference spend and pauses dispatch when it is reached; you get warning emails at 50% and 80% first.

Both are described on the billing page. Neither produces a 429.