An LLM API rate limit controls how much traffic an account, project, or model can accept over a period. A 429 response is a starting point for diagnosis, not an instruction to retry indefinitely. Read the error body, identify the constrained resource, and stop retrying errors that require a funding or configuration change.
This guide uses provider documentation checked September 29, 2026. Limits differ by endpoint and account; it does not claim a universal requests-per-minute allowance.
Classify the failure before retrying
Keep the HTTP status, provider error code, timestamp, request ID, and relevant response headers. Exclude authorization headers and private prompts.
Provider terminology varies. OpenAI's rate-limit documentation describes request/token limit information and retry handling. Its spend-limit documentation also documents 429 responses for hard spending limits. Do not classify a request from the status number alone.
A Codex or Claude Code subscription usage window is a different control. Do not treat an API 429 as proof that a subscription reset is due.
Budget both requests and tokens
A short question and a repository-sized prompt each count as a request but can create very different token demand. Queue admission should account for the actual model's limiting dimensions.
As a hypothetical scheduling example, several workers launching large contexts together can trigger a burst even if the daily average looks modest. Stagger starts and keep a shared concurrency limit across workers. Per-process limits do not constrain the whole application when multiple processes run independently.
For cost accounting—not rate-limit arithmetic—use the coding Agent API cost worksheet. Cached-token treatment must follow the selected provider's current rules.
Use one bounded retry policy
Honor Retry-After when the provider supplies it. Otherwise follow its recommended increasing delays with jitter, plus a maximum attempt count and total deadline.
Check whether the SDK already retries. Application retries wrapped around SDK retries can multiply traffic unexpectedly. Give one layer ownership and record the final number of attempts.
A timeout does not prove the first operation never happened. Separate retrying model generation from rerunning a tool that writes files, sends messages, or creates external resources. Reconcile the earlier action or use an operation identifier supported by that system before repeating it.
Verify recovery under a small workload
Repeat a controlled task with lower concurrency. Record successful requests, final failures, retry count, and completion time. Recovery means useful work finishes within the chosen limits—not merely that the error message disappeared.
If it still fails, send the provider redacted identifiers and the narrow time window. Do not add workers to compensate for throttling.
Connect with a visible usage trail
The Agent.Space Developer API guide shows how to verify a request's key, model, protocol, and funding record. That evidence helps separate connection issues from account usage questions.
Open Agent.Space if you need that integration path. Start with one request and a small worker budget; no API connection should be interpreted as unlimited capacity.