Class 06 taught you to operate a CLI agent; Lessons 10.1 through 10.3 taught you routing, fallback policy, and privacy. This lesson joins them into one working setup: OpenCode as the harness, OpenRouter as the routing layer, and you as the director of a controlled comparison.

Bridge: from one CLI, many models — to a real routing layer

Lesson 6.6 ("One CLI, Many Models") gave you the core separation: the CLI harness does the operating, the model does the reasoning. OpenRouter makes that separation practical across providers. Instead of maintaining a key and integration per company, OpenCode sends requests through one routing layer where swapping models is a configuration choice, not a migration.

The roles, stated once and kept for the rest of the tab:

OpenCode      = coding-agent harness (reads files, edits, runs commands, asks approval)
OpenRouter    = model/provider routing layer (forwards requests, offers choice + fallbacks)
Selected model = reasoning engine (produces analysis and proposed actions)
Project files  = context and work surface (what the work is about and where it lands)

You: brief, approvals, verdictOpenCode harness: project + toolsOpenRouter: route + fallbackFiles, tests, terminal output

When something goes wrong, this diagram is your diagnostic map: a bad brief is your layer, unread files are the harness layer, weak reasoning is the model layer, an outage or surprise bill is the routing layer, and a failing test is the work surface telling the truth.

When this setup earns its keep

Do not make every task a model experiment — Lesson 6.6 warned against exactly that. Reach for the multi-model setup when one of these is true:

• Compare models on one bounded task. You have a real decision (pick a default coding model) and want evidence instead of opinions.
• Spend less on routine work. A lower-cost model handles exploration, reformats, and first-pass reviews; the stronger model is reserved for hard reasoning.
• Reserve strength for hard problems. Architecture changes, subtle bugs, and large refactors justify the expensive route — deliberately, per task.
• Reach an open-weight or regional family. A Qwen, GLM, or DeepSeek release you want to evaluate (Class 11) is one route identifier away instead of a new integration.

Default to one trusted model for daily work. Promote a task to multi-model treatment only when the decision or the savings justify the overhead.

The controlled comparison method

A comparison is only evidence if everything except the model stays fixed. Four constants, no exceptions:

Then run each model in a fresh session (Class 09's reset rule: no CONVERSATION.md carryover advantaging one candidate), collect the same measurements — result quality, correction required, time, cost, tool-use reliability — and record the verdict with its evidence. Class 11 will give you the scorecard; what matters here is the discipline: change one variable, keep the rest honest.

A minimal brief template you can reuse:

MODEL-EVAL-BRIEF.md
Task: <one concrete task, e.g., "Refactor src/cart.ts so discounts apply once">
Repository state: <commit hash or branch — identical for all runs>
Allowed files: <the smallest useful set>
Do not: <edits outside the set / running migrations / touching secrets>
Acceptance criteria:
  1. <checkable fact>
  2. <checkable fact>
  3. <tests + browser check>
Record for each run: model + provider, time, cost, correction needed, verdict.

Setup, kept deliberately light

Class 06 already established the CLI workflow, so this is configuration, not a new education:

1. Install and orient OpenCode per its current docs at opencode.ai — OpenCode itself is open-source and free. Start it from the project root, confirm it can read files and propose (not yet execute) changes. You can connect your own provider keys, log in with existing subscriptions you already pay for (such as GitHub Copilot or ChatGPT Plus/Pro), or use OpenCode Zen — its optional pay-as-you-go subscription (around $20 credit to start) for a curated set of reliable, pre-tested coding models with transparent per-request pricing, spend limits, and zero-retention hosting. See opencode.ai/zen for current details. 2. Create an OpenRouter account and key at openrouter.ai, fund a small credit balance, and note the spending ceiling from your Lesson 10.2 fallback policy. OpenRouter and Zen solve the same routing problem two different ways — OpenRouter gives you the widest catalog to compare any model for any job; Zen gives you a smaller, validated short-list that just works for coding agents. 3. Point OpenCode at OpenRouter using the current provider configuration in the OpenCode docs — interfaces change, so follow the official path and treat any click path here as perishable. Confirm which model identifier each request will use. 4. Set the guardrails first: per-task budget, an allow-list of two or three approved models, approval before long agent loops, and logging of model + cost for every evaluation run (Class 12 makes these permanent). 5. Verify with a read-only task: "Do not change anything. Map this repository and list the files relevant to <task>." Confirm the right model served the request, the spend registered, and no file changed.

Because provider identifiers, dashboard layouts, and pricing pages change, treat OpenRouter's catalog and the OpenCode docs as the live sources and this lesson as the durable reasoning around them.

Practical exercise: write a model-evaluation brief (no expensive runs needed)

Without running anything costly, write a MODEL-EVAL-BRIEF.md for one real task in your own project:

• the task in one paragraph,
• the frozen repository state,
• the smallest useful file set,
• the "do not" list (including secrets and off-limits commands),
• three to five checkable acceptance criteria,
• the exact test or browser check that decides success,
• the two or three candidate routes (model + provider) and why each earned a slot,
• your fallback policy and per-task spending ceiling from Lesson 10.2,
• the privacy classification of the context from Lesson 10.3.

Done looks like: a one-page brief file another person could execute without asking you clarifying questions.

Quick verification: hand the brief to a fresh agent session (or a colleague) and ask: "What would you do first, and what would you refuse to touch?" If the answers match your intent, the brief is tight enough to make a future comparison fair.

Common failure mode: a brief that says "improve the checkout flow." That is three tasks wearing one coat. Narrow it until the acceptance criteria fit on one screen.

Check your understanding

1. What is each layer's job: OpenCode, OpenRouter, the model, the project files? 2. Name two situations where the multi-model setup is worth the overhead — and one where it is not. 3. What four things must stay identical across runs for a comparison to count as evidence? 4. Why should guardrails and the evaluation brief come before any expensive run?