Groq free tier limits for gpt-oss-20b: what can you build?

Groq’s free tier lists 30 requests per minute, 1,000 requests per day, 8,000 tokens per minute and 200,000 tokens per day for openai/gpt-oss-20b, checked on 26 October 2026 in the Free Plan Limits table.

Other models can have different limits on the same official limits page. This guide uses only openai/gpt-oss-20b for its examples.

Check your organisation’s actual Limits page before building around those numbers. The public table is a general guide, limits apply across the organisation, and some accounts may also have separate input and output limits. A second API key does not give your app another independent allowance.

That is enough to consider a small text feature: filling an editable form, preparing a digest from supplied reading, or helping someone refine a short piece of writing. In the examples below, the token allowance becomes the constraint before the request count does.

Count the whole call

A request includes your instructions, schema, supplied text and retained conversation. Output includes generated reasoning as well as the answer the user sees. For GPT-OSS, include_reasoning: false controls whether reasoning is returned; it does not establish that reasoning was never generated or used no tokens.

The examples below use invented token budgets, including a reasoning allowance. They are calculated plans, not live API measurements, typical usage figures or token counts taken from the displayed sample.

For each call, budget input plus all generated output. Then add those calls across the day and across likely bursts. This does not reproduce Groq’s request-admission algorithm, which its checked documentation does not fully specify. Actual usage, account limits and response headers take priority.

An event form that starts with a rough note

A useful first feature is turning a short description into fields someone can check. An event organiser could paste:

Design meetup, Bristol, 7 November 2026 at 18:30. Bring a laptop.

The desired result is an editable event card. This is an illustrative output contract, not a model response:

{
  "title": "Design meetup",
  "date": "2026-11-07",
  "time_local": "18:30",
  "place": "Bristol",
  "timezone": null,
  "checklist": ["Bring a laptop"]
}

The application would put those values into ordinary form controls, keep the original note alongside them, and save only after confirmation. The timezone remains unresolved because the note did not explicitly supply one. A task manager could use the same pattern for a title, due date and checklist.

Groq supports strict JSON Schema output on gpt-oss-20b. Use the json_schema response format with strict: true; every property must be required, and objects need additionalProperties: false. A value that may be unknown can allow null while its field remains required.

That gives the application a predictable shape to handle. It still needs to check dates and other values, allow corrections, and handle an unsuccessful or incomplete response. A valid date string can describe the wrong date.

For a planning budget, allow 800 input tokens and 400 total output tokens per extraction. The output allowance might be 200 visible tokens plus 200 reasoning tokens. These are assumptions for the whole request, including instructions and schema, not the tokenisation of that one-line note.

At 100 extractions a day, that is:

100 × (800 + 400) = 120,000 tokens a day.

Ten additional full attempts would bring the day to 132,000 tokens. There is room for that in the stated daily budget, although an automatic repair loop should still have a limit.

The awkward case is everyone arriving together. Twenty submissions budget 24,000 tokens, even though 20 requests is below 30 RPM. At this payload, six calls total 7,200 tokens; five per minute gives a less crowded planning target of 6,000. Put submissions through a shared queue and show a waiting state rather than promising instant completion to all 20 people. Those figures guide pacing; they do not guarantee acceptance.

This looks plausible for a modest form assistant. It stops looking comfortable if the output assumptions change: another 1,000 reasoning tokens on every extraction would raise the same 100-call day to 220,000 tokens. Keeping answers concise is useful, but counting only the visible JSON would hide the problem.

Strict structured output currently does not support streaming or tool use. Receive and validate the complete result before filling the form.

A digest that can wait its turn

A digest suits a queue more naturally. Someone selects several release notes or articles, supplies their text, and asks for a short account of the changes.

Give each source an application-assigned identifier such as release-1. Ask for grouped changes with a short explanation and supporting source identifiers. The application then builds links from its existing identifier-to-URL map. The desired result is a reviewable digest with links back to the supplied reading, rather than plausible-looking URLs invented by the model.

Keep the excerpts available beside the digest so someone can check whether a summary represents them fairly. This example does not require browsing or a crawler: the selected text is the input.

Suppose each digest budgets 5,000 input tokens and 1,000 total output tokens, with the output split between 500 visible tokens and 500 reasoning tokens. At 24 digests a day, the total is 144,000 tokens.

