Title: Rate limit LLM : cl%C3%A9, organisation et IP %E2%80%94 LLM EU
Canonical: https://llmeu.com/fr/docs/rate-limits/
Markdown mirror: https://llmeu.com/fr/docs/rate-limits.md
Machine-readable: https://llmeu.com/llms.txt (index) - https://llmeu.com/llms-full.txt (full catalogue) - https://llmeu.com/llms-catalogue.json

Premiers pas

- [D%C3%A9marrage rapide](/fr/docs/quickstart/)
- [Console](/fr/docs/console/)
- [Migration](/fr/docs/migration/)
- [R%C3%A9f%C3%A9rence de l'API](/fr/docs/api/)

R%C3%A9f%C3%A9rence

- [Authentification](/fr/docs/authentication/)
- [Points de terminaison](/fr/docs/endpoints/)
- [Erreurs](/fr/docs/errors/)
- [Limites de d%C3%A9bit](/fr/docs/rate-limits/)
- [Streaming](/fr/docs/streaming/)
- [Politiques](/fr/docs/policies/)
- [Routage et politique](/fr/docs/routing/)
- [R%C3%A9sidence et r%C3%A9gions](/fr/docs/residency/)
- [Preuves et v%C3%A9rification](/fr/docs/evidence/)
- [Compatibilit%C3%A9 OpenAI](/fr/docs/openai-compat/)

Exploitation

- [Auto-h%C3%A9bergement](/fr/docs/self-hosting/)

# Limites de d%C3%A9bit

Une limite de d%C3%A9bit sur cette API est un plafond par compartiment dans une fen%C3%AAtre fixe : le limiteur compte une requ%C3%AAte dans le processus API, laisse passer les premi%C3%A8res et refuse la suivante avec 429 rate_limit_exceeded. Le tableau ci-dessous est g%C3%A9n%C3%A9r%C3%A9 %C3%A0 partir du m%C3%AAme objet que celui lu par le limiteur, donc chaque nombre ici est une limite appliqu%C3%A9e et non le r%C3%A9sum%C3%A9 d'une intention.

A row marked as not enforced is defined in the limiter table but no request path checks it on this deployment. It is listed so the absence is visible rather than silent: a number in the documentation is not an applied limit.

## Concurrence

Au plus 8 requ%C3%AAtes peuvent %C3%AAtre en cours sur une cl%C3%A9 API %C3%A0 la fois, compt%C3%A9es par cl%C3%A9 et non par organisation. Une requ%C3%AAte au-del%C3%A0 est refus%C3%A9e imm%C3%A9diatement avec le m%C3%AAme 429 %E2%80%94 il n'y a pas de file d'attente.

## %C3%80 quoi ressemble un refus

Une requ%C3%AAte refus%C3%A9e est HTTP 429 avec type rate_limit_error et code rate_limit_exceeded. Ce d%C3%A9ploiement ne d%C3%A9finit ni retry-after ni en-t%C3%AAtes de r%C3%A9ponse x-ratelimit-*, donc le corps est la seule horloge : lorsque le limiteur conna%C3%AEt la fin de fen%C3%AAtre, le message se termine par celle-ci au format ISO 8601 (Retry after 2026-10-06T12:00:00.000Z) ; le message par organisation n'indique aucun moment. Attendez cet instant ou appliquez un backoff exponentiel %E2%80%94 r%C3%A9essayer plus t%C3%B4t ne peut pas r%C3%A9ussir, car le compteur n'avance que lorsque la fen%C3%AAtre tourne. Consid%C3%A9rez un 429 comme r%C3%A9essayable ; toute autre erreur dans cette documentation n%C3%A9cessite que la requ%C3%AAte change avant de pouvoir r%C3%A9ussir.

## O%C3%B9 r%C3%A9side le compteur

Les fen%C3%AAtres sont compt%C3%A9es dans le processus API et r%C3%A9%C3%A9crites dans la table rate_limits toutes les 15 secondes et %C3%A0 l'arr%C3%AAt, donc un red%C3%A9marrage continue la fen%C3%AAtre au lieu de distribuer un nouveau budget. Le plafond qui en d%C3%A9coule est %C3%A9nonc%C3%A9 plut%C3%B4t que d%C3%A9couvert : le compteur est par n%C5%93ud API, donc deux n%C5%93uds doublent chaque limite effective. REDIS_URL est r%C3%A9serv%C3%A9 %C3%A0 la version partag%C3%A9e et rien ne le lit encore %E2%80%94 ex%C3%A9cutez un seul n%C5%93ud API, ou acceptez des limites par n%C5%93ud.

## Questions fr%C3%A9quentes

### What is a rate limit on this API?

A ceiling per bucket inside a fixed window. The limiter counts a request in the API process, lets the first 600 through inside a 1 min window on one API key, and refuses the next one with 429 rate_limit_exceeded. The window starts at the first request after the previous window ended, and every number in the table above is read from the object the limiter itself reads.

### Which limit counts my chat calls %E2%80%94 the key or the organization?

Both, and both have to pass. key_chat counts 600 inference calls per API key in 1 min, org_chat counts 1800 across the whole organization in the same window. A call that reaches either ceiling is refused, and the message says which one: the per-key message carries the window reset instant, the per-organization message does not.

### Do I have to read the message to find out when to retry?

For a limit counted per key or per IP address, yes. This deployment sets no Retry-After header, so the reset instant inside the message text %E2%80%94 an ISO 8601 timestamp taken from the limiter's own window end %E2%80%94 is the only clock the response carries. For the per-organization limit the message names no time at all, so back off exponentially there. A retry before the window rolls cannot succeed: the counter only moves when the window does.

### Is the counter shared across API nodes, or per process?

Per API process. Windows live in memory and are written back to the rate_limits table every 15 seconds and on shutdown, then restored on boot, so a restart continues a window instead of handing out a fresh budget. Two API nodes therefore double every effective limit. REDIS_URL is reserved for the shared version and nothing reads it yet, so run one API node or accept per-node limits.

### Are all of these limits actually applied?

No. public_page is defined in the limiter table but no request path checks it on this deployment, and the table above marks it as not enforced for that reason. Every other row is named at a limiter call site, which is what applied means on this page.

### How many requests may be in flight at once on one key?

8 at most. The count is kept per API key, raised when a call enters the chat handler and lowered when it finishes, and a request above the cap is refused at once with the same 429 rate_limit_exceeded %E2%80%94 there is no queue behind it.