GitHub Copilot Model Picker Explained 2026

What the model picker is and where it lives

The model picker is the control that decides which language model answers your prompt. It is not a settings toggle buried three menus deep. It sits in the chat surface itself, usually as a small dropdown near the input box, and it changes what happens on the next request. GitHub's documentation describes it as the interface for choosing between Auto and a list of named models, with availability depending on your plan and on what your organization allows.

Where you find it depends on which client you use.

In VS Code, the picker appears in the Chat view and in inline chat. The docs describe a dropdown at the bottom of the chat input where you can switch between Auto and specific models. The same control shows up in the Copilot Edits and agent mode panels, though the exact label and position have moved around across releases. If you cannot find it, the first thing to check is whether you are on a current extension build, because older versions shipped without a picker at all.

In Visual Studio, the picker lives in the Copilot Chat window. The docs list a model selector in the chat toolbar. Visual Studio has historically lagged VS Code on model availability, so a model that appears in VS Code may not appear here yet.

In JetBrains IDEs, the picker is in the Copilot Chat tool window. The plugin exposes a model dropdown, and again the list can differ from what VS Code shows because the plugin ships on its own cadence.

On github.com, the picker appears in Copilot Chat on the web and in the coding agent interface. The web chat has its own model selector, and the available set is governed by the same plan and policy rules as the IDE clients.

In the CLI, model selection is handled differently. The docs describe configuration through the CLI rather than a graphical dropdown, which is why people who are used to the IDE picker sometimes report that the picker is "missing" when they are actually in a terminal session where no dropdown exists by design.

The practical consequence: "the model picker is broken" almost always means one specific client is showing a different list than another. Before you assume a bug, confirm which surface you are in and what that surface is supposed to support.

Symptom-to-fix table

Most picker complaints fall into a handful of buckets. Here is the mapping from what you see to what is usually causing it.

Dropdown empty, greyed out, or missing entirely

An empty or greyed-out dropdown is the most common report. The usual causes, in rough order of likelihood:

• Extension version too old. The picker was added over time. If your extension predates the feature, there is no dropdown to populate. Update the extension and reload the window.
• You are not signed in, or your session expired. A signed-out client cannot fetch the model list. Re-authenticate.
• You are in a surface that does not support picking. Inline suggestions and some completion contexts do not expose a model selector. Only chat-style surfaces do.
• Org policy disabled the picker. If an administrator has restricted model access, the dropdown can render as disabled rather than absent. This looks like a bug but is policy working as intended.
• Network or proxy blocking the model-list endpoint. Corporate proxies that whitelist some GitHub endpoints but not others produce exactly this symptom: chat works, picker is empty.

Model list shorter than expected

You can see a picker, it has entries, but the model you want is not there. Causes:

• Plan tier. Higher tiers expose more models. The docs tie model availability to subscription level, so a shorter list on a lower plan is expected behavior, not a fault.
• Org policy allowlist. Organizations can restrict which models members may use. An allowlist that excludes a model removes it from the dropdown even if your plan technically includes it.
• Client lag. JetBrains and Visual Studio plugins often trail VS Code. A model available in VS Code may simply not be wired up in your IDE yet.
• Regional or compliance restrictions. Some models are gated by region or by enterprise data-residency settings.

"Auto" pinned and you cannot change it

If Auto is selected and the dropdown will not let you pick anything else, the cause is almost always one of these:

• Org policy forces Auto. Administrators can mandate automatic routing. When they do, the picker is locked. No client-side fix exists.
• No premium quota remaining. If your plan meters premium requests and you have exhausted them, the client can fall back to Auto and disable premium model selection until the quota resets or you upgrade.
• Extension version mismatch. A picker that renders but does not respond to clicks is a classic stale-build symptom. Update and reload.

Model resets to Auto mid-session

