Stop Hardcoding Model Fallbacks: Let Production Data Pick Your Paths

Stop Hardcoding Model Fallbacks: Let Production Data Pick Your Paths You've seen the pattern. Maybe you've written it: def call_model ( prompt : str ) -> str : try : return call_gpt4o ( prompt ) except Exception : try : return call_claude ( prompt ) except Exception : return call_gpt4o_mini ( prompt ) Nested try/excepts. A fallback chain. It feels like resilience. It's not. This pattern has three problems that compound in production: it's static, it's exception-only, and it never learns. Why Hardcoded Fallbacks Break Down Problem 1: They only catch exceptions. The most common production failure mode for LLM calls is not an exception — it's a valid API response with bad output. The model returns HTTP 200 with a response that doesn't parse, doesn't match your schema, or gives an answer that's technically formed but factually wrong. Your try/except doesn't catch any of that. The broken response flows downstream as if it succeeded. Problem 2: They're static. You wrote the fallback order on