That fits the daily arithmetic. It does not support three digests together: their combined budget is 18,000 tokens. One 6,000-token job per minute is already a substantial part of the minute allowance, so make “queued, then ready” the normal interaction. This is a queue of ordinary API calls in your application, not a recommendation to use Groq’s separate Batch service.

Two full retries would take the day to 156,000 tokens. Retrying every job once would need 288,000 and exceed the daily allowance. A failed result cannot simply mean “try again forever”.

Longer reading also changes the verdict. A 7,500-token input plus 1,000 output tokens budgets 8,500 tokens for a single job, already above the published combined minute allowance in this planning model. Giving the model a large context window does not expand the free tier’s TPM budget.

The practical fit is a small selection of supplied reading with bounded excerpts and a short result. A service accepting arbitrarily long documents needs a different budget. Splitting them into calls may help with individual payloads, but those calls still consume the shared allowance.

Streaming chat needs a conversation limit

A small copy helper gives chat a concrete purpose. An organiser supplies event facts and asks for an announcement, then requests a shorter version, adds venue information and adjusts the tone. The result remains text they can edit.

Groq documents ordinary streaming chat for GPT-OSS. That is a separate configuration from the strict extraction request. Streaming lets you display the answer as it arrives; the token budget stays the same.

For an illustrative conversation, assume:

• 600 tokens of fixed instructions.
• 100 tokens in each new user message.
• 500 generated tokens per turn: 150 visible answer tokens and 350 reasoning tokens.
• Previous user messages and visible answers remain in the next prompt; reasoning is not replayed.

The first call budgets 1,200 tokens. Each completed exchange adds another 250 tokens to the next request.

A six-turn conversation totals 10,950 tokens. Ten such conversations a day need 109,500 tokens and 60 requests. That is a reasonable shape to investigate for a small, explicitly limited helper.

The same six turns compressed into one minute would budget 10,950 tokens, exceeding the 8,000 TPM allowance under these assumptions. Concurrent users add another complication: four first turns total 4,800 tokens, while four sixth turns total 9,800. A per-user request counter misses the difference.

Keep a shared queue, bound the answer length and make the conversation limit visible. Offering six revisions before starting a fresh conversation gives the user a comprehensible boundary. Saving the current draft separately means ending the conversation need not discard their writing.

Without a limit, full-history replay gets expensive. A ten-turn conversation in this example costs 23,250 tokens; twenty turns cost 71,500. Summarising old history is another possible design, but that summary call also needs a budget. None of these totals assumes that repeated prompts will receive a cache hit.

Three fitting examples still share one allowance

The examples fit separately. Run all three daily workloads in the same organisation and they total 373,500 tokens across 184 requests. That exceeds 200,000 TPD while remaining well below 1,000 RPD.

A smaller mixed day could be 80 extractions, four digests and three six-turn conversations: 152,850 tokens across 102 requests, leaving 47,150 tokens below the published daily cap. Reserve that room for variation, retries and other work.

Groq supports prompt caching for this model, but cache hits are not guaranteed and cached tokens are deducted from limits after processing. Do not rely on a future cache discount to admit a large simultaneous burst.

The inference allowance also does not host your application or keep its records. The maintained free-compute guide covers separate API hosting and database options for the form, queue or saved drafts.

Keep work when the API asks you to wait

For a browser application, keep the API key in a trusted backend. That backend can hold the shared queue, enforce each feature’s budget and preserve a pending job when a request cannot run.

A rate-limit response is 429 Too Many Requests. Follow Groq’s response headers: retry-after is expressed in seconds when supplied on a rate-limit response. The remaining-request headers describe daily requests, while remaining-token headers describe minute tokens. They do not expose every applicable limit, so also record actual usage and check the account’s Limits page.

Bound retries and waiting time. Correct a bad request or invalid key before trying again. A job blocked by a daily budget should stay pending with a clear status rather than immediately retrying.

If more capacity becomes necessary, upgrading to Developer requires a valid payment method and introduces usage-based billing. A higher limit is not another free allowance.

For a first implementation, the editable extractor has the smallest moving parts. Connect one form to a server-side structured-output request, retain the original input, and record the returned usage while checking the extracted fields. Replace the assumed 800-plus-400 budget with those observations before deciding how many people to invite.