Rate limits

How limits work

Different parts of the API are limited in different ways:

Endpoints	Counted per	Window	Over the limit
Chat completions, Responses and Messages (including count_tokens)	API key	Fixed minute, hour and day windows, aligned to UTC	429 naming the limit, for example Rate limit exceeded: <limit> requests/minute: in the error envelope with code RATE_5001, or for Messages in Anthropic’s envelope as a rate_limit_error
Embeddings and rerank	User (or IP address without a valid credential), per endpoint	Per minute	429 with {"detail": "...", "retry_after": 60} and Retry-After: 60
Platform API	User (or IP address without a valid credential)	Per minute	429 with {"detail": "Too many requests. Please try again later.", "retry_after": 60} and Retry-After: 60

• Per key or per user. The chat, Responses and Messages windows count each API key separately. The embeddings, rerank and Platform API limits count the person, so every key and console session of one user shares one budget.
• Not counted. Embeddings, rerank, batches and files do not count toward a key’s minute, hour and day windows. Batches and files are bounded by your credit and the batch size limits instead.
• Fails closed. By default, if BreachLine cannot reach the store that counts chat, Responses and Messages requests, they are refused with 429 (Rate limiter temporarily unavailable) rather than served without a limit.
• Concurrency. Some deployments also cap how many requests one principal can run at the same time. That limit returns 429 with a Retry-After header.

Limit values

The limit values are configured per deployment, so this guide does not list them. Read them from the API instead:

• A chat, Responses or Messages 429 names the limit it hit in its message, for example Rate limit exceeded: <limit> requests/minute.
• Platform API responses report the current limit in X-RateLimit-Limit.

Build clients that handle 429 as described below rather than assuming a fixed value. For questions about the limits on your account, contact BreachLine.

Headers

Endpoints	Headers
Chat completions, Responses and Messages	No X-RateLimit-* headers, and a 429 has no Retry-After. Wait for the next window: at most 60 seconds for the per-minute limit.
Embeddings and rerank	No X-RateLimit-* headers. A 429 carries Retry-After: 60.
Platform API	Responses carry X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset (a Unix time in seconds). A 429 carries Retry-After: 60.

A few frequently read Platform endpoints, such as /api/v1/users/me and the /api/v1/settings/ endpoints, are exempt from the per-minute limit and carry no X-RateLimit-* headers.

Staying inside the limits

• Retry 429 with exponential backoff and jitter, starting at about one second.
• Use one key per service, so one noisy job cannot use up another’s chat, Responses and Messages budget. Embeddings, rerank and Platform API budgets are shared by all of one user’s keys.
• On the Platform API, slow down as X-RateLimit-Remaining approaches zero, and wait for Retry-After after a 429.
• Batch bulk work with the Batches API instead of many parallel requests.
• Cache GET /v1/models (it is already cached for 60 seconds per key).
• Stream long answers rather than polling.