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.