Frontier model APIs go down more often than anyone admits in their status page. A 500 here, a 30-second timeout there, a quiet rate limit on a Friday afternoon. Most chatbots treat any failure as a fatal error and either show a generic 'something went wrong' or just spin forever. Visitors close the tab and the chance to convert is gone, with no log of what they were going to ask.

SleekAI lets you configure a fallback model per bot. Set GPT-4o as primary and Claude 3.5 Sonnet as fallback, or Gemini 1.5 Pro as primary and an OpenRouter mix as fallback. When the primary call returns an HTTP error, hits a rate limit, or exceeds your timeout, SleekAI retries the same request against the fallback. The conversation state, the resolved variables, the user message all carry over. The visitor sees a reply that is at most a second slower than usual, with no error to dismiss.

Generic chatbots are wired to a single provider and a single API key. When that provider blips, the whole widget is dead. Self-hosted retry logic is possible in theory but the code to do it correctly across different SDKs and error formats is more work than most teams want to maintain. SleekAI handles the cross-provider translation so the fallback just works.

Treating any AI chatbot as critical infrastructure means accepting that single-provider deployment is fragile. Frontier providers have outages, throttling, capacity issues during launches, and occasional bad deploys that turn one of their models flaky for hours. None of this is unusual.

What is unusual is the small number of sites that have actually planned for it. Most just wait out the outage and lose whatever conversions and support load happened during that window. The cost of running with a fallback is essentially zero until it fires.

The configuration is a five-minute setting in the bot dashboard. The two API keys are already needed if you use more than one provider for cost reasons or for testing. There is no separate monitoring service, no infrastructure to maintain, no integration code to write.

The fallback model uses the same prompt and the same conversation state, so quality remains consistent. The risk of running without a fallback is asymmetric: you save nothing in normal operation and you take the full hit during outages. The risk of running with a fallback is bounded: you spend a fraction more on tokens during the rare retries and gain availability the rest of the time.