A fallback chain with a deadline
Each model's behaviour is scripted. The deadline and timeouts are on a simulated clock.
When your main model is slow or down, a fallback chain tries the next model within a deadline, a circuit breaker stops you calling a provider that keeps failing, and graceful degradation gives users something useful instead of an error.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 6 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write first_working(models, call) that tries each model name in order using call(name) (which returns a string or raises RuntimeError) and returns (name, reply) for the first that works, or None. Test it with a call that fails for "a" and works for "b".
Write a Breaker class with failures and is_open(): it opens once failures reaches 2, and success() resets the count. Print is_open() after 1 failure, 2 failures, and after success().
Explain it without notes
How does a fallback chain work, and which failures should trigger the next model?
Why do you need a deadline as well as a per-attempt timeout?
Describe the three states of a circuit breaker and when it moves between them.
What is graceful degradation and what are two examples for an LLM feature?
Expected output
request 1: medium-model after 750 ms
path: big-model 429 (50 ms) -> medium-model ok (700 ms)
reply: from medium-model
request 2: small-model after 2000 ms
path: big-model timeout (1500 ms) -> medium-model 503 (100 ms) -> small-model ok (400 ms)
reply: from small-model
request 3: canned message after 3000 ms
path: big-model timeout (1500 ms) -> medium-model timeout (1500 ms) -> deadline reached
reply: Sorry, I can't answer right now. Please try again in a minute.