RPM vs TPM ceiling at your token size
The smaller bar is the one that actually throttles you.
| Limit | Value | Max req/min | Binds? |
|---|
Why two limits, and why it matters
Every major LLM provider — OpenAI, Anthropic, Google, Mistral — meters you on requests per minute and tokens per minute simultaneously. The catch is that the token limit is the one most people forget. A 30,000 TPM budget sounds large until you send 4,000-token prompts: that's only about 7 requests a minute before you start getting 429 Too Many Requests, even though the RPM limit might allow hundreds. The fix is almost never "send faster" — it's trimming context, capping output length, or moving up a usage tier.
This calculator does the division for you. It takes both limits and your tokens per request, finds the smaller ceiling, and turns it into something you can plan around: concurrent active users. If you know each user fires roughly two requests a minute, the user number tells you how many people one key serves before requests queue. When you hit the wall, the honest options are: shrink the prompt (often the biggest lever), shorten max_tokens, batch non-urgent work on the async batch API, or qualify for a higher tier by spending more.
Once throughput is sized, price it: the LLM token cost calculator turns those tokens into dollars, and the AI app cost estimator models the whole bill at your user count. Building a chat product? The chatbot cost calculator ties conversation volume to both cost and throughput.
How to use it
1. Pick a preset tier or type the RPM and TPM limits from your provider dashboard.
2. Enter the input and output tokens a typical request uses (output counts toward TPM too).
3. Set how many requests one active user sends per minute.
4. Read the effective requests per minute, concurrent users, and which limit is the bottleneck.
Common mistakes
Counting only input tokens. Output tokens are billed and rate-limited too — a chatty model with long answers burns TPM fast. Sizing to the RPM limit. If your prompts are large, TPM caps you first; the RPM number is irrelevant. Assuming the limit is fixed. Tiers rise automatically as your spend grows, so a wall today may be gone next month. Ignoring bursts. Limits are per-minute averages but enforced in short windows, so spiky traffic hits 429s below the average.
FAQ
How do I turn a TPM limit into requests per minute?
Divide TPM by tokens per request (input + output). The result is your token-side request ceiling; your true ceiling is the smaller of that and the RPM limit.
Why do I get 429 errors below my RPM limit?
Because the token-per-minute limit is binding instead. Long prompts or outputs exhaust TPM before you reach the request count. Shrink the prompt or cap output length.
How many users can one API key serve?
Effective requests per minute ÷ requests per user per minute. Raise it by trimming tokens, batching, moving up a tier, or spreading load across keys.
Do batch endpoints share these limits?
No — async batch APIs have their own, much higher limits and a discount, at the cost of latency. Use them for non-interactive bulk jobs.
Estimate only. Rate limits are reference figures and vary by provider, model and account tier — verify in your dashboard.