Class 09 taught you that every AI request spends a context budget. Now a new question appears: once you have a focused task and a clean context package, which model should receive the request — and how do you reach it without rewiring your whole setup each time?

That is the problem OpenRouter solves. It is not a model company and not a coding agent. It is a routing layer that sits between your app or agent and models from many providers.

The problem: every provider speaks its own dialect

OpenAI, Anthropic, Google, Qwen, GLM, DeepSeek, and others each offer capable models. But left to yourself, each one means:

• a different API format and SDK behavior,
• a separate account, API key, and billing relationship,
• different model names, availability, and price changes,
• a different dashboard for tracking spend and failures.

For one experiment that is tolerable. For a real workflow — where you want to try a second model, survive an outage, or use a cheaper model for routine work — it becomes friction. Students stop comparing models, not because comparison is useless, but because switching is annoying.

The core idea: one interface in front of many providers

OpenRouter gives your agent or application a single, stable place to send requests, then forwards each request to the provider and model you selected.

Your app or coding agent
          ↓
      OpenRouter
          ↓
OpenAI / Anthropic / Google / Qwen / GLM / DeepSeek / others

More precisely, the layers look like this:

Project: task brief + context filesAgent or app: sends one shaped requestOpenRouter: routes the requestProvider: hosts and serves the modelSelected model: reasons and respondsFiles, commands, tests, output

Your project files never "live" on OpenRouter. The task brief, the selected files, and the tool results travel as the request payload; OpenRouter passes that payload to the chosen provider, returns the provider's response, and records the routing facts — which model served the request, how long it took, and what it cost.

What OpenRouter actually gives you

Four things, each worth naming separately:

1. Unified API access. Your agent learns one request shape. Switching from one provider's model to another is a change of model identifier, not a rewrite of your integration. 2. Model discovery. The OpenRouter catalog lists models from many providers in one place, with prices, context lengths, and availability visible side by side. You will use this catalog in Class 11 when you investigate model families. 3. Provider choice. For some models, more than one provider can serve the same model weights. OpenRouter lets you pick which provider handles your request — a choice with price, speed, and privacy consequences you will learn to make in Lesson 10.2. 4. One billing layer. You fund one OpenRouter balance (credits) instead of maintaining balances with every provider. Per-request costs still differ by model and provider, which is why Class 12 turns this visibility into a cost-control habit.

What OpenRouter is not

This distinction is the whole lesson, so state it plainly:

If the reasoning is weak, the model is the suspect. If the agent never read the right files, the harness is the suspect. If the request never reached a working provider, the route is the suspect. Class 07 taught you to locate failures by layer; OpenRouter simply adds one well-lit layer between your agent and the model.

Why this matters now

Without a routing layer, every model comparison is a small migration project. With one, comparison becomes a decision: same repository, same prompt, same test — different model identifier. That is what makes Lessons 10.2 through 10.4 possible:

• Lesson 10.2 gives you the vocabulary of routes and fallbacks.
• Lesson 10.3 teaches you what crosses the data boundary when you route a request outward.
• Lesson 10.4 puts OpenCode and OpenRouter together into a controlled multi-model coding setup.

Practical exercise: trace one request

On paper or in a Markdown file, trace this request through every layer:

Write one sentence for each step:

1. What does the project contribute (files, instructions)? 2. What does the agent (OpenCode) do before anything leaves your machine? 3. What does OpenRouter receive, decide, and forward? 4. What does the provider do? 5. What does the model produce? 6. What comes back to you, and where does it land (files, terminal, chat)?

Done looks like: a six-step trace with each layer's job in your own words.

Quick verification: cover the diagram above and re-explain the path to someone (or to a fresh chat) without saying "OpenRouter is the AI." If you can name what each layer adds, you have the mental model.

Common failure mode: describing OpenRouter as "the model that answers." If your trace has OpenRouter doing the reasoning, redraw it — the model reasons; OpenRouter routes.

Check your understanding

1. What problem does a routing layer solve that a single provider's API does not? 2. What travels from your machine to OpenRouter, and what does OpenRouter do with it? 3. Name two things OpenRouter gives you besides forwarding requests. 4. Why is "the AI failed" too vague once a routing layer is involved?