Summary

  • GroqCloud's own documentation measures throughput in eight named units at the organisation level and then sends readers to their own account settings for the number that actually applies, which makes the public page a measurement convention before it is a ceiling.
  • Two distinct failure signals are published for two distinct causes — 429 when a measured rate is exceeded, 498 when Flex capacity is unavailable — and the document that could convert either into a contractual obligation was not among the pages retrieved for this review.

A limit is a measurement convention before it is a number

The rate-limits page opens by naming what it counts rather than how much it allows. The retained excerpt reads: “Rate limits are measured in: RPM: Requests per minute RPD: Requests per day TPM: Tokens per minute TPD: Tokens per day ASH: Audio seconds per hour ASD: Audio seconds per day ITPM: Input tokens per minute OTPM: Output tokens per minute.”

That list is more informative than a single throughput figure would be. Eight dimensions, not one, means the envelope has eight walls. Two of them are denominated in audio seconds, which tells you speech models are metered on a different clock from text models. Two split token accounting into input and output, which matters because prompt-heavy and generation-heavy workloads draw on different budgets. And two are daily rather than per-minute, which means a burst can be survivable in the short term and still exhaust the day.

The same page fixes the aggregation level and the tie-break rule in its own words: “Rate limits apply at the organization level, not individual users. You can hit any limit type depending on which threshold you reach first.” It also states that “Cached tokens do not count towards your rate limits,” which is a real allowance for anyone running repeated prompts with a stable prefix.

Put those three statements together and the practical shape of the constraint appears. Ten services, five teams and one batch backfill behind a single organisation share one envelope. The binding wall is whichever one trips first, and no published page tells a specific operator which wall that will be, because the numbers are not on it.

The number that applies is delegated to a page behind login

The documentation does not leave the reader without direction. As the page is rendered, it advises that limits may have exceptions and that current, exact limits should be read on the limits page inside the reader's own account settings. That instruction is the most consequential sentence in the whole set, and it is also the reason this review cannot state any organisation's threshold: the page it points to sits behind authentication and was not read here.

What remains public is a convention plus a routing instruction. A team can learn the units, the aggregation level and the tie-break from the open web. It cannot learn its own ceiling from the open web, and a third party assessing the service — a procurement analyst, a journalist, a competitor sizing a displacement pitch — cannot either.

One plan publishes a base; every other limit is described only as higher

The model catalogue is where numbers actually appear, and it scopes them carefully: “Need higher rate limits? Upgrade to Developer plan to access higher limits, Batch and Flex processing, and more. Note that the limits shown below are the base limits for the Developer plan, and higher limits are available for select workloads and enterprise use cases.”

Three things follow. The published table is a floor for one plan, not a ceiling for the service. Higher limits are described as existing for unnamed select workloads and enterprise cases, which makes them a negotiated outcome rather than a published one. And the phrase “base limits” concedes variance without stating its dimensions.

That concession is why the pricing document matters, and why its silence is a finding. The pricing page retained for this review is positioning copy — “Groq is the premier neocloud for fast inference … Fast or affordable is no longer a tradeoff. We're building hundreds of megawatts of capacity, with many more on the way” — with no plan table, no rate-limit figures and no processing-tier specification in the text read. Anyone trying to establish which plan buys which envelope from Groq's public pages will not close the question on that page. The tier-to-limit mapping is not established by the documents in this set.

The ceiling moves with the model, and the model can move under you

Because limits are presented per model row, the envelope is model-specific by construction. A capacity plan expressed as a single number is therefore under-specified before anything else goes wrong: swap the served model and the constraint changes shape.

As rendered, the Developer table shows, among other rows, openai/gpt-oss-120b at 250K tokens per minute and 1K requests per minute. That figure is reported from the provider's rendering of a table row, not read here as a complete table, and it should be treated as an illustration of the format rather than a specification of the service.

The same page adds a second kind of movement: preview models may be discontinued at short notice. That is a documented coupling between the catalogue and the ceiling. A workload tuned against a preview row inherits the row's lifecycle, and no rate-limit document can stabilise a limit attached to a model that can be withdrawn.

