Multi-provider LLM fallback: staying up when one API goes down

Originally published at https://pranjulrathour.scult.in/blog/multi-provider-llm-fallback. That copy is the canonical version and gets updates first.
Every LLM provider has bad hours. Rate limits tighten, a region degrades, a model version is deprecated on a Tuesday. If your product has one provider, its uptime is theirs. RAG.NextUpgrad ships with automatic multi-provider fallback because the first client demo I ever gave hit a provider outage — and I never wanted to explain that again.

The abstraction that makes it possible
Put every provider behind one interface: generate(messages, options) → stream of tokens plus usage. Keep prompts in a neutral chat format and translate to each provider's schema inside the adapter. The moment a prompt depends on one vendor's special syntax, fallback silently degrades quality.
Deciding when to fall back
- Hard failures — connection errors, 5xx, authentication errors — fall back immediately.
- Rate limits — retry once with backoff, then fall back; a queue of retries during an outage is a slow outage.
- Timeouts before the first token — fall back; after the first token, finish or fail cleanly rather than restarting with a different voice mid-answer.
- Content refusals — do not fall back automatically. A refusal is a signal, not an error.
Ordering providers
Order by quality for your evaluation set, then by cost. Keep a cheap, fast model as the last resort so the product degrades to "shorter, plainer answers" rather than "no answers". Record which provider answered each request; without that field you cannot debug a quality complaint.

What fallback cannot fix
- Bad retrieval — if the context is wrong, every provider will be wrong with confidence. Fix that with a confidence gate.
- Provider-specific behaviour your product relies on, such as a JSON mode or a tool-calling format. Test every provider against your schema.
- Cost surprises — a fallback to a pricier model during a long outage can double a month's bill. Cap fallback spend.
Choosing a primary provider deserves its own framework — I wrote one in choosing an LLM provider. Whatever you choose first, design so that the choice is reversible at runtime.
![]() | Pranjul Rathour GenAI engineer, Kanpur · 3x first-prize hackathon winner · campus mentor I ship production RAG pipelines, fine-tune LLMs and build agentic AI products end to end. I lead engineering at SCULT INDIA for a 14-member team and have mentored 200+ students through TechVerse Enclave. Open to: GenAI roles, hackathon judging, mentorship sessions and guest talks at colleges. Email: pranjulrathour41@gmail.com |
![]() Pranjul Rathour | ![]() Pranjul Rathour, GenAI engineer, Kanpur | ![]() In a packed college auditorium |








Comments
Post a Comment