notAcalculator logo

API Rate Limit & Cost Calculator

API Rate Limit & Cost Calculator

Give us your feedback! Was this useful?

The Two Budgets Every API Has

Every API enforces two budgets, and they are not the same[wikipedia-rate-limiting]. The first is a rate limit — how many requests you may send in a window (e.g., GitHub 5,000 per hour, OpenAI Tier 1 500 requests per minute, Stripe 100 writes per second)[github-rate-limits][openai-rate-limits][stripe-rate-limits]. The second is a cost budget — how many dollars those requests accrue at the provider's per-request or per-token price. Exceed the first and you are throttled with 429 Too Many Requests and a Retry-After header[mdn-retry-after]; exceed the second and you are invoiced.

The rate limit is usually a token bucket[wikipedia-token-bucket]: tokens refill at a fixed rate (e.g., 10 per second) up to a burst capacity (e.g., 100). You can burst to 100 instantly, but sustained throughput cannot exceed 10 per second. A second, coarser limit — often per minute or per hour — caps the refill. Developers who test only the happy path discover the bucket the first time a deploy scales from 1 to 10 replicas and the aggregate request rate 10× while the limit stays fixed.

Cost compounds the same arithmetic with money. If an API charges $0.002 per request ($2.00 per 1K), 500 requests per minute for 8 hours is 240,000 requests, or $480 per day[nist-units]. Add a retry policy that retries 429s with exponential backoff and the cost of throttling is not just latency — it is extra requests that are themselves billable. Whether you are a junior wiring your first fetch or a senior designing a multi-region ingestion pipeline, the same three numbers govern the outcome: limit, load, and price.

This calculator estimates both budgets at once. Enter the provider's limit, your expected load, the cost per 1K requests (or per 1K tokens for LLM APIs), and a retry factor, and it reports monthly cost, required backoff, and the probability that a given second will be throttled. It shows results in both requests per minute and per hour so a team in Berlin reading GitHub's "per hour" docs and a team in São Paulo reading OpenAI's "per minute" docs get the same answer without conversion[nist-units]. For pure token math without rate limits, the LLM API Cost Calculator goes deeper; for token counting itself, the Token Counter Calculator counts context.

How to Use This Calculator

The calculator needs four numbers and one choice of retry behavior. The worked examples below cover the most common developer scenarios.

Example 1 — GitHub REST API, small CI job.

  • Limit: 5,000 per hour[github-rate-limits] (83.3 per minute)
  • Load: 200 requests in a 10-minute CI run (20 per minute)
  • Cost: GitHub free tier $0 per 1K (or $0.002 if you model Actions minutes as API cost)
  • Retry: 0% (no retry — fail fast)
  1. Choose limit unit. Select Per hour and enter 5000. The calculator also shows 83.3 per minute.
  2. Enter load. Type 20 per minute (or 1200 per hour — both give the same ratio).
  3. Enter cost per 1K. Type 0 for free tier, or 2.00 for a paid proxy at $2 per 1K.
  4. Enter retry % — 0 for this job.
  5. Press Calculate. Results: utilization 24%, monthly cost $0 (or $1,728 at $2 per 1K if 20/min × 43,200 min/month), throttling risk negligible.

Example 2 — OpenAI, burst with retry.

  • Limit: 500 per minute[openai-rate-limits]
  • Load: 800 per minute burst for 2 minutes, then 100 per minute steady
  • Cost: $0.002 per request ($2 per 1K)
  • Retry: 30% of throttled requests retried once with backoff

Enter 500 limit, 800 burst load, $2 per 1K, 30% retry → utilization 160% during burst, ~300 requests throttled in 2 minutes, retry adds ~90 extra requests, cost $480/day + $0.18 retry overhead, Retry-After avg 2–4 s[mdn-retry-after]. The fix is not more retries — it is smoothing the burst via a token bucket queue[wikipedia-token-bucket].

Example 3 — Stripe writes, high throughput.

  • Limit: 100 per second (6,000 per minute)[stripe-rate-limits]
  • Load: 80 per second sustained (4,800 per minute)
  • Cost: $0.005 per 1K
  • Retry: 10%

Utilization 80%, monthly 6.9M requests, cost $35/month, throttling risk low but tail latency from 10% retries adds p95 200 ms.

