How Many AI API Requests Can Your App Handle?

Your app can send only as many AI API calls as its first applicable limit allows. If an account hypothetically permits 60 requests, 120,000 counted input tokens and 30,000 output tokens per minute, a call using 8,000 input and 500 output tokens has a theoretical average ceiling of 15 requests per minute: the input allowance runs out first. That is a planning calculation, not a promise that 15 calls sent together will succeed. A context window governs one call; a spending cap governs money; neither is a substitute for a per-minute throughput limit.

Read the limits that apply to your account

Start with the maker’s current account page, not a generic tier chart. Record the model, endpoint, project or organization, usage tier, and every limit that applies. If your application also has a gateway or its own per-user limiter, that can be the first bottleneck. Claude’s rate-limit guide describes Messages API limits by requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM). Its organization limit still applies when a workspace has its own lower setting. Google’s Gemini API guide describes RPM, input tokens per minute (TPM), and requests per day (RPD); limits are per project rather than per API key, vary by model and tier, and the active values appear in AI Studio. Do not transfer a Claude input/output formula to a provider that counts one different token pool.

Question	Claude Messages API	Gemini API
Which minute counters matter?	RPM, ITPM and OTPM for a model class	RPM and input TPM; model-specific counters may also apply
What else can stop calls?	Organization/workspace rules and monthly spend limits	RPD and, where applicable, spend-based limits
Where to get your actual values?	Claude Console rate-limits page or Rate Limits API	AI Studio active rate-limits view
What shares a limit?	Organization limits remain in force across workspaces	Project limits are not multiplied by adding API keys

These are published counting rules, not a claim about your account’s allowance. A provider may have a model-specific or endpoint-specific condition missing from this compact table. A gateway can enforce its own request, token or user policy before the provider does, as Solo’s agentgateway guide demonstrates. Record both layers if you use one. The free-tier guide helps with eligibility, but a free or paid label alone does not tell you how many calls your project can sustain.

Calculate the first limit you hit

For a service that really exposes separate RPM, ITPM and OTPM counters, use a representative call shape and calculate three ceilings:

Average calls/minute = min(RPM, ITPM ÷ counted input tokens/call, OTPM ÷ counted output tokens/call).

The smallest result names the binding limit. Round down if you need a whole number of complete calls. This is an average-workload worksheet, not an admission algorithm. Token counts vary with the prompt, conversation history, retrieved text, generated answer and model. Measure the distribution of your own calls rather than using the smallest prompt you can find. If several user flows share the same model-class pool, add their traffic before applying the calculation.

The word counted matters. Claude says that, for most models, uncached input and cache-creation tokens count toward ITPM, while cache-read tokens do not. It also says output tokens count as they are generated, and the requested max_tokens value does not itself consume OTPM. Check the exact model and current policy before using caching as capacity in your worksheet. Gemini labels its published TPM dimension as input tokens, so use its input-token definition and any other counter shown for your model rather than silently adding output to it. The token counter can size sample text, but its Claude and Gemini figures are estimates made with another tokenizer; use each provider’s own usage or token-count endpoint when an exact count matters.

For a provider with a combined tokens-per-minute pool, replace the two token divisions with that pool divided by the tokens it actually counts per call. Do not assume every provider charges the limiter for cached input, generated output or reserved output in the same way. If there is an RPD or daily-token cap, calculate a separate daily ceiling. Dividing a daily quota by 1,440 gives a daily average across minutes, not extra burst permission in any one minute.

Compare three workload shapes

The quotas and token counts in this table are illustrative, not any provider’s current tier: 60 RPM, 120,000 ITPM and 30,000 OTPM. The example assumes each call is counted exactly as listed, with no other traffic in the same pool.

Illustrative call	Input/call	Output/call	RPM ceiling	Input ceiling	Output ceiling	First limit; average ceiling
Short answer	1,000	250	60	120	120	Requests; 60/min
Document question	8,000	500	60	15	60	Input; 15/min
Long answer	1,000	2,000	60	120	15	Output; 15/min

The document row is 120,000 ÷ 8,000 = 15 calls/minute on input; its output demand at that pace is only 7,500 tokens/minute. The long-answer row reaches the same 15-call ceiling for a different reason: 30,000 ÷ 2,000 = 15 on output. A scheduler that looks only at RPM would try four times the sustainable rate for either row. If the output lengths vary, use observed output counts to refine that row; do not call the table a measured benchmark.

