Groq Free Tier Limits Explained: RPM, RPD, TPM and Daily Caps

Groq is one of the few inference providers that publishes free-tier limits per model, in numbers specific enough to do arithmetic with. That is unusually useful, and it is why Groq keeps showing up as the fast path in free-tier architectures. It is also why the arithmetic is worth doing properly: the numbers are small, and the interesting question is not "how many tokens do I get" but "which of the four caps do I hit first".

This breakdown uses Groq's own rate-limit documentation as the source of truth, applies real arithmetic to each cap, and flags the places where the published table and your actual account diverge.

What are Groq's free developer tier rate limits?

Groq publishes base developer-plan limits in a per-model table. As re-checked on the provider's rate-limit page, the headline rows look like this:

Source: Groq rate limits documentation↗.

Two sentences from that page deserve to be quoted in spirit rather than paraphrased, because they change how you read every number above:

• "Rate limits apply at the organization level, not individual users."
• "You can hit any limit type depending on which threshold you reach first."

Groq also warns that the published table is a high-level summary with possible exceptions, and that the authoritative numbers for your account live on the Limits page in your account settings. Treat the table as a planning estimate and the console as the contract.

How we verified this

We read Groq's rate-limits documentation↗ directly on 2026-09-17 and transcribed the per-model values above from that page, along with the organization-level scoping statement, the cached-token exclusion and the response-header table used later in this article. We did not invent or extrapolate any figure: where the documentation publishes a value, we cite it; where it publishes a note that audio models use a separate limit basis, we say so rather than converting units ourselves. One thing worth noting for anyone comparing screenshots of this page over time: these values have moved. Earlier published snapshots showed a substantially higher per-minute request ceiling on the prompt-guard models and a much lower one on the Whisper turbo model than the current table. That volatility is the reason we link the source instead of hard-coding a number into a decision.

Three structural facts that matter more than any single number

1. Limits are per model, not per account. Each model carries its own pool. A guard model with a 14,400 daily request ceiling and a large daily token allowance is not interchangeable with the main chat model's 1,000-request pool. A workload that mixes models draws from several meters at once, and a workload that routes everything through one model can exhaust that model's pool while the rest of your account sits idle.

2. Limits are per organization. Everyone using your organization shares one pool, across every key. For a solo developer this is convenient, because all of your own projects draw on the same allowance. For a team it is a footgun: five teammates on one organization means five people competing for the same 1,000 daily requests, and the 429s will look random until you realise who is sharing the meter.

3. Cached tokens are excluded. Groq's documentation is explicit that tokens served from the cache do not count towards rate limits. This is the single most underrated line on the page, because it changes the achievable request count by an order of magnitude for the right workload shape. We do the arithmetic below.

A fourth mechanic to know: some organizations also carry separate per-minute limits on input tokens and output tokens in addition to the combined per-minute token cap. If that applies to your account, the Limits page shows your token figure with an "X in / Y out" breakdown on hover; if there is no breakdown, you have a single combined per-minute cap.

What 30 requests per minute and 1,000 requests per day actually buy

The two headline numbers constrain completely different things. Confusing them is why teams either over-engineer or get surprised.

The daily cap (1,000 requests) is the sustained-work ceiling. At 100 requests per hour you have ten hours of continuous operation, or a full working day of an interactive tool with realistic idle gaps. Convert that into agent work: a fifty-turn agent session where each turn includes a planning call, one or two tool calls and a final response costs roughly 100 to 300 requests, because every tool round-trip is a separate request. That puts the daily cap at roughly three to ten agent sessions per day, which is a reasonable allowance for evaluation and demos and a hard wall for anything customer-facing.

The minute cap (30 RPM) is the burst ceiling. Sequential usage fits comfortably. Fan-out does not. An agent that fires five parallel tool calls, six times in a row, has just consumed thirty requests inside one minute. Parallelism is where free tiers die first, and 30 RPM is essentially "sequential, plus a little room".

The token caps (8,000 per minute, 200,000 per day) are the context-length ceiling. This is the constraint most people get wrong, because running out of tokens feels like running out of requests. Consider a long-context workload using 8,000 input tokens and producing 1,000 output tokens per request, with no caching:

• Metered tokens per request: 8,000 + 1,000 = 9,000
• Daily request ceiling from the token pool: 200,000 ÷ 9,000 ≈ 22 requests per day

Twenty-two. Well below the 1,000-request ceiling, and well below what most people assume when they read "1,000 requests per day". For long-context work, the daily token pool is the binding constraint, not the request count.

There is a per-minute version of the same effect. Groq evaluates each limit type independently and you are constrained by whichever you reach first. Thirty requests carrying a hundred tokens each totals only 3,000 tokens — far under the 8,000-token per-minute ceiling — yet it hits the per-minute request ceiling exactly. Conversely, a single request carrying 9,000 tokens blows the per-minute token ceiling while using one request out of thirty. Both are rate-limit errors; neither looks like the other.

