API rate limits are rarely published in the unit you actually need. A limit documented as "60 requests per minute" doesn't tell you the millisecond interval to sleep between calls, and a limit given in requests-per-day doesn't make it obvious what that means for a burst of traffic in one second. This tool converts between all four common units and adds a safety buffer, so the number you get is one you can safely build a rate limiter around.
How it works
Enter the limit exactly as documented (a value and a unit: per second, minute, hour, or day) and it's converted to requests per second first, since that's the common unit everything else is derived from.
The safety buffer reduces the theoretical maximum before it's turned into a sustained rate and a minimum interval. A buffer matters because real traffic bursts, clock drift between your server and the API's rate-limit window, and retries after transient errors can all push you over a limit you're technically respecting on average.
The minimum interval in milliseconds is what you'd actually use in code, e.g. as the delay in a token-bucket or leaky-bucket limiter, or a simple `setTimeout` between sequential calls.
A worked example
A limit of 60 requests per minute converts to exactly 1 request per second. With a 15% safety buffer, the safe sustained rate drops to 0.85 requests per second, a minimum interval of about 1,176 ms between requests, rather than cutting it exactly to 1,000 ms.
Questions people ask
Why apply a safety buffer at all? Shouldn't the documented limit be exact?
It usually is exact for average throughput, but most APIs enforce limits over a sliding or fixed window, and a burst of requests early in a window can trip the limit even if your average rate is technically compliant. A buffer of 10–20% is common practice for production rate limiters.
How does this apply to AI APIs like OpenAI, Anthropic, or Gemini?
LLM APIs typically enforce two limits simultaneously: requests per minute (RPM) and tokens per minute (TPM). This converter handles the RPM side; the binding constraint in practice is often TPM, not RPM, especially for large prompts or completions. Check which limit your usage actually hits first before relying on either number alone.
What's the difference between a token-bucket and a fixed-window rate limit?
A fixed-window limit resets fully at the start of each window (e.g. every 60 seconds), which allows bursting up to the full limit at the window boundary. A token-bucket (or sliding-window) limit refills gradually, which smooths traffic more evenly. The "safe sustained rate" here works for either, but fixed-window APIs specifically benefit from a larger buffer near window boundaries.
My API gives separate limits for different endpoints. How do I combine them?
Convert each endpoint's limit separately using this tool; rate limits are almost always tracked per-endpoint (or per API key + endpoint), not pooled across your whole account, unless the documentation explicitly says otherwise.
Guides
- How to Estimate LLM API Costs Before You ShipAPI bills come from input and output tokens priced separately. With three numbers per request you can estimate a monthly bill and compare models before writing any code.
- What 99.9% Uptime Really Means in Hours and MinutesEach extra nine cuts allowed downtime by a factor of ten. Here is what three, four and five nines allow per year, month and day.