For a mixed app, a useful next step is to multiply each flow’s planned calls/minute by its counted input and output tokens, then sum by shared pool. For example, hypothetically sending ten document calls and ten short-answer calls each minute would consume 20 requests, 90,000 input tokens and 7,500 output tokens. All three are below the illustrative caps, although bursts and other traffic can still trigger a rejection. The context-window guide explains how much one call can contain; that per-call maximum does not raise these minute budgets.

Why an average can still produce 429s

Limits are enforced over time, not merely checked against a spreadsheet at the end of each minute. Claude describes a token-bucket approach with capacity replenishing continuously; a full-minute allowance may not be available as one burst. Google also says specified limits do not guarantee actual capacity. Concurrent clients, a shared organization or project, another background job and a gateway policy can consume room you thought was free. Claude’s API error guide also documents acceleration limits after sharp traffic increases. Pace admissions to the relevant shared pool and leave headroom based on observed rejects and latency; there is no universal safe percentage to promise.

Concurrency is another number. If the long-answer example is running at its theoretical 15 calls/minute and the assumed, not measured, mean call latency is 20 seconds, Little’s-law arithmetic gives 15 × 20 ÷ 60 = about five in-flight calls on average. Five concurrent slots alone do not make the rate safe: a sudden five-call launch may be a burst, latency has a tail, and a retry also needs admission. Measure actual latency percentiles, accepted calls, rejected calls and token usage by model and pool. Use a queue or a token-aware admission control to smooth arrivals, and protect interactive work from a batch of low-priority jobs.

Claude’s response headers expose request and token limits, remaining capacity and reset times, and its 429 can carry retry-after. Record those alongside the request ID and usage, without logging sensitive prompt content. When a provider does not give an equivalent header, use its console usage and error response rather than inventing a reset time. The goal is to know which counter is binding in your traffic, not to infer it from an HTTP status alone.

Read the error before retrying

An HTTP 429 is not a complete diagnosis. Claude’s rate-limit documentation says a temporary Messages limit names the exceeded limiter and may include retry-after. Its monthly tier spend-cap response also uses 429 but has error.details.error_code set to enforced_spend_limit_reached and no retry-after; retrying will not help until access resumes or the limit changes. A user-set Claude organization or workspace spend limit can instead produce HTTP 400. Google’s rate-limit guide also describes a rolling spend-rate limit that can return 429 RESOURCE_EXHAUSTED, so inspect the error details and account state before treating every 429 as a simple RPM overflow.

For an actual temporary throttle, honor a provider-supplied wait, then use bounded exponential backoff with jitter. Google’s troubleshooting guide recommends this pattern for retryable 429/503 responses and a maximum attempt count; it advises against retrying ordinary 400/402/403 client problems. Set a deadline as well: an interactive call should eventually give the user a useful failure, while an offline job may wait longer. Check whether your SDK already retries, or you could accidentally multiply the attempts in two layers.

For a spend-cap, billing or access error, pause the affected work, inspect the provider console and tell the responsible person what limit needs action. Do not rotate keys or projects to evade a shared cap. If a request timed out after submission, reconcile its request ID, result and usage before resending when possible; an uncertain outcome can mean duplicate work or charges. The same reasoning applies to jobs that moved through a gateway: a gateway 429 and a provider 429 may need different operators and different fixes.

Decide what to change

Choose the fix for the counter that actually binds. If input tokens dominate, remove irrelevant retrieved passages, trim repeated history, or use documented cache behavior for repeated material. If output dominates, ask for a shorter answer or cap output where the product requirement allows; do not confuse a shorter cap with a guarantee that the response is complete. If RPM dominates, combine work only where the API genuinely supports it, smooth arrival times and request a higher permitted limit with measured demand. If a daily quota or spend control binds, a faster minute scheduler cannot fix it.

Some work can wait. An asynchronous batch API may have a different queue and price, but it changes completion time and failure handling; the batch API guide walks through those trade-offs. Keep user-facing calls on the path that meets their deadline. Before seeking a quota increase, bring a worksheet: model and tier, traffic by flow, counted input/output distribution, peak arrival pattern, observed 429 details and required headroom. That gives the provider and your team a concrete capacity question rather than a vague request for “more RPM.”

Sources

• Claude Platform rate limits — Messages counters, cache counting, scope, spend-cap behavior and headers.
• Claude API errors — status meanings, acceleration and SDK retry behavior.
• Gemini API rate limits — project/model counters, active account limits, daily and spend-rate limits.
• Gemini API troubleshooting — retryable errors, backoff and client-error handling.
• Solo agentgateway rate limiting — example of separate gateway-enforced controls.

All pages read on October 30, 2026.

Free toolHow many tokens is my prompt?Count my tokens