Tips while entering:

  • Convert units before comparing: 5,000 per hour = 83.3 per minute = 1.39 per second[nist-units]. The calculator shows all three.
  • Cost per 1K is often quoted per 1M — divide by 1,000. OpenAI's $0.002 per 1K tokens is $2 per 1M[openai-rate-limits].
  • Retry % is the fraction of throttled requests you retry, not of all requests. A 30% retry on a 160% utilization burst is ~18% more load, which can re-throttle — model it, don't guess[wikipedia-rate-limiting].

The Formula

All estimates are steady-state averages. Burst is modeled as load > limit; retries as extra load.

Let:

  • L = limit (requests per minute, the provider's bucket refill rate)[wikipedia-token-bucket]
  • D = demand (requests per minute, your load)
  • p = price per request in dollars (price per 1K / 1000)
  • r = retry fraction (0 to 1) applied to throttled requests
  • W = window (minutes per month ≈ 43,200)

Utilization:

U=DLU = \frac{D}{L}

Throttled per minute (when D > L):

T=max(0,DL)T = \max(0, D - L)

Retry overhead per minute:

R=T×rR = T \times r

Effective load (what the server sees):

Deff=D+RD_{\text{eff}} = D + R

Monthly cost:

Cmonth=Deff×W×pC_{\text{month}} = D_{\text{eff}} \times W \times p
[nist-units]

With 30.44 days per month, W = 60 × 24 × 30.44 = 43,833.6 minutes (the calculator uses 43,200 for a 30-day month and notes the 1.5% difference). To handle per-hour limits, divide by 60: L_per_min = L_per_hour / 60[github-rate-limits].

Worked Step-Through

500 per minute limit, 800 per minute burst, $2 per 1K ($0.002 per req), r = 0.30, 2-minute burst:

U=800500=1.60=160%U = \frac{800}{500} = 1.60 = 160\%
T=800500=300 throttled/minT = 800 - 500 = 300\ \text{throttled/min}
R=300×0.30=90 extra/minR = 300 \times 0.30 = 90\ \text{extra/min}
Deff=890 /min during burstD_{\text{eff}} = 890\ \text{/min during burst}
Cburst-2min=890×2×0.002=$3.56 for 2 minC_{\text{burst-2min}} = 890 \times 2 \times 0.002 = \$3.56\ \text{for 2 min}

Sustained at 100 per minute after the burst: U = 20%, T = 0, C = 100 × 43,200 × 0.002 = $8,640 per 30-day month. The burst's 90 retries cost $0.18 extra — cheap in money, expensive in latency because each retry waits the Retry-After window[mdn-retry-after].

Reference Table

Monthly cost and throttling for a 500 per minute limit (e.g., OpenAI Tier 1)[openai-rate-limits] at $2 per 1K, varying demand and 30% retry. Cost scales linearly with price: at $0.50 per 1K divide by 4; at $10 per 1K multiply by 5.

10020%00$8,640
25050%00$21,600
40080%00$34,560
500100%00$43,200
600120%10030$54,432
800160%30090$76,032
1,000200%500150$97,632
1,500300%1,000300$151,632
Monthly cost at $2 per 1K with 30% retry — linear to the limit, then steeper as retries add billable requests. Halve the cost at $1 per 1K.

The cliff is at 100% utilization: below it cost is D×W×p, above it cost is (D + (D−L)×r)×W×p. At 120% the retry tax is 4% extra; at 200% it is 15% extra. The fix is always to lower D (queue, batch, cache) rather than to raise r — more retries on an overloaded bucket just move the cost from 429s to 200s with added latency[wikipedia-token-bucket].

Practical Tips

  1. Smooth the burst, don't retry the burst. A token-bucket queue that caps at L and buffers excess to the next window eliminates throttling without retries[wikipedia-token-bucket]. Implement via p-limit or a server-side queue before adding retry logic.
  2. Batch when the API allows it. GitHub's GraphQL and Stripe's batch endpoints turn N requests into 1 — the cheapest way to stay under L[github-rate-limits][stripe-rate-limits].
  3. Cache the Retry-After you receive. The header is in seconds or a date[mdn-retry-after]. Use it verbatim for backoff; don't guess 1 s and re-throttle. With exponential backoff, start at the header's value, not at a constant.
  4. Separate per-minute and per-hour limits. GitHub's 5,000 per hour and 83 per minute are the same bucket at different windows — bursting to 83 per minute for 60 minutes hits the hourly cap exactly[github-rate-limits]. Model the tighter of the two.
  5. Price the retry. At $2 per 1K, 30% retry on a 200% overload adds $11k per month. Log T and R and alert when U > 80% — cheaper to add a queue than to pay for retries[kleppmann-ddia].
  6. Load-test at L×N replicas. A service that does 100 per minute on 1 replica does 1,000 on 10 replicas. Multiply D by replica count before comparing to L — the most common prod surprise[wikipedia-rate-limiting].

Limitations

  • Steady-state averages, not burst dynamics. Real token buckets allow a burst up to capacity even when U > 100% for a short window[wikipedia-token-bucket]. The calculator reports sustained throttling; a 1-second burst to 1,500 per minute may still succeed if the bucket was full.
  • Single bucket modeled. Many APIs have multiple limits (per second, per minute, per hour, per token)[openai-rate-limits]. The calculator models one at a time — run it twice for the two tightest limits and take the higher throttling.
  • Cost per 1K is not always per request. LLM APIs charge per 1K tokens, not per request[openai-rate-limits]. If your request averages 2K tokens, multiply the per-1K-token price by 2 to get per-request price before entering.
  • Retry cost assumes one retry. Real clients may retry 3× with exponential backoff. The calculator's single-retry model is a floor; 3× would triple R[mdn-retry-after].
  • No concurrency or latency modeling. Effective load D_eff assumes retries are immediate within the same minute. In reality retries are spread over the Retry-After window, smoothing the load — the monthly cost is correct, the per-minute throttling is slightly pessimistic[wikipedia-rate-limiting].

Frequently Asked Questions

What is the difference between per minute and per hour rate limits?
They are the same bucket at different windows. 5,000 per hour equals 83.3 per minute and 1.39 per second. Bursting to 83 per minute for 60 minutes hits the hourly cap. Always model the tighter window for your load pattern.
What does 429 Too Many Requests and Retry-After mean?
429 means the token bucket is empty. The Retry-After header tells you when tokens refill — either seconds to wait or a date. Wait that long before retrying; immediate retries just re-throttle.
How do I estimate monthly cost from a per minute rate?
Multiply per minute demand by 43,200 (minutes in a 30-day month) by price per request. At 100 per minute and $0.002 per request, that is 100×43,200×0.002 = $8,640 per month.
Should I retry throttled requests?
Only a fraction. Retrying 100 percent of throttled requests on an overloaded bucket adds load and re-throttles. Retry 20–30 percent once with exponential backoff starting from the Retry-After value, and queue the rest.
What is a token bucket?
A rate-limiting algorithm where tokens refill at a fixed rate up to a burst capacity. Each request consumes a token. You can burst to capacity instantly, but sustained rate cannot exceed refill rate.
How do I stay under the limit without losing throughput?
Queue and batch. A token-bucket queue caps at the limit and buffers excess to the next window. A batch endpoint turns N requests into 1. Both keep utilization under 80 percent, where throttling is near zero.
Does cost per 1K mean per request or per token?
It depends on the API. REST APIs like GitHub and Stripe charge per request. LLM APIs like OpenAI charge per 1K tokens — multiply by average tokens per request to get per-request price.
How many replicas push me over the limit?
Multiply per-replica demand by replica count. 100 per minute on 1 replica is 1,000 per minute on 10 replicas. Compare the aggregate to the limit, not the per-replica rate.

References

  1. [1]GitHub Docs. Rate limits for the REST API.
  2. [2]OpenAI Platform. Rate Limits Guide.
  3. [3]Stripe Docs. Rate Limits.
  4. [4]MDN Web Docs. Retry-After HTTP Header.
  5. [5]Wikipedia. Token bucket.
  6. [6]Wikipedia. Rate limiting.
  7. [7]National Institute of Standards and Technology (NIST). Metric (SI) Unit Conversion.
  8. [8]Kleppmann, Martin. Designing Data-Intensive Applications. O'Reilly Media.Buy on Amazon

Last updated: August 22, 2026

1b

UnByte — Independent Software Engineering

Every calculator references authoritative sources — Editorial policy