LearnGrokA 429 is not a bug. It is the API telling you that you asked for more than your team's current allowance for that model, and it is a normal operating condition at any real volume.
First: work out which limit you hit
Limits are expressed in two dimensions, per model and per team: a request rate and a token rate. They have different fixes, so it is worth knowing which one you are hitting.
- Request rate is hit by many small calls. It is expressed per second rather than per minute. That is deliberate, so that you cannot spend a whole minute's budget in the first second. Batch or queue.
- Token rate is hit by fewer, larger calls. Shrink the payload.
The token side has a detail that catches people out: cached prompt tokens still count toward your token rate, even though they are billed more cheaply. Prompt caching is a cost optimisation, not a rate-limit optimisation. Reasoning tokens and image or audio input tokens count too.
Your live per-team numbers are in the xAI console, and the current published caps are on the rate limits page. Do not hard-code an assumed limit: they differ sharply between model families, and the gap between the largest and smallest is more than an order of magnitude.
Retry properly: nothing will tell you when
The documentation describes no retry header and no Retry-After on a 429. The
schedule is entirely yours to choose, so choose it deliberately:
- Back off exponentially. Wait, then double the wait on each subsequent failure. xAI's own examples use a doubling delay with a small maximum number of attempts.
- Add jitter. Without randomisation, every client that failed together retries together and rebuilds the spike.
- Cap the retries, then fail the request properly and surface it. Unbounded retry loops hide the problem until the invoice arrives.
Raising the ceiling
Three documented routes, and the first is passive:
- Tiers rise with cumulative spend, measured since the start of 2026, and counting both prepaid credit and paid invoices. They upgrade automatically and never downgrade, so a tier once earned is kept.
- Ask. The console has a route to request an increase without waiting for the spend to accumulate.
- Contact sales for enterprise capacity.
Two caveats. Tiering applies to text and embedding models; image, video and voice increases go through sales instead. And a new team starts at the bottom tier, which is worth knowing before you plan a launch around a load test.
Two things that are not rate limits
Batch work does not count toward your rate limits at all. If the job is not latency-sensitive, moving it to the batch surface sidesteps this entire problem and is billed at a discount. Batch has its own separate ceilings on submission rate and payload size.
Running out of credit is a different rejection. If your billing limit is exhausted, requests are refused for that reason rather than for rate. If a 429 appears with no traffic change, check the balance before you rewrite the client.
If it appears suddenly
Look for a retry storm, a scheduled job overlapping itself, or a deployment that doubled your worker count. A rate-limit error without a traffic increase is usually one of those three.
What changes
Tier thresholds and per-model caps change, and the caps are model-specific. Read the current figures from the rate limits page and your console rather than from any third-party page, including this one.
