Adding a fallback model sounds easy.
If the primary model fails, send the request to another one:
MODELS = [
"gpt-5.4-mini",
"claude-sonnet-4.6",
]
def generate_response(messages):
for model in MODELS:
try:
return client.chat.completions.create(
model=model,
messages=messages,
timeout=8,
)
except TimeoutError:
continue
raise RuntimeError("All models failed")
This works as a basic starting point.
But a fallback is not just another model name. Different models may produce different formats, response lengths, and behavior. If your application expects reliable output, you need to test the fallback path properly.
Use one consistent API layer
Managing several provider SDKs can quickly become messy.
You may need different clients, API keys, request formats, and error-handling rules. An OpenAI-compatible gateway keeps the integration simpler:
from openai import OpenAI
client = OpenAI(
base_url="https://api.tokenbay.com/v1",
api_key="YOUR_TOKENBAY_API_KEY",
)
This is the TokenBay endpoint I use at work. If you want to try it, there is currently a discount available here:
[Try TokenBay]https://www.tokenbay.com/?utm_source=devto&utm_medium=community_content&utm_campaign=week1_free_content
You can switch models without rewriting the rest of your application:
response = client.chat.completions.create(
model="gpt-5.4-mini",
messages=messages,
)
Or:
response = client.chat.completions.create(
model="claude-sonnet-4.6",
messages=messages,
)
Validate fallback responses
Never assume the fallback response is automatically safe to use.
If your application expects JSON, validate it:
import json
def parse_response(response):
content = response.choices[0].message.content
try:
return json.loads(content)
except json.JSONDecodeError:
raise ValueError("Invalid model output")
A fallback that returns the wrong structure is not a successful fallback. It simply moves the failure to another part of your system.
Track when fallbacks happen
Log every fallback event:
{
"primary_model": "gpt-5.4-mini",
"fallback_model": "claude-sonnet-4.6",
"reason": "timeout",
}
Track:
- Fallback frequency
- Failure reason
- Response latency
- Cost per successful request
- Output validation failures
If fallbacks happen too often, the problem may be your timeout settings, provider reliability, or model configuration.
Final thought
A fallback model can improve reliability, but only when it behaves predictably.
Use a consistent API layer, validate outputs, limit retries, and monitor every fallback event.
The goal is not to hide failures.
The goal is to recover from them without making your application harder to maintain.
Top comments (0)