AI API Rate Limit Calculator
An API can have plenty of request capacity and still return 429 errors because long prompts exhaust input tokens or verbose responses exhaust output tokens. Enter the limits shown in your account and a representative request profile to see the constraint you need to design around.
Capacity before the first 429
This is a capacity estimate, not a provider promise. Keep the buffer until production logs show stable headroom.
- Binding limit
- Output tokens per minute
- Raw capacity
- 80 RPM
- Planning capacity
- 64 RPM
- Active users at peak
- 32
- Suggested in-flight work
- 9
The first independent allowance this request profile exhausts
Before reserving capacity for real-world variance
After the 20% safety buffer
Planning estimate from the entered per-user request rate
Enough concurrent work to approach the buffered rate at the entered duration
Copies the displayed assumptions and capacity estimate. Answers stay in your browser.
Privacy: calculations happen entirely in your browser. The calculator does not send or save limits, traffic assumptions, or outputs. Analytics may count only a generic calculation event, without parameters.
Convert every allowance into the same unit
Requests per minute is already a throughput limit. The input-token ceiling is input-token allowance divided by effective input tokens per request. The output-token ceiling uses the same division for generated tokens. The calculator takes the lowest of the three, then reserves the safety buffer.
That distinction matters because request count does not tell you request weight. A retrieval-heavy chat can use thousands of input tokens while a streaming assistant can be limited by generated tokens even if both have the same RPM.
Treat the provider dashboard as the source of truth
- 1. Copy the limits for the exact model and project. Some model families share a pool, and account tiers can change over time.
- 2. Measure a representative request. Include system prompts, retrieval context, tool results, and generated output.
- 3. Reserve headroom. Start with 20% or more until peak traffic and retries are observed in production.
- 4. Log rate-limit headers. Compare the estimate with remaining-limit and reset headers after real calls.
A capacity number is not a load test
This tool does not model burst windows, queueing, retries, shared limits across models, regional capacity, provider outages, or acceleration limits. A 429 can also have a different cause from a global service-capacity error.
Cache treatment varies by provider and model. Enter a cache-hit percentage only after verifying that cached input changes rate-limit accounting for your specific endpoint. Otherwise leave it at zero and plan conservatively.
Pair capacity with cost and an operating fallback
A higher rate limit can solve a queue but still be the wrong business decision. Estimate the cost of the workload, define a fallback for 429s, and measure quality before increasing capacity.