API Rate-limit Planner

Method, assumptions and limits

Useful capacity = min(RPM × tasks/request × buffer factor, TPM / tokens/task × buffer factor, workers × 60 / latency × tasks/request) / (1 + extra retry attempts / 100). Rates are steady-state averages, so fractional tasks per minute are meaningful. Retries are counted in both requested load and capacity, not deducted twice.

Tokens per task = input + maximum output. This is an explicit conservative scenario, not a provider-exact reservation algorithm. Batching here combines independent tasks in one online request, not a provider asynchronous Batch API. It assumes token counts scale linearly, latency already includes the whole batch, and shared overhead is included in your per-task estimate.

The default 48 attempts/minute becomes 45.71 useful tasks/minute at 5% extra attempts. A target of 40 therefore leaves 5.71 useful tasks/minute of headroom. One worker at eight seconds per request instead limits capacity to about 7.14 useful tasks/minute.

If one request exceeds the entire entered minute token allowance, this model reports zero useful capacity. Actual burst windows, request-size limits, shared account limits, provider-specific token accounting, daily quotas, dynamic latency, errors and backoff are not simulated. Measure them before production.

Provider source

OpenAI rate-limit guidance describes request/token headers, unsuccessful attempts consuming limits, and backoff. Its documented token reservation can use a maximum rather than this page’s conservative sum. Read the exact provider/model contract and enter your own limits. Source reviewed 11 September 2026; defaults are examples, not a current account tier.