A 429 from Groq means you've exceeded a rate limit — but Groq is unusually transparent about how close you are before that happens, and most recurring 429s are avoidable once you're actually watching what it already tells you on every request.
Groq reports your remaining budget on every successful response
Every response carries a set of x-ratelimit headers — limit and remaining counts for both requests and tokens, plus a reset time for each — so you can see exactly how much headroom is left before you ever hit a 429, not just after. A client that only reacts to the 429 itself, rather than watching these headers and backing off proactively as remaining requests or remaining tokens approach zero, is choosing to find out about the limit the hard way every time.
Limits are per model and per organization — not per person or per key
Rate limits in Groq are scoped to a specific model and to your organization as a whole, not to an individual user or API key. Multiple team members, or multiple keys issued for different services, all draw from the same per-model pool — so a 429 can show up on an integration that, on its own, looks well within budget, because something else in the same org is consuming the shared allowance for that model.
A rate limit (429) and a spend limit (400) are different errors
Exceeding your RPM/TPM ceiling returns a 429 with a retry-after header telling you how long to wait, in seconds. Hitting a configured spend limit is a different failure entirely: a 400 with the code blocked_api_access, applied organization-wide across every API key until the limit is raised — retrying doesn't help, and there's no retry-after header to honor because it isn't that kind of error. Raising your spend limit in your account settings is the only real fix for that one.
Cached tokens don't count against your limit, and neither does Batch
Tokens served from Groq's cache don't count toward your rate limit at all, so leaning on caching where your traffic allows it is a throughput lever as well as a cost one — the same pattern that shows up on OpenAI and Anthropic. Separately, the Batch API runs on its own processing window with its own limits, entirely outside the synchronous RPM/TPM pool, so genuinely non-interactive, high-volume work fits there instead of competing with live traffic for the same ceiling.
If On-Demand headroom is not enough, Flex trades reliability for throughput
Groq's default On-Demand tier gives predictable speed but can queue under peak load; the Flex tier offers higher throughput limits as a best-effort service, meaning it can return its own over-capacity errors since that extra headroom isn't guaranteed capacity. An Auto setting picks whichever tier is available for your account automatically, and upgrading from the Free to the Developer plan raises baseline limits across the board regardless of which service tier is chosen.