Choosing a model per request

The Chat view has a model picker — a dropdown that sets which model answers, sitting right alongside the mode dropdown you’ve been using all course. The two are independent: the mode decides how much latitude Copilot has, the picker decides how much reasoning it brings. And like the mode, the picker is a per-request choice. You’re not committing the whole session to one setting; you pick what this next request deserves, then pick again for the one after it.

What’s in the list isn’t fixed

Two things shape what you actually see in that dropdown, and it’s worth knowing both so an empty-looking list doesn’t confuse you later.

The first is your plan. What’s offered is gated by the Copilot plan you’re on — a richer plan exposes more options, a leaner one fewer. The second is the surface you’re working in. The available choices differ depending on whether you’re in Ask, Edit, or Agent — the support table genuinely has different columns for each, so a model you can reach for in one mode may not appear in another. That’s not a bug; it’s the plan-times-surface gating doing its job.

There’s also an Auto model selection mode in the picker. Instead of you choosing, Copilot routes the request to a fitting model for you — and the same Auto behavior spans Copilot’s other surfaces too, the cloud agent and the CLI, not just the Chat view. It’s the sensible default when you don’t have a strong opinion about a given request. The rest of this lesson is about the requests where you should have an opinion.

When to reach for more reasoning

Higher reasoning earns its keep when the task is genuinely hard to get right — where a plausible-looking answer can be subtly wrong and the cost of wrong is high. That’s exactly the shape of the work you did in Act 1.

The shared-lib refactor was that kind of task. You were threading a new event type through an audit helper and a validation rule that a dozen services lean on, where the failure mode isn’t “it doesn’t compile” — it’s “it compiles, looks fine, and quietly breaks a consumer three repos away.” Reasoning that holds more of the picture at once and checks its own work is worth paying for there. This is the thinking counterpart to the tight permissions you used on the same code: hard problem, high blast radius, so you give the agent your best read.

When to reach for less

The routine CRUD in orders-service is the opposite. Adding a straightforward endpoint, wiring a handler, the kind of well-trodden code where the right answer is the obvious one — that work doesn’t get better answers from a heavyweight reasoning pass. It gets the same answer, slower and more expensively. Reaching for the deepest model here is like turning permissions all the way down on a one-line fix: effort spent where there’s nothing to protect.

So the call mirrors the action dial exactly. Ask the same question you learned to ask about autonomy, pointed at reasoning instead: is this a task where thinking harder actually changes the answer? On the gnarly library change, yes — turn it up. On routine app work, no — Auto or a lighter pick is fine, and your credits go further.

That word — credits — is the part we’ve been circling. The heavier setting costs more, and on a company plan you’re not the only one deciding what “more” means. Spending credits where it pays.