Which service the limits belong to
The names are easy to mix up. Groq is a company that hosts models on its own hardware. Grok is the model family from xAI. This site is neither: it is an OpenAI-compatible API for one open-weight model (model ID uncensored), run by an independent provider. So for the groq api rate limit itself, such as requests or tokens per minute on a given plan, open Groq's console or documentation and read the numbers for your account. They change, and I will not guess.
What follows is exact for our API, and the habits carry over to any provider: respect the limit headers, retry only on the right errors, and cap your own concurrency before the server does it for you. If you came here for a Grok NSFW setup, our integration guide covers the surrounding errors as well.
The limits at a glance
| Limit | Full key | Trial key |
|---|---|---|
| Concurrent requests | 8 | 2 |
| Requests per minute | 300 | 60 |
| Request body | 8 MB | 8 MB |
| Context window (prompt plus completion) | 100,000 tokens | 100,000 tokens |
Two of these are rate limits in the strict sense, requests per minute and concurrency. The other two are size limits on a single request, and they are independent of the rate limits. A request with a 90,000-token prompt counts as one request against the 300 per minute, the same as a one-line prompt, though it will take longer and hold its slot longer.
The trial credit of $0.50 is claimed with one click on the API key page after sign-up, and it uses the trial limits. The full-key limits apply once you have topped up.
The three kinds of 429
All limit errors arrive as HTTP 429, but they mean different things and call for different reactions.
rate_limited: you sent more than your requests-per-minute allowance. Slow down; the window is a minute, so spacing requests evenly helps more than a long pause.concurrency: too many requests were in flight at once. Wait for an earlier one to finish. This is common with streaming, where each request lives for the whole generation.- Temporary overload: also a 429, with a
Retry-After: 5header. It is not your fault and not tied to your key's limits. Wait the stated 5 seconds and retry.
Failed requests are not charged, so a retry loop costs only the one request that finally succeeds. Responses also carry X-RateLimit-Limit-Requests and X-RateLimit-Limit-Concurrency so your client can read its own ceilings instead of hard-coding them, plus X-Balance-USD for the remaining credit and X-Request-Id, which you should log and quote if you contact support.
Throughput math: why 300 per minute is hard to reach
The two limits interact. With 8 concurrent slots, the most you can complete per minute is 8 x 60 divided by the average duration of a request in seconds. To actually reach 300 requests per minute you need requests that finish in 8 x 60 / 300 = 1.6 seconds on average. Slower requests are limited by concurrency first.
| Average request time | Max per minute, full key (8 slots) | Max per minute, trial (2 slots) |
|---|---|---|
| 2 seconds | 240 | 60 |
| 10 seconds | 48 | 12 |
| 20 seconds | 24 | 6 |
These are arithmetic ceilings for a hypothetical request time, not measurements of our service; time your own requests. The takeaway is that a long creative generation of 20 seconds on a full key tops out at 24 requests per minute, far under the 300 allowed. If you need more throughput, shorten the replies with max_tokens or ask for less text per call rather than hoping for a higher request limit.
A client that handles all three cases
This Python client limits its own concurrency with a semaphore, reads Retry-After when present, and backs off with a small jitter otherwise. It uses the official openai package.
import random
import threading
import time
from concurrent.futures import ThreadPoolExecutor
from openai import OpenAI, RateLimitError
client = OpenAI(
base_url="https://api.groknsfw.top/v1",
api_key="YOUR_KEY",
max_retries=0, # we handle retries ourselves
)
slots = threading.BoundedSemaphore(8) # use 2 on the trial key
def ask(prompt, tries=6):
for attempt in range(tries):
with slots:
try:
r = client.chat.completions.create(
model="uncensored",
messages=[{"role": "user", "content": prompt}],
max_tokens=400,
)
return r.choices[0].message.content
except RateLimitError as e:
wait = e.response.headers.get("retry-after")
body = e.response.text
# sleep outside the slot so others can proceed
delay = float(wait) if wait else min(2 ** attempt, 30)
if "rate_limited" in body:
delay = max(delay, 5)
time.sleep(delay + random.random())
raise RuntimeError("still rate limited after retries")
with ThreadPoolExecutor(max_workers=8) as pool:
results = list(pool.map(ask, ["Write one line about the sea."] * 20))
print(len(results))The same idea in Node is a small queue that allows at most 8 pending promises, and the curl check below prints the limit headers so you can confirm your key's ceilings:
curl -s -D - -o /dev/null https://api.groknsfw.top/v1/models \
-H "Authorization: Bearer YOUR_KEY" | grep -i "x-"Streaming, long prompts and context
A streamed request with stream: true keeps its concurrency slot until the last event arrives. That means a slow reader counts against you: if your code pauses while handling each chunk, the slot stays busy. Consume the stream promptly.
Long prompts interact with limits in two ways. First, they take more time to process, so they lower your throughput by the formula above. Second, they must fit the 100,000-token window together with the reply, so keep a margin. Trimming old chat turns helps both problems, and the same trimming reduces your bill: at $0.15 per 1M input tokens, a 20,000-token history costs $0.003 each time you resend it.
Details of the request format are in the quickstart, and rates are on the pricing page.
Showing limits to your own users
A rate limit is also a product decision. If your app sits between end users and the API, a raw 429 should never reach them. Decide ahead of time what they see instead.
- For chat apps, show a short "writing" state and queue the message. A wait of a few seconds is invisible to most users if something is happening on screen.
- For batch tools, show progress as a count of finished items and let the job run in the background. Retries are internal and should not appear as errors.
- For shared deployments, give each user a small per-user allowance in your own code so that one heavy user cannot take all 8 slots from the others.
Log three things for every failure: the X-Request-Id, the error code, and how many requests your app had in flight at that moment. With those, you can tell a misbehaving client from real load in a few minutes. If a problem looks like it is on the server side, the request ID is what support will ask for first.
Finally, test the failure path on purpose. Run your client with a deliberately low semaphore and then with a high one, and watch what the logs show. A retry loop that has never fired is a retry loop you cannot trust. The trial key is a convenient place for this, since with only 2 concurrent requests it is easy to hit the concurrency error with a short script and see how your code reacts, at a cost of a few tenths of a cent per request.
Common mistakes
A few patterns cause most of the 429 trouble people report.
- Retrying instantly. A loop that resends on every failure turns one over-limit moment into a storm. Wait, add jitter, and cap the number of tries.
- Retrying everything. Only 429 and transient server errors deserve a retry. A malformed request or a wrong key will fail the same way every time.
- Forgetting streams in the count. Ten open chat windows on a full key can be ten streams, and that is two more than the 8 slots.
- Setting no timeout. A hung connection keeps a slot busy. Give each request a sensible timeout in your HTTP client.
- Sizing for the average. Traffic comes in bursts. Plan for your busiest minute, not your daily mean.
Planning capacity before you launch
Work backwards from your peak. If you expect 30 users chatting at once and each reply streams for about 15 seconds, you need 30 slots at the instant they all send, and a full key has 8. Queue the rest in your own app, show a short wait, and process them as slots free up. With 8 slots and 15-second replies you can finish 8 x 60 / 15 = 32 replies per minute.
For batch jobs, run a fixed worker pool equal to your concurrency limit and let the retry logic handle the occasional overload. Rather than working around the limits, build the queue: it gives you predictable behaviour and lets you show real wait times to your users.
