Lesson 10.1 showed you the shape of the multi-model world: your agent, OpenRouter in the middle, many providers behind it. Now you need the vocabulary to make a deliberate decision inside that shape — because "just use the good model" falls apart the moment you ask which provider serves it, what happens when it is down, and what the request costs.

The four words to get exactly right

Three supporting terms complete the picture:

• Latency — how long a request takes to return. A strong model that takes three minutes may be wrong for an interactive coding loop.
• Uptime (availability) — whether the route is actually reachable right now. Providers have outages, capacity limits, and rate limits.
• Request compatibility — whether the provider supports what your request needs: the context length, tool-calling format, image inputs, or structured output your agent relies on. Not every provider serves every feature for every model.

Why one model can have several providers

This surprises newcomers: the same named model is sometimes available through more than one provider on OpenRouter. The weights may be identical, but the route is not. Different providers can differ on:

• Price — per-million-token input and output rates vary by host.
• Availability — one provider may be down or rate-limited while another serves the same model fine.
• Speed — inference hardware and load differ, so latency differs.
• Privacy setting — logging and data-retention terms differ by provider (the subject of Lesson 10.3).
• Performance details — quantization, context-length support, and tool-format compatibility can differ on some routes.

So the decision is never just "which model." It is always "which model, served by whom, under which terms." That pair — model plus provider plus settings — is your route.

Compare five things before you commit

For any route you are considering, check these five columns side by side on OpenRouter:

No route wins all five. A cheap route with poor tool support is a bad coding route. A strong route with high latency is a bad interactive route. Class 08 taught you there is no best model for every job; the same logic applies to routes. Lesson 10.4 will put this comparison to work inside OpenCode, where the route you pick determines which reasoning engine drives the same harness.

A simple fallback policy

Automatic retry feels reassuring until it quietly spends your budget on a loop. Write the policy down before you need it. Every fallback policy needs four lines:

Preferred model:      <model + provider>
Approved alternative: <model + provider, or "none">
Stop condition:       <e.g., 2 attempts total, then stop and notify a human>
Spending ceiling:     <e.g., $X per task / $Y per day — stop instead of exceeding it>

Two worked examples:

Customer-support assistant (low stakes, high volume):
  Preferred:    fast inexpensive model via Provider A
  Alternative:  same model via Provider B (one retry)
  Stop:         after 2 attempts, show a "try again shortly" message and log the failure
  Ceiling:      $0.02 per conversation; never escalate to the flagship reasoning model automatically

Hard coding task (high stakes, low volume):
  Preferred:    strong coding model via Provider A
  Alternative:  previous-generation coding model via Provider B (one retry)
  Stop:         after 2 attempts, stop and hand the error to the human — do not chain further models
  Ceiling:      $3 per task; ask approval before any run expected to exceed it

Notice what the policy prevents: silent escalation from a cheap model to an expensive one, endless retry chains, and a bill discovered after the fact. You will turn ceilings like these into enforced guardrails in Class 12.

When automatic fallback helps — and when a human should choose

Let the fallback run automatically when:

• the task is routine and low-stakes,
• the alternative is pre-approved and similarly priced,
• the stop condition is short (one retry, then stop),
• a failure is merely annoying, not dangerous or expensive.

Stop and bring in a human when:

• the alternative costs much more than the preferred route,
• the failure might be in your prompt or context, not the provider (retrying a broken brief wastes money twice),
• the task touches credentials, production, money, or other people's data,
• the error message suggests a permissions, privacy, or compatibility problem rather than a transient outage.

The rule of thumb: automate recovery from provider problems; do not automate recovery from task problems. If the brief was unclear or the context was wrong, a different model reading the same broken input usually produces a differently worded failure.

Send request on preferred routeUse the result, log model + costTry approved alternative onceStop, notify human, keep the error

Practical exercise: write two fallback policies

Pick two real scenarios (or use the pair above): one routine, high-volume task and one difficult, high-value task.

For each, write the four-line policy: preferred model, approved alternative, stop condition, spending ceiling. Then add one sentence explaining why the alternative is acceptable — same capability at a different provider, or a weaker model that is fine for this task.

Done looks like: two four-line policies plus two justification sentences, saved in a Markdown file.

Quick verification: for each policy, answer: what happens on the third consecutive failure? If the answer is anything other than "it stops and a human sees the error," tighten the stop condition.

Common failure mode: approving "any available model" as the fallback. An unbounded fallback is not a policy — it is permission to spend. Name the alternative explicitly.

Check your understanding

1. What is the difference between a model, a provider, and a route? 2. Why might the same model cost different amounts through two providers? 3. What four lines does every fallback policy need? 4. When should a failure stop and notify a human instead of retrying automatically?