API Rate Limit Calculator

Frequently Asked Questions

How does a token-bucket rate limiter work?

A bucket holds up to "burst" tokens and refills at a steady "refill" rate (tokens per second). Each request consumes one token; if the bucket is empty the request is throttled until a token is added.

How many requests are allowed per window?

Sustained throughput equals the refill rate × window length, plus the initial burst capacity. A bucket refilling at 10/s with a 100-token burst allows up to 100 + 10 × window-seconds requests over that window.

How fast can a full bucket be exhausted?

If requests arrive faster than refill, the burst drains in burst ÷ (arrival rate − refill rate) seconds. A 100-token bucket refilling at 10/s, hit at 60/s, empties in 100 ÷ (60 − 10) = 2 s.

How is a token bucket different from a fixed window?

A fixed window resets a counter every interval, allowing bursts at the boundary (double the limit across two adjacent windows). A token bucket smooths traffic by enforcing an average rate while still permitting a controlled burst.

Provided by AllCalculators.io
Free online calculators for everyday. No registration required.

Estimates for informational purposes only.

Important Disclaimer: Estimates for informational purposes only.

This calculator provides estimates for informational purposes only. Results are based on assumptions and may not reflect actual outcomes. Consult qualified professionals in relevant fields before making important decisions based on these results.

JavaScript is required to use the interactive calculator above. The questions and answers below remain readable without JavaScript.

How This Calculator Works

The token-bucket algorithm is the most common way APIs enforce rate limits. Picture a bucket that holds up to capacity tokens; every request costs one token. The bucket refills at a steady refill rate (tokens per second) up to its capacity. A client can fire a short burst as large as the bucket is full, but its long-run sustained rate can never exceed the refill rate - once the bucket empties, requests are throttled until tokens trickle back. This calculator takes the bucket capacity, the refill rate, your incoming request rate, and an optional starting token count, then reports the sustainable rate, the maximum instantaneous burst, the net drain per second, how long until the bucket empties under sustained load, and how long a fully drained bucket takes to refill. It is the quick way to size a rate limit so legitimate traffic flows while abuse is contained.

Formula / Method

The long-run sustainable request rate equals the refill rate R (tokens/sec). The maximum burst that can be served instantly equals the bucket capacity C. Under a steady incoming rate I, the bucket's net drain per second is I − R. If that is zero or negative the refill keeps up and the bucket never empties - the traffic is sustainable. If it is positive, the time to exhaust a bucket starting with S tokens is S ÷ (I − R) seconds. Once empty, refilling back to capacity from S tokens takes (C − S) ÷ R seconds (when R > 0). All quantities share the same time unit, so if you express the refill rate per minute, the exhaust and refill times come out in minutes too.

Worked Example

Say capacity = 100 tokens, refill = 10 tokens/sec, and a client sends 25 requests/sec starting from a full bucket. The sustainable rate is 10 req/s and the allowed burst is 100 requests all at once. Net drain = 25 − 10 = 15 tokens/sec, so the full bucket of 100 empties in 100 ÷ 15 ≈ 6.67 seconds. After that, the client is capped at the 10 req/s refill rate - 15 of every 25 requests get a 429 Too Many Requests. If the client then goes idle, the empty bucket refills to 100 in (100 − 0) ÷ 10 = 10 seconds, restoring the full burst allowance. Drop the incoming rate to 8 req/s and net drain is negative, so the bucket never empties and every request succeeds.

Common Mistakes

Confusing capacity with rate - capacity sets the burst size; the refill rate sets the sustained throughput. They are different knobs.

Setting capacity equal to the per-second rate - that allows no burst headroom and rejects bursty-but-legitimate clients.

Mixing time units - a refill expressed per minute and an incoming rate per second are off by 60×.

Forgetting that fixed-window limiters allow double the rate at a window boundary - token bucket smooths this out.

Ignoring per-client vs global limits - a shared bucket lets one noisy client starve everyone else.

Tips & FAQ

Token bucket vs fixed window? Fixed window is simpler but allows a 2× spike across the boundary (end of one window plus start of the next); token bucket and sliding window avoid that. How big should the burst be? Large enough to absorb normal client retries and page-load fan-out, small enough to limit damage - often 2–10× the per-second rate. What status code signals throttling? HTTP 429, ideally with a Retry-After header telling the client when to try again. Should limits be per user or per IP? Per authenticated key is fairest; per IP is a fallback for anonymous traffic but breaks behind shared NATs. What is a leaky bucket? A close cousin that drains at a fixed rate and smooths output; token bucket allows bursts whereas leaky bucket enforces a steady pace. How do I communicate limits? Return X-RateLimit-Limit, X-RateLimit-Remaining, and reset headers so clients can back off gracefully. Use these numbers to pick a capacity and refill that protect your backend without punishing well-behaved clients.

Frequently Asked Questions

Related Developer Tools Calculators