# A rate limit that counts the tokens you asked for, not the ones you got

> Source: <https://dev.to/build996/a-rate-limit-that-counts-the-tokens-you-asked-for-not-the-ones-you-got-1oda>
> Published: 2026-09-02 11:34:27+00:00

Spent a while assuming a 413 meant my prompt was too long. It wasn't. The prompt was 20 tokens.

Groq's free tier caps you at 8,000 tokens per minute, and that budget is charged against the `max_tokens`

you **declare**, not the number the model actually generates. So this fails:

``` php
prompt: 20 tokens, max_tokens: 8192
-> 413  "on tokens per minute (TPM): Limit 8000, Requested 8271"
```

Nothing was generated. The request was rejected on the ceiling I asked for.

The same model with `max_tokens: 16`

and a 4,078-token prompt returns 200 without complaint. Prompt size was never the problem.

I swept the 14 models Groq advertises. Four of them answered a minimal request in ~300ms and then returned 413 on the identical request with `max_tokens: 8192`

:

``` php
openai/gpt-oss-120b          478ms   ->  413  (Requested 8271)
qwen/qwen3.8-27b             324ms   ->  413  (Requested 8212)
qwen/qwen3.6-27b             330ms   ->  413  (Requested 8210)
openai/gpt-oss-safeguard-20b 308ms   ->  413  (Requested 8271)
```

Two more passed the same request, which is the second thing worth knowing: it is a rolling window shared across models, not a per-model constant. A model that passes one probe can 413 a minute later — one of mine came back `Limit 8000, Used 4373, Requested 6278`

. Never conclude a model is exempt from a single passing call.

The practical consequence is for agents. Tool schemas already eat the prompt, and most harnesses declare a generous `max_tokens`

by default. Set it to what you actually need — 1,500 works — or every call dies before the model sees it.

Worth checking whether your provider bills the declared ceiling or the real output. Alibaba's docs, for contrast, say plainly that their TPM "includes input and output tokens."