Model fallback: bound attempts and preserve the deadline

Current snapshot

Separate the client decision from server work

A fallback is a second route after an eligible first-route failure. This deterministic lab computes start times, response times, client timeouts and a shared end-to-end deadline for one request. It sends no network traffic and does not measure a provider. Route A starts at zero. Route B can start only after A’s client wait ends, and at most two attempts are allowed. If A times out, its server may still be working while B runs. The client closes A and ignores its later response; starting B does not establish that A was cancelled or free. The final panel distinguishes attempts made, late responses and routes still outstanding when the client returns.

Choose the primary outcome and two independent budgets

Primary fixture chooses Success at 200 ms, Unavailable 503 at 100 ms, Invalid request 400 at 100 ms, or Slow success at 900 ms. Per-route timeout is 250, 500 or 1000 milliseconds and applies separately to each dispatched route. Global deadline is 400, 800 or 1600 milliseconds from the original A dispatch. Each wait ends at the earliest of server completion, its route timeout and the global deadline. A server completion exactly at a boundary is processed first in this fixture; this explicit tie rule is a simulation assumption, not a distributed timing guarantee. A short global budget can therefore expire even when a route still has time left on its own timeout.

Require eligible failures and a compatible route

The policy allows one fallback after a 503 or a client timeout. A 400 ends the request without B because replaying a malformed request does not fix it. The provider troubleshooting reference distinguishes transient failures from client errors; this lab is a deliberately small routing policy, not its recommended full retry implementation. Secondary contract chooses Compatible or Missing required tool. An incompatible route is never dispatched, even when A failed transiently. Secondary fixture selects a 200 ms success, a 100 ms 503 or a 900 ms slow success. Choosing a backup does not imply independent infrastructure, equal model quality or support for the same capabilities.

Reproduce recovery, deadline failure and late work

With the defaults, A returns 503 at 100 ms and B succeeds 200 ms later, so the client returns B at 300 ms after two attempts. Change A to Success: only A runs, finishing at 200 ms. Restore Unavailable and choose an unavailable B: both attempts fail, ending at 200 ms. For the timeout experiment choose Slow success for A, a 250 ms route timeout, an 800 ms deadline and a successful compatible B. A times out at 250, B wins at 450, and A eventually finishes at 900. A is still outstanding at client close, and its late success cannot replace B. Reduce the deadline to 400: B has only 150 ms left, so the client closes without a response at 400. Increase the route timeout to 1000 and deadline to 1600: A can now succeed at 900 without B.

Inspect the playback and preserve observations

Play reveals eight stages over sixty teaching seconds; Pause freezes the view. Next event moves to the next seven-and-a-half-second boundary. Restart rewinds while keeping the inputs and speed. Time seeks and pauses; Speed changes the inspection pace to quarter, half, normal or double. Input changes rewind and pause; hiding the tab pauses. The final result is disclosed only at sixty seconds even though all virtual millisecond events are precomputed. Export events JSON saves the full model and the inspected prefix. Capture baseline, Replace baseline and Clear baseline manage comparisons. Notebook notes persist locally and Export notes saves them. Expand experiment and Exit full screen adjust the workspace. Scrollable event history is keyboard accessible.

Keep the production limitations explicit

There is no streaming, partial-answer reuse, tool execution, billing, authentication, safety refusal handling, automatic SDK retry, backoff, jitter or Retry-After handling here. Production retries may multiply attempts underneath a routing layer, so enforce budgets across layers. A safety refusal must not be treated as a reason to bypass the same policy through another model. Real cancellation requires provider support and acknowledgement; this fixture deliberately assumes dispatched work continues to its scripted server completion. The figures illustrate scheduling arithmetic and failure boundaries, not availability or cost forecasts.