Claude Code hit a rate limit. Now what?

Not every error should fall back

OpenLLM classifies each failed hop and picks one of four actions, so a fallback never makes a bad request worse.

• ▸Network blips, timeouts and 5xx errors: retry the same model once, then move on
• ▸Rate limits and exhausted quota: cool that model for a minute or two and try the next hop
• ▸Model not found or a content refusal: try the next hop without cooling
• ▸Malformed or oversized requests: return the real error and stop, since every model would reject it

Fallback chains when a model is rate-limited

Define an ordered chain per model alias. When a hop returns a rate limit, an overload or a provider error, the request moves to the next hop instead of failing your session.

• ▸Chains are configured once and shared by every client and device
• ▸Each hop resolves its own model settings, so a fallback never inherits the wrong parameters
• ▸Every hop that ran is visible in your request history

Why stopping matters for cost

Moving a request that can't succeed to another model only misses that model's prompt cache and bills you again. Returning the real error lets your corrected retry land warm on the same model.

See where the tokens go

Requests, tokens, latency and API-equivalent cost per model and provider, with charts you can export or share.