How cached tokens change the math

Now re-run the long-context scenario with a stable prefix. Suppose your system prompt plus tool schemas total 4,000 tokens, and those 4,000 tokens are served from cache on every request. Only the uncached remainder is metered.

The cached-prefix row is worth pausing on. By keeping the expensive part of the prompt stable and varying only a short user turn, metered tokens per request fall from 9,000 to 1,000 — roughly a nine-fold increase in daily request capacity, from about 22 to about 200 requests per day. The per-minute token cap then becomes your constraint during bursts: 8,000 tokens per minute at 1,000 metered tokens per request means roughly eight requests per minute, well under the 30 RPM ceiling.

The practical design rules that fall out of this:

• Keep long, stable prefixes stable. Every byte you change at the front of the prompt invalidates the cached portion and pushes you back toward the 22-requests-per-day regime.
• Put variable content at the end. Retrieved documents and user messages belong after the invariant system prompt and tool definitions.
• Check model support first. Prompt caching is available on some models and not others, and the cache-hit behaviour is described on Groq's caching documentation and each model's card. Do not assume the exclusion applies to a model that does not cache.

How to read Groq's rate-limit response headers

Groq returns rate-limit state on responses, which means you can build a router that stops before it fails instead of after. The documented headers are:

A defensive client reads them once per request and pauses pre-emptively:

[object Object]

The important detail is the asymmetry: a nearly exhausted per-minute window wants a short sleep, because it refills in seconds; a nearly exhausted daily request budget wants a provider switch, because it refills on a clock measured in hours. Treating both as "retry with backoff" is how a project spends an afternoon earning 429s it could have avoided.

What the Groq free tier is not for

• Not for team sharing. One organization, one pool. Five developers on one organization means five people exhausting the same 1,000 daily requests, and the resulting errors will look like intermittent platform problems rather than contention. Either separate organizations or accept the contention explicitly.
• Not for production base load. Groq describes these values as base limits for the Developer plan and points users to an upgraded Developer plan for higher limits plus Batch and Flex processing. The structure — organization-level, per-model, upgradeable — tells you what the free tier is: an evaluation and prototyping surface.
• Not for high-fanout agents. Parallel tool calling is the first thing to exhaust 30 requests per minute. Sequential agents fit; tree-of-thought agents and wide retrieval loops do not.
• Not for long-context pipelines without caching. As the arithmetic above shows, 8,000-token requests give you roughly 22 requests per day. If your pipeline reads long documents per request and cannot cache a stable prefix, the daily token pool will define your throughput.

The pairing that makes Groq work well

The most useful role for Groq's free tier is a latency spike absorber with a short-context, cache-friendly profile, not a base load. A pattern that follows directly from the published numbers:

The design principle is the same one that governs all free-tier failover: the useful partner is the one whose limiting meter is idle while yours is maxed.

Limitations worth repeating

• The published table is a summary, not a guarantee. Groq says so directly. Your console is authoritative.
• Audio and speech models use a different limit basis from text models, and the current documentation lists separate audio limits for those models. Do not convert between them.
• Effects of caching depend on stability. One change early in the prompt and the exclusion stops helping.
• Organization pooling is invisible by default. Add a dashboard before you add teammates.
• Free-tier capacity is not contractual. Plan a graceful degradation path — a queued job that retries after a reset is a far better user experience than an error.

FAQ

Does exceeding one Groq limit block all models? No. Limits are per model, so exhausting one model's pool does not consume another's. That is also why routing across models is a legitimate relief valve rather than a trick.

Do requests or tokens reset first? Both are window-based. Request and token ceilings reset on their own schedules, and the reset headers tell you how long remains for each. Read them rather than guessing.

Can I raise the limits without paying for a full production plan? Groq points to an upgraded Developer plan that raises the ceilings and adds Batch and Flex processing, with higher limits available for select workloads. Check the current plan details on Groq's console limits page↗, because the tier structure changes.

Is latency the reason to use Groq's free tier at all? For interactive, short-context, cache-friendly requests, speed is the differentiator, and it is why the tier works best as the fast path in a multi-provider design rather than as the only path.

What is the single most common mistake with these limits? Assuming the 1,000-request ceiling is the limit that will bind. For long-context work, the 200,000-token daily pool binds first — often at around twenty requests — and for fan-out work, the 30-request per-minute ceiling binds first. Request count is the number people quote and the least likely number to be the one that stops them.

Where this sits in the directory

Groq's numbers are small but documented, per-model and honestly metered, which makes it one of the few free tiers you can architect against with confidence rather than hope. The Groq entry in the directory carries the full limit table, the console link where your organization's exact numbers live, and the same treatment for the other free tiers you would pair it with.