How to Handle LLM API Rate Limits, Timeouts, and Errors: Retries, Concurrency, and Backup Models
By LanoX Team. All facts checked on November 3, 2026 (Asia/Dubai). LanoX is the worked example; the approach applies to any LLM API.
Sort every failed call into 1 of 2 types before you retry: API key or parameter problems, which a retry will not fix, and temporary service issues, which a limited number of retries can. For rate limits (HTTP 429), reduce concurrency and wait; for service errors, cap retries and switch only to a backup model you have already tested. For image and video jobs, check the original task's status before resubmitting so you do not create and pay for a duplicate.
That is a summary of the LanoX homepage FAQ: "Check the error message first to distinguish API key or parameter problems from temporary service issues. If you hit a rate limit, reduce concurrency and wait before retrying. For service errors, limit retry attempts and, if needed, have your application switch to a backup model you have already tested. Before resubmitting an image or video request, check the original task's status to avoid creating duplicates." (checked 2026-11-03)
Which errors should you retry, and which not?
| Error type | Examples | Retry? | What to do |
|---|---|---|---|
| Key or parameter problem | Wrong or revoked key, wrong model ID, invalid request body | No | Fix the key, model ID, or request, then send again |
| Rate limit | HTTP 429 Too Many Requests | Yes, after waiting | Lower concurrency; wait before retrying |
| Temporary service issue | Timeout, server error | Yes, a limited number of times | Cap retries; fall back to a tested model if needed |
| Async image or video task | Status unclear after a timeout | Not until you check | Query the task status first |
LanoX has no single error-code table as of 2026-11-03, but its docs list the codes to handle. In the video API notes they say: "Clients must also handle 401, 402, 403/model-access errors, 404, 429, and 5xx-class business codes instead of relying only on HTTP status." and "Clients must inspect code in the response body." (checked 2026-11-03). So read the code and the error message in each response body, not only the HTTP status. HTTP 429 is the standard status code: MDN says it "indicates the client has sent too many requests in a given amount of time" (checked 2026-11-03).
How long should you wait after a 429?
If the response has a Retry-After header, use it. MDN says that in a 429 response it "indicates how long to wait before making a new request," given as a date or a number of seconds, for example Retry-After: 120 (checked 2026-11-03).
If there is no header, wait a little longer after each failed attempt and stop after a fixed number of tries. A suggested starting point is 3 retries at 1, 2, and 4 seconds. This is our suggestion, not an official LanoX setting; adjust it for your own app. Whatever you choose, keep a hard limit; unlimited retries during a rate limit only add load.
What are your actual rate limits?
Ask the API instead of guessing. On LanoX, GET /v1/models returns rpm_limit (requests per minute) and tpm_limit (tokens per minute) for each model your key can use. The docs say these fields are "Returned only when configured as a positive integer" and that "The response is filtered by API-key permissions" (checked 2026-11-03).
The docs' sample response shows rpm_limit 60 and tpm_limit 100000. Those are example values, not LanoX's limits; read the numbers for your own key. Set your app's concurrency below them so that bursts do not trip the limit.
When should you switch to a backup model?
Only after a capped number of retries fail, and only to a model you have already tested with your real requests. Before you rely on a backup:
| Check | Why |
|---|---|
| The backup model accepts your API format | supported_endpoint_types in GET /v1/models lists chat.completions, responses, or messages |
| It passes your 4 core tests | Streaming, tool calls, image input, and structured output can differ by model |
| Its price is acceptable | Check the model catalog |
| Your logs record which model answered | So usage and charges can be matched later |
For how to test a model's features after switching, see switching to an OpenAI-compatible API (coming soon).
Why are image and video errors different?
Image and video jobs are usually asynchronous: you create a task, then check its result. The lanox-image-2 docs describe the pattern as "create a task, then poll for the result with the task ID" and say "Poll every 2–5 seconds." (checked 2026-11-03). The task has 4 statuses:
| Status | Meaning | Terminal? |
|---|---|---|
queued | Created and waiting to run | No |
processing | In progress | No |
succeeded | Done; image URL is available | Yes |
failed | Failed; error message is available | Yes |
If the call that created the task timed out, do not create a new one straight away. Query the original task ID first. A task still queued or processing is still running, and resubmitting would create a second job.
What should you send support when something looks wrong?
Send the request time and request ID. The LanoX docs say: "If the records do not match, contact support with the request time and request ID so the call can be investigated." (checked 2026-11-03). You can reach support at support@lanox.ai or through the Contact page.
Remove the key before you share any log. The Security & Trust page says: "Redact keys from logs before sharing them for troubleshooting." (checked 2026-11-03)
How do you know if an API is reliable enough for production?
Measure it with your own traffic. The Security & Trust FAQ suggests testing "with real workloads" and measuring "success rates, response times, and performance under concurrent traffic," and notes: "A successful test call or a low price alone does not establish long-term reliability." (checked 2026-11-03)
If you need written availability commitments, the Enterprise page says: "Availability and response commitments can be defined within the contract." (checked 2026-11-03). LanoX publishes no uptime figure on its public pages as of that date.
Who is this guide not a good fit for?
- Codex or Claude Code users with a client-specific error. Use the Codex guide or the Claude Code guide; this article covers 2 general error types, not client screens.
- Teams that need a single error-code table. LanoX has no single table as of 2026-11-03; its docs name the codes to handle (401, 402, 403, 404, 429, 5xx), so read the
codein each response body and contact support. - Teams that need a public uptime number. Availability is defined only within an enterprise contract.
- Apps with no tested backup model. Test 1 first; an untested fallback can fail in new ways.
FAQ
- What does a 429 error mean?
- Too many requests in a given amount of time. Lower concurrency, wait (use
Retry-Afterif present), and retry a limited number of times. - Should I retry on every error?
- No. Retrying a wrong key, wrong model ID, or invalid request gives the same error. Retry only temporary issues, with a cap.
- Can retrying an image request charge me twice?
- It can create a second task. Check the original task ID first; poll every 2–5 seconds until it reaches
succeededorfailed. - Does LanoX publish its rate limits?
- Limits are returned per key in
GET /v1/modelsasrpm_limitandtpm_limit, when configured. There is no public default figure.
Sources
- LanoX homepage FAQchecked 2026-11-03
- docschecked 2026-11-03
- MDNchecked 2026-11-03
- MDNchecked 2026-11-03
- model catalogchecked 2026-11-03
- lanox-image-2 docschecked 2026-11-03
- Contact pagechecked 2026-11-03
- Security & Trust pagechecked 2026-11-03
- Enterprise pagechecked 2026-11-03
- Codex guidechecked 2026-11-03
- Claude Code guidechecked 2026-11-03