Choosing a model per request

The Chat view has a model picker - a dropdown that sets which model answers, sitting alongside the agents dropdown you use to select roles. The two are independent: the role decides how much latitude Copilot has, the picker decides how much reasoning it brings. And like the role, the picker is a per-request choice. You are not committing the 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

The picker is deliberately not a fixed catalog. The available models change as GitHub adds and retires them, and two things shape what you actually see.

The first is your plan. What is offered is gated by the Copilot plan you are on - a richer plan exposes more options, a leaner one fewer. The second is the surface you are working in. Current supported-model listings (as of September 2026) are keyed by client and surface - Copilot Chat in an IDE, the Copilot CLI, the cloud agent, the app - so a model reachable in one surface may not appear in another. That is not a bug; it is plan-times-surface gating doing its job. Use the picker and GitHub’s current supported-models documentation as the source of truth rather than memorizing model names.

There is also an Auto model selection option 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 is the sensible default when you do not 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.

The shared-library refactor in this course’s scenario is that kind of task: threading a new event type through an audit helper and a validation rule that a dozen services lean on, where the failure mode is not “it does not compile” but “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 would use on the same code: hard problem, high stakes, so you give the agent your best read.

When to reach for less

Routine CRUD in your own 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 does not 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 is nothing to protect.

So the call usually mirrors the action dial (the autonomy setting the role controls). 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 (the metered spend Copilot requests draw on) go further.

Try it

Open the model picker and note what is available on your plan. Give Copilot a mechanical task - rename a variable across a file - on the default model, then switch to the strongest model available and ask a design question about the same code. Compare the depth of the two answers; the rename should not get better, and the design question probably should.

The heavier setting costs more, and on a company plan you are not the only one deciding what “more” means. Spending credits where it pays covers the meter.