Too many requests (429)
A 429 response means requests are arriving faster than allowed, or the model is busy. It is temporary. Wait the number of seconds in the Retry-After header, then try again, and spread out bursts of requests.
Which 429 is it?
| Code | Message | Cause |
|---|---|---|
rate_limited | ”Too many requests. Retry shortly.” | More than 600 requests in 60 seconds from one API key, or from one signed-in Syntic Code user. |
model_busy | ”The model is busy right now. Retry shortly.” | The model is limiting requests. |
capacity_busy | ”The model is very busy right now. Nothing was charged. Retry shortly.” | Syntic turned the request away before running it because capacity was full. Nothing was billed. |
Usage limits on your plan are different: they come back as 402 quota_exhausted. See Out of credits or over your limit.
How the rate limit works
The 600-requests-per-minute limit uses a sliding window, so room frees up gradually rather than all at once. On a 429 rate_limited response, these headers help you plan:
| Header | Meaning |
|---|---|
Retry-After | Seconds to wait before retrying. |
X-RateLimit-Limit | The limit for the window. |
X-RateLimit-Remaining | Requests left (0 here). |
X-RateLimit-Reset-Seconds | Seconds until the window has room again. |
What to do
- Wait for
Retry-After, then retry with a little random delay added so many clients do not retry at the same instant. - Smooth bursts with a queue in your own code instead of sending everything at once.
- Move large jobs that do not need an immediate answer to batches, which do not count against this limit.
- If
model_busykeeps happening, send less urgent work to a different model.
In the apps
- Syntic Code shows “Rate limited — retrying in …” and retries by itself. If the model stays busy, it suggests waiting a minute or picking another model with
/model. - Syntic Desktop shows “You’re sending messages quickly. Try again in a moment.”
Related
Was this page helpful?