EXPERIMENT_032 // FALLBACK.MODEL.ROUTER
A visitor triggers three model calls in sequence: a healthy primary response, a simulated primary failure that reroutes live to a lower-tier fallback model, and a simulated total outage that fails fast with a clear error — every result labelled with the model that actually served it.
LOADING EXPERIMENT...
Click one of three buttons and watch a real call go through @diabolicallabs/llm-client. "Healthy call" answers from the primary model, gpt-5.5. "Simulate primary failure" swaps in a broken model ID for the primary slot, so the same request comes back served by the fallback tier, gpt-5.4-mini, with a visible provenance badge and the originally-requested model shown alongside it. "Simulate total outage" breaks both slots, and the router fails fast with a worded error instead of a blank result. Every run is a live call to the real OpenAI API — nothing here is mocked or cached between clicks.
HOW IT WORKS
`@diabolicallabs/llm-client`'s `createClient()` accepts `LlmClientConfig.model` as a string array — the first entry is the primary model, later entries are fallback tiers, and `fallbackOn` names the error kinds that trigger the switch. This experiment passes `["gpt-5.5", "gpt-5.4-mini"]` and lets the toolkit's own retry-and-swap logic run. No local model, no Ollama bridge, no toolkit-bypass exception — every call here goes through the same single entry point as every other Labs surface.
The two failure-simulating buttons swap a deliberately-invalid model ID into the primary or both array slots. OpenAI rejects an unrecognised model ID immediately with a `not_found` error — the default `fallbackOn` kind — before generating a single token, so the failure is real and live against the production API on every click, not a stubbed response, and it carries no meaningful inference cost. A model ID that stops resolving is also exactly what a pulled model looks like from a caller's side.
`LlmResponse.model` always carries the model that actually served the response; `LlmResponse.requestedModel` is populated only when the toolkit's failover fired. Provenance is exactly that check — fallback when `requestedModel` is present, primary when it is not — computed fresh on every request server-side, never cached, so toggling between modes mid-session changes the badge on the very next click.
"Simulate total outage" breaks both array slots. Once the toolkit exhausts every model in the array it throws, the route catches that error and returns a 502 with a plain worded message — never a silent empty response and never a raw provider error or stack trace. The router prefers an honest failure to a quiet one.
WHAT THIS PROVES
This is a routing pattern the fleet can adopt directly, not just a demo. Diana's scheduled jobs currently fail hard on a single provider outage; this shows the exact toolkit primitive — already installed at `@diabolicallabs/llm-client` v6.2 in this repo — that hardens any of them with a two-line config change and zero new dependencies. No new provider, no bypass exception, no separate process to babysit.
It is grounded in a real incident, not a hypothetical. Fable 5 launched on 2026-06-09 and was pulled three days later, on 2026-06-12, by a US export-control directive, alongside Mythos 5. A frontier model that stops resolving mid-production is not an edge case anymore — this experiment routes around exactly that failure mode, live, with the provenance of every response labelled so nobody has to guess which model actually answered.