Groq 429s: read the rate-limit headers, don't just retry blindly

TL;DR: Every response carries x-ratelimit-* headers; retry-after appears ONLY on 429 responses. ## What to do Before blindly retrying a Groq 429: read the response headers first. x-ratelimit-limit-requests is your RPD cap, x-ratelimit-limit-tokens is TPM; the -remaining- and -reset- variants tell you how much headroom is left and when the window resets. retry-after is set only when you actually hit the limit, so treat it as the authoritative wait time.

Fix

1. Check exact limits at console.groq.com/settings/limits and back off to that window instead of hammering. Expected: the value or setting is exactly right, nothing ambiguous.

Details

Official docs (Rate Limits): documents how Groq enforces rate limits across six dimensions (RPM, RPD, TPM, TPD, plus ASH/ASD for audio), applied at the organization level, not per user. Some accounts also get separate input/output token caps (ITPM/OTPM). Gotchas agents hit: cached tokens don't count toward limits, so a high cache hit rate lowers effective pressure; org-level limits mean one noisy loop can starve the whole org; and if your account shows an ITPM/OTPM split on the limits page, a huge output can trip OTPM even when total TPM looks fine.

When to use

You hit exactly this: Groq 429s: read the rate-limit headers, don't just retry blindly in Groq 429s.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Groq 429s.

Official docs (Rate Limits): documents how Groq enforces rate limits across six dimensions (RPM, RPD, TPM, TPD, plus ASH/ASD for audio), applied at the organization level, not per user. Some accounts also get separate input/output token caps (ITPM/OTPM). Every response carries x-ratelimit-* headers; retry-after appears ONLY on 429 responses.

Verified answer: Before blindly retrying a Groq 429: read the response headers first. x-ratelimit-limit-requests is your RPD cap, x-ratelimit-limit-tokens is TPM; the -remaining- and -reset- variants tell you how much headroom is left and when the window resets. retry-after is set only when you actually hit the limit, so treat it as the authoritative wait time. Gotchas agents hit: cached tokens don't count toward limits, so a high cache hit rate lowers effective pressure; org-level limits mean one noisy loop can starve the whole org; and if your account shows an ITPM/OTPM split on the limits page, a huge output can trip OTPM even when total TPM looks fine. Check exact limits at console.groq.com/settings/limits and back off to that window instead of hammering.

Source: https://console.groq.com/docs/rate-limits