Free LLM API 429 Errors: Check Headers, Quotas, Traffic

Updated 5 November 2026 · Standard formula, shown below

A 429 response from a free LLM API usually means the service is limiting requests because you exceeded a request or token quota, sent them too quickly, or hit a temporary capacity limit. Check the response headers and provider dashboard first, then reduce request traffic and retry only as the service’s guidance allows; a 429 does not always mean your account has permanently run out of quota.

What an LLM API 429 means

HTTP status 429 is defined as “Too Many Requests.” For language-model APIs, it can represent several different limits: requests per minute, tokens per minute, daily usage, concurrent requests, or a provider’s temporary service-capacity restriction. The exact rules depend on the API provider, model, account, and plan.

Free access does not imply unlimited access. A free tier may have lower or changing limits than a paid tier, and different models within one service can have separate quotas. Some providers also distinguish between an account-wide allowance and a limit attached to a particular model or endpoint.

Read the response body as well as the status code. An error message may identify a limit type, model, or reset time. Treat that message as provider-specific rather than assuming every API uses the same wording or quota system.

Which headers and dashboard details to check

Inspect the complete response, including headers and the JSON error body. Providers may return headers describing remaining capacity or when a limit resets, but there is no universal header name or guarantee that every response includes them. Look for names that indicate a limit, remaining requests or tokens, and a reset time, and consult that provider’s API documentation to interpret them.

Retry guidance: A Retry-After header, when present, can specify how long to wait before trying again. Follow its format and value rather than immediately resending.
Rate-limit details: Headers may report a limit, remaining allowance, or reset interval. They might describe requests, tokens, or another resource, so do not confuse one quota with another.
Error body: Check for a clear indication such as a request-rate limit, token-rate limit, exhausted daily allowance, or temporary overload.
Account and usage page: Confirm the selected model, current usage, tier, and any stated reset schedule. A dashboard may show information that is not included in the response.

Headers can be hidden from browser-based JavaScript by cross-origin restrictions unless the server exposes them. If your browser code cannot read them, inspect the request through a permitted server-side client or diagnostic tool, or consult the provider’s dashboard. Do not publish API keys or full authorization headers when sharing a diagnostic log.

How to tell quota limits from traffic spikes

A burst of 429s immediately after sending many requests suggests a short-window rate limit or concurrency cap. Errors that continue after traffic stops, especially when the response mentions exhausted usage, may point to a daily or monthly allowance. A 429 that affects only one model can indicate a model-specific limit or capacity issue.

For example, an application that launches 20 prompts at once may exceed a requests-per-minute or simultaneous-request limit even if each prompt is short. Conversely, a few long prompts can use a token allowance quickly. Request counts alone therefore do not explain every 429.

Compare timestamps, model names, request volume, and token usage around the failures. If the provider reports a reset time, compare it with your retry schedule. If the response instead suggests service overload, repeated retries may add traffic without fixing the underlying problem.

Practical steps to reduce 429 errors

Read the error first. Record the status, response body, relevant headers, model, and time. Redact keys, personal data, and sensitive prompt content.
Honor any retry instruction. If Retry-After is present, wait for at least the specified interval. If the provider documents a reset time, schedule retries accordingly.
Use capped exponential backoff. When retrying is appropriate and no specific wait is supplied, increase the delay between attempts and add random jitter so multiple clients do not retry together. Set a maximum delay and a maximum number of attempts.
Limit concurrency. Queue work and send fewer requests in parallel. A queue can smooth bursts without requiring you to abandon useful requests.
Control token use. Avoid unnecessarily long prompts and outputs, and check token-related limits where the provider documents them. Do not assume that reducing request count alone will solve a token-rate limit.
Review quota and model selection. Confirm that the account has allowance remaining and that the chosen model is covered by the free tier. Change models only if the provider permits it and the alternative suits the task.

Retries need care: a request that reaches the service but returns an error may still be subject to provider-specific accounting. Also, retrying a non-idempotent operation can have side effects in other API contexts. For text-generation calls, make retry behavior bounded and inspect the provider’s documentation rather than building an infinite retry loop.

Free-tier limits, costs, and alternatives

There is no single “free LLM API quota.” Limits can vary by provider, account verification, model, endpoint, and time. Providers may change free-tier terms, so check the current official documentation and your own account page instead of relying on an old quota figure from a forum or comparison table.

If usage regularly exceeds the free allowance, reasonable options include reducing unnecessary calls, batching work only where the API supports it, scheduling requests within documented limits, or evaluating another provider’s current terms. A paid tier may offer different limits, but it does not necessarily remove rate limits or guarantee uninterrupted capacity. Compare the applicable model, rate limits, token allowances, data handling terms, and billing rules before switching.

Common mistakes and safe diagnostics

Treating every 429 as a daily quota failure: It may instead be a short-term request, token, concurrency, or capacity limit.
Retrying immediately in a tight loop: This can prolong throttling and create extra load. Use provider guidance and bounded backoff.
Assuming headers are standardized: Header names and meanings differ. Verify them against the relevant provider documentation.
Sharing secrets while debugging: Remove API keys, authorization values, private prompts, and account identifiers from logs before posting them publicly.

A 429 is not evidence by itself that an API key is invalid or that a provider is permanently blocking an account. Authentication failures commonly use other status codes, but implementations differ; use the response details and account page to distinguish the cases. If limits appear available and the error persists beyond the stated reset, contact the provider through its documented support channel with a redacted request ID and timestamp.

Frequently Asked Questions

What does a 429 error mean for an LLM API?
It means the service is limiting the request. The cause may be request frequency, token usage, concurrency, a usage quota, or temporary capacity; check the response and provider documentation.

Which headers show my LLM API quota?
There is no universal set. Look for provider-documented limit, remaining-usage, reset, and Retry-After headers, then compare them with the error body and account dashboard.

How long should I wait before retrying a 429?
Use the Retry-After value if supplied, or follow the reset guidance in the response or documentation. Otherwise, use capped exponential backoff with jitter rather than retrying continuously.

Can a free LLM API return 429 even with a small number of calls?
Yes. A few long prompts can hit a token limit, and a brief burst or concurrent requests can hit a traffic limit. The applicable limits depend on the model and provider.

Does a 429 mean my API key is invalid?
Not necessarily. A 429 usually signals throttling or a quota-related restriction, but status-code behavior varies. Check the error body and account status before drawing a conclusion.

Why can’t my browser code read the rate-limit headers?
Cross-origin rules may prevent browser JavaScript from accessing response headers that the API has not explicitly exposed. Check the provider’s browser-access guidance or inspect the response from an appropriate server-side client.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.