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

How to design automatic fallback across LLM providers: provider abstraction, health checks, prompt portability, cost-aware routing and the failure cases that a retry loop cannot fix.

Requirements gathering, on stage
Requirements gathering, on stage

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

  1. Bad retrieval — if the context is wrong, every provider will be wrong with confidence. Fix that with a confidence gate.
  2. Provider-specific behaviour your product relies on, such as a JSON mode or a tool-calling format. Test every provider against your schema.
  3. 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.

LLM appsReliabilityArchitectureRAG
Pranjul Rathour
Pranjul Rathour
GenAI Engineer · Kanpur, Uttar Pradesh, India

GenAI engineer and AI product builder with 2+ years shipping production-grade AI systems: RAG pipelines, fine-tuned LLMs, hybrid retrieval and multi-modal apps across vision, speech and OCR, architected end to end from ingestion to deployment. Leads engineering for SCULT INDIA's 14-member team, founded the 500+ member TechVerse Enclave community and has mentored 200+ students. Three hackathon first prizes: Changethon 2025 (IIT Roorkee), Product Genesis at Vividhotsava 2025 (CSJMU Kanpur) and BYTEBATTLE (MeetKats).

Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at colleges. Email pranjulrathour41@gmail.com.

Keep reading

More on RAG & retrieval

All RAG & retrieval posts →
Campus talks · hackathon judging · mentoring

Want this as a live session at your college?

Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at colleges.

Pranjul Rathour, GenAI engineer in Kanpur