You pick a model, work for a while, and notice later that you are back on Auto. This is usually not a bug. New chat sessions can start on the default rather than carrying your last selection. If your org forces Auto, every new session returns to it. Check whether the reset correlates with opening a new chat versus staying in the same thread.

Picker works in one client, not another

This is the single most common false alarm. Model availability is per-client. Comparing VS Code to JetBrains to github.com and expecting identical lists will produce a support ticket that resolves as "working as designed." Confirm the expected list for your specific client before filing anything.

Auto vs pinned model

Auto is the default for a reason. The docs describe it as routing your request to a model chosen automatically, with the selection based on factors like the kind of task and current availability. You are not told which model handled a given request unless the client surfaces it, and the point is that you do not have to think about it.

What Auto optimizes for is roughly: getting a reasonable answer without you managing a dropdown. It is tuned for general chat, quick questions, and the long tail of small edits where the difference between a fast model and a slow one matters more than the difference in output quality. It also hedges against capacity problems, since routing can avoid a model that is under load.

What Auto does not optimize for is your specific task. It has no idea that you are halfway through a multi-file refactor where consistency matters more than speed, or that you need deterministic output for a test-generation pass.

When pinning beats Auto

Pinning means selecting a named model and keeping it. Cases where that is the better call:

• Large refactors. When you are asking for changes across many files in one thread, a single consistent model produces more coherent results than a routing layer that may swap models between turns. Different models have different conventions for how they structure edits, and mixing them mid-task shows up as inconsistent style.
• Deterministic test output. If you are generating tests and want them to follow one house style, pin the model. Auto may hand different turns to different models, and the generated tests drift in structure.
• Reasoning-heavy work. For problems that need careful step-by-step reasoning, pinning a model built for that is more predictable than hoping Auto routes there. The pricing snapshot lists several reasoning-oriented options, including openai/o3-pro at $20 per million input tokens and $80 per million output tokens, and openai/o1 at $15 per million input and $60 per million output. Those are the kinds of models you pin deliberately rather than leave to chance.
• Reproducibility. If you need to explain later why a suggestion looked the way it did, knowing which model produced it helps. Auto removes that information.

When Auto is fine: quick questions, boilerplate, small edits, exploratory chat, and anything where you would not notice which model answered. Most day-to-day use falls here, which is why Auto is the default.

Premium request math

This is where the picker stops being a UI question and becomes a budgeting question. GitHub's model is that some requests cost more than others, and the multiplier depends on which model you pick. The docs describe premium requests as a metered resource, with different models consuming different amounts per request.

The mechanics, as the documentation lays them out:

• Each plan includes a monthly allowance of premium requests. The size of that allowance depends on your tier.
• Different models have different multipliers. A request to a lightweight model may cost a fraction of a premium request, while a request to a heavyweight reasoning model costs multiple.
• When the allowance runs out, premium model selection stops working until the next cycle or an upgrade. This is the mechanism behind the "Auto is pinned and I cannot change it" symptom above.

What runs out first depends on your habits. If you pin a high-multiplier model for everything, you will exhaust the allowance quickly. If you leave Auto on for routine work and pin only for the tasks that need it, the same allowance stretches much further. The picker is the control that determines which of those two patterns you are in.

To reason about relative cost, it helps to look at what these models cost when billed directly. The pricing snapshot shows the spread clearly. At the low end, openai/o1 sits at $15 per million input tokens and $60 per million output. Mid-range options like openai/gpt-5-pro are listed at $15 per million input and $120 per million output, and openai/o3-pro at $20 per million input and $80 per million output. At the top, openai/o1-pro is listed at $150 per million input and $600 per million output, with a batch variant at $75 per million input and $300 per million output. Anthropic's entries in the same snapshot include claude-opus-4.1 and claude-opus-4 at $15 per million input and $75 per million output, and claude-opus-4.7-fast and claude-opus-4.6-fast at $30 per million input and $150 per million output.