Two failure codes carry two different meanings

The error page gives the client-visible half of the constraint in one sentence: “429 Too Many Requests: Too many requests were sent in a given timeframe. Implement request throttling and respect rate limits.” As the limits page is rendered, a 429 is also the only case in which a retry-after header is set, and the rate-limit headers exposed to clients include x-ratelimit-limit-requests for requests per day and x-ratelimit-limit-tokens for tokens per minute. Those headers are the only run-time evidence an application gets about which wall it is approaching.

The Flex Processing documentation then publishes a second and quite different signal: “Flex Processing is a service tier optimized for high-throughput workloads that prioritizes fast inference and can handle occasional request failures. … If flex capacity is unavailable, requests will fail quickly with status 498 and error capacity_exceeded.” Flex is reported as offering ten times higher rate limits than the on-demand tier at the same price, for paid customers, and the error page lists 498 as a custom status whose request “will not be processed,” with no charge for requests that return server error codes.

Read together, 429 and 498 answer different questions. 429 says the caller exceeded a measured rate and should slow down. 498 says the provider lacked capacity for that class of work and the request was never attempted. A retry policy written only against 429 will treat 498 as noise, retry immediately, and generate load that cannot succeed; the honest client behaviour for 498 is a deferral decision, not a backoff calculation.

That distinction is sharpened by the Batch documentation, which describes “an asynchronous batch of requests to Groq with 50% lower cost, no impact to your standard rate limits, and 24-hour to 7 day processing window.” Batch does not raise the synchronous ceiling. It removes work from that ceiling by changing the time contract the work is bought under — a cheaper, slower path around a wall that stays where it is.

The document that would make this an obligation was not read

The only page in this set that speaks in the register of obligation is the terms of service, and its language is a disclaimer scoped to the website: “YOUR USE OF THE WEBSITES (INCLUDING ANY THIRD-PARTY MATERIALS) IS AT YOUR SOLE RISK. THE WEBSITES … ARE PROVIDED ON AN ‘AS IS’ AND ‘AS AVAILABLE’ BASIS. … GROQ MAKES NO WARRANTY THAT (A) THE WEBSITES WILL MEET YOUR REQUIREMENTS, (B) THE WEBSITES WILL BE UNINTERRUPTED, TIMELY, SECURE, OR ERROR-FREE.” A liability figure of USD $100 for claims related to the websites is also reported from that page.

Two boundaries have to be stated plainly here. First, that excerpt governs the websites. Carrying a website warranty disclaimer across to an API availability commitment would be a category error, and this article does not do it. Second, no complete terms document, order form, enterprise contract or separate service-level agreement was retrieved for this review. The absence of uptime percentages and service credits from one excerpt is evidence about the text actually read, and about nothing else.

The document class that would settle whether any availability commitment with a remedy attaches to GroqCloud is a signed service-level instrument or order form — the sort of paper that is negotiated rather than published, and the first thing a serious buyer should ask for.

What a team can plan, and what it cannot

The control surface is mundane and consequential. Engineering teams size concurrency, set retry budgets and write client-side backoff against a published limit, and they read that limit as an operating envelope. The text that actually binds them — the change procedure, the per-model variation, the deferral tiers and the presence or absence of a credit-bearing commitment — sits in documents almost never read beside the limit table.

Where a help-centre number is consumed as a contractual ceiling, three failures follow in sequence. Workload is sized to a figure that can move. Retry logic is tuned to an error semantics nobody verified. And the gap surfaces at peak demand as throttling that the team's own capacity model did not contain, at the moment when a queue has the least room to absorb it.

What this review can state with confidence is narrower than the marketing, and more useful. GroqCloud publishes the units, the aggregation level, the tie-break, the exclusion for cached tokens, the base envelope for one plan, a model-specific structure, and two distinct failure codes with client guidance attached to one of them. It does not, in the pages read, publish a per-account number, a change procedure, a per-model figures table for every plan, or any availability commitment with a remedy.

All seven documents were retrieved on 19 October 2026; none carried a publication or last-modified date, so no effective date can be attached to any limit described here.

For the entity itself, see the BTW directory entry for Groq Inc..