Grok AI request limits — Grok API rate limits
Updated:
Handling Grok API 429 errors, gateway protection limits, and recommendations for high load.
How Grok API Dev limits work
| Where the limit applies | How it appears |
|---|---|
| Individual API key | Throttling can apply to one key without affecting the others. |
| Simultaneous requests | A group of parallel resource-intensive requests can trigger 429 for that key. |
| Overall gateway load | During traffic peaks, the gateway can temporarily slow down or reject new requests. |
| Large files and multimodal | Requests with heavy attachments can face stricter limits than regular text requests. |
We do not publish a strict RPM/TPM limits table. Effective throttling depends on the API key, concurrency, request size, and current gateway load.
If you need sustained high throughput, contact support and describe your traffic pattern.
Discuss your workload with support ↗How to handle HTTP 429
The primary external signal is the Retry-After header in a 429 response. It tells the client how many seconds to wait before trying again. Do not retry immediately: that creates another burst and can extend throttling.
Example response
HTTP
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 8
{
"error": {
"message": "Rate limit exceeded. Please retry later.",
"type": "rate_limit_error",
"code": "rate_limit_exceeded"
}
}The error text and fields can vary. Client logic should rely first on HTTP 429 and Retry-After rather than the wording of message.
- 1Limit concurrency with a queue or semaphore.
- 2Honor Retry-After when the server sends it.
- 3Without Retry-After, increase the delay after every attempt and add random jitter.
- 4Cap attempts; persistent 429s belong in monitoring, not an infinite loop.