Rate Limit Capacity Planner
Your TPM and RPM allowances and your per-request token counts into the number of active users they support, and which of the two limits binds first.
Your tokens per minute limit binds first, at 500.0 requests/min. Each user needs 1.50 req/min at peak.
- Tokens counted per request
- 2,000 tokens
- Requests/min the token limit allows
- 500.0
- Requests/min the request limit allows
- 5000.0
- Binding limit
- tokens per minute
- Effective ceiling
- 500.0 req/min
- Tokens used at that ceiling
- 1,000,000 /min
- Unused token allowance
- 0 /min
- Demand per user at peak
- 1.500 req/min
- Active users supported
- 333
Which of the two limits actually binds
req/min = min( RPM, TPM ÷ tokens per request )
users = req/min ÷ (requests per user per minute × peak factor)
Two ceilings apply at once and only one of them is doing anything. With long prompts the token limit binds and the request limit is decoration; with short ones it is the other way round. Knowing which is which decides what to do about it. If tokens bind, trimming the system prompt, moving tool schemas out of every call or caching a shared prefix buys real capacity. If requests bind, none of that helps and you need batching, fewer calls per user action, or a higher tier.
The output field deserves a moment. Some providers count your reserved max_tokens against the token budget at admission time rather than the tokens actually generated, which means a lazy max_tokens: 4096 on a workload that returns two hundred tokens can be spending twenty times the allowance it needs. Check which your provider does — it is the single cheapest capacity win available if it applies to you.
Treat the user number as a ceiling under a smooth arrival pattern rather than a promise. Real traffic clusters, retries pile on at exactly the wrong moment, and every 429 you retry into consumes budget that legitimate first attempts needed. Size below the ceiling, queue client-side rather than retrying blindly, and give background work a lower priority than anything a person is waiting on.