Those are direct API prices, not Copilot multipliers, and the two are not the same thing. But the ratio between them is a reasonable proxy for why one model eats your allowance faster than another. A model that costs ten times more per token is not going to be cheap in premium-request terms either.

The practical rule: leave Auto on for the bulk of your work, pin deliberately for the tasks where the model choice actually changes the outcome, and check your remaining allowance before starting a long session on an expensive model. If you are trying to figure out which plan gives you enough headroom, the plan comparison breakdown is the place to start.

Model switching without losing context

Switching models mid-conversation is where people expect the worst and usually get something better than they feared. The behavior depends on the surface.

In chat, changing the model does not wipe the thread. The conversation history stays, and the next turn is handled by the newly selected model. What you lose is continuity of style, not continuity of context. A model that has been following your conventions for ten turns is replaced by one that has to infer them from the same history, and the output can shift noticeably.

In agent mode, the picture is more delicate. Agent sessions involve a plan, a set of file edits, and sometimes a running task list. The docs describe agent mode as operating over a longer horizon than single-turn chat. Switching models in the middle of an agent run is possible in some clients, but the new model inherits the state the previous one built. If the first model made a questionable architectural decision three steps ago, the second model inherits it and may not question it. For long agent runs, pinning at the start is safer than switching mid-flight.

Command-style switching exists too. Some clients expose a slash command for changing the model without touching the dropdown, which is faster when you are already typing. The exact command varies by client, and the docs for your specific IDE are the authoritative source. The CLI handles model selection through configuration rather than a slash command in the chat box.

What does not survive a switch: any per-model tuning you had implicitly relied on. If you had been getting terse answers and the new model is verbose, that is not a setting you can carry over. You re-establish it through your prompt.

A reasonable pattern for long work: pick the model before you start the task, not during it. Use Auto for the exploratory phase where you are figuring out what you want, then pin once you know, and stay pinned until the task is done. Switching mid-task is for when a model is clearly failing, not for casual comparison.

Checklist before filing a support ticket

Most picker tickets resolve as configuration, not bugs. Work through this before opening one, because the first three items answer the majority of cases.

• Client and version. Note which IDE or surface you are in and the exact extension version. "VS Code, extension 1.x.y" is actionable. "Copilot is broken" is not.
• Plan tier. Confirm which subscription you are on. Model availability is tied to tier, and a shorter list on a lower plan is expected.
• Org policy. If you are in an organization, check whether an administrator has restricted model access or forced Auto. This is the single most common cause of a locked picker, and it is not something support can override.
• Premium quota. Check whether you have premium requests remaining. An exhausted allowance produces a disabled picker that looks identical to a policy lock.
• Extension logs. Most clients write logs to a known location. In VS Code, the Output panel has a channel for the Copilot extension, and there is a log directory under your user profile. The logs will show whether the model-list request failed, which distinguishes a network problem from a policy problem.
• Reproduction steps. Note whether the issue appears in a fresh chat, an existing thread, or only in agent mode. The scope narrows the cause considerably.
• Comparison point. If the picker works in one client and not another, say so explicitly. It tells support whether the problem is account-level or client-level.

If you are on the free tier and hitting a wall, the free tier breakdown covers what that tier does and does not include. If you are still deciding whether Copilot is the right tool at all, the general guide is a better starting point than a troubleshooting thread.

How this review was researched

This article is based on GitHub's published documentation for Copilot, including the model-selection and troubleshooting pages, the official pricing page for Copilot plans, release notes from the VS Code and Visual Studio teams covering model-picker changes, and public issue threads in the GitHub Copilot repositories where users report picker behavior. Model pricing figures come from the live pricing snapshot available at the time of writing. No hands-on testing was performed for this article, and no claims here rest on direct use of the product.

Where the documentation is silent on a specific behavior, this article says so rather than filling the gap with a guess. Model availability changes frequently, and the authoritative source for what your client supports today is the documentation for that client, not a third-party article.