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

Pranjul Rathour
Pranjul Rathour

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.

On the mic
On the mic

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.

Presenting to a room
Presenting to a room

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.

From my carousels
7 Levels of RAG Apps
7 Levels of RAG Apps, slide 17 Levels of RAG Apps, slide 2
7 Levels of RAG Apps, slide 37 Levels of RAG Apps, slide 4
Full carousel on Instagram and LinkedIn.
Pranjul Rathour
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.
On stage, at hackathons and on campus
Pranjul Rathour
Pranjul Rathour
Pranjul Rathour, GenAI engineer, Kanpur
Pranjul Rathour, GenAI engineer, Kanpur
In a packed college auditorium
In a packed college auditorium

Comments

Popular posts from this blog

Forming a hackathon team: roles, skills and the mistake most teams make

Hello from Kanpur: what I build, and what I'll write about here

I built 15 free tools, 1,211 prompts and a 50,000-skill library — here's what's inside tools.scult.in