One interface: a fake, an HTTP-shaped client and a recorder
The HTTP-shaped client talks to a fake transport, so the example is offline. The pattern is the same one the real client in Topic 2.9 uses.
Give your code one tiny ChatModel interface and put every real client, fake and recorder behind it. Features then never learn which provider they use, tests need no key, and switching providers becomes a configuration change.
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 a class Counter that wraps any model and counts how many times complete was called (calls attribute), returning the wrapped model's reply.
Write make_model(config) that returns a FakeModel for {"provider": "fake"} and raises ValueError("unknown provider: ...") otherwise.
Explain it without notes
What problem does a ChatModel interface solve?
How do fakes, recorders and real clients fit together?
What can't an interface hide when switching providers?
Expected output
fake -> Rain Expected In Pune
recorded 1 call(s), 2 messages in the first
fake -> Untitled
http -> Title: Rain is expected in Pune this week
recorded 1 call(s), 2 messages in the first
satellite -> config error: unknown provider: satellite