How to Change GitHub Copilot Model in 2026

Switching the model behind GitHub Copilot is not one setting. It is a different setting in every client, and on paid business and enterprise plans it can be overridden by an org policy you cannot see from inside your editor. This guide walks the actual UI paths for VS Code, JetBrains IDEs, Visual Studio, github.com chat and the CLI, then covers the admin side: allowed-model lists, policy precedence, and how to confirm which model actually served a response.

Everything below is drawn from GitHub's client documentation, the VS Code and JetBrains extension changelogs, and the organization policy reference pages. No hands-on testing is claimed here; where a behavior is documented, it is attributed, and where it is not, that is said plainly.

Before you start

Two things gate whether the model picker even appears.

Plan tier. GitHub's docs describe model availability as plan-dependent. Copilot Free exposes a smaller set of models than Copilot Pro, and Copilot Business and Copilot Enterprise add organization-level controls on top. If you are on Free and the picker shows fewer entries than a colleague on Pro sees, that is expected, not a bug. The plan comparison covers which tiers expose which model families.

Extension version. The model picker is a client feature, not a server feature. Older extension builds simply do not render it. The VS Code and JetBrains changelogs show the picker arriving in specific release lines, and GitHub's docs recommend keeping the extension current before troubleshooting a missing picker. If your editor is pinned to an old build by a corporate update policy, that is your first suspect.

One more precondition worth stating: you must be signed in with the account that holds the Copilot entitlement. A personal sign-in on a machine where the org expects SSO will produce a picker that looks fine and then fails at request time.

Change model in VS Code

VS Code is the reference client. The docs describe the model picker as living in the Chat view, not in the general settings UI.

1. Open the Chat view (the Copilot chat panel, not the inline suggestion ghost text).
2. Find the model name at the bottom of the chat input box. It renders as a small dropdown label showing the currently selected model.
3. Click that label. A list of models available to your account opens.
4. Pick the model you want. The label updates immediately and the next request uses the new model.

There is a second path through the command palette: run GitHub Copilot: Change Model (the exact command label has shifted between releases, so if it does not autocomplete, search for "Copilot" and look for the model entry). This is the path to use when the chat panel is collapsed or when you are working in a window where the picker is hard to reach.

Where the choice persists. The docs describe the selection as remembered per user, not per workspace, in the default configuration. That means switching to a different model in one project changes it for every project in that VS Code profile. If you want a per-workspace model, you are looking at a setting that the default UI does not expose; the practical workaround is separate VS Code profiles, which carry their own settings and their own model selection. This is the closest thing to "copilot model per workspace" that the documented client supports.

Inline completions and chat are separate surfaces. Changing the chat model does not necessarily change the model behind inline ghost-text suggestions, and the docs treat those as distinct features. If your goal is faster or slower completions specifically, changing the chat model will not do it.

Change model in JetBrains IDEs and Visual Studio

Both of these clients lag VS Code in feature parity, and the model picker is a good example. The plugin changelogs show the picker landing in JetBrains and Visual Studio later than in VS Code, which is why "the option is not there" is almost always a plugin-version problem rather than a plan problem.

JetBrains (IntelliJ IDEA, PyCharm, WebStorm, GoLand, and the rest)

1. Update the GitHub Copilot plugin first. Open Settings (or Preferences on macOS), go to Plugins, find GitHub Copilot, and apply any pending update. Restart the IDE.
2. Open the Copilot chat tool window.
3. Locate the model selector in the chat panel header or input area. The exact placement has moved between plugin releases; the changelog for your installed version is the authoritative source for where it sits.
4. Click it and choose from the list.

If no selector appears after updating, the plugin build you have may predate the feature. Check the changelog entry for the model picker and compare against your installed version number, which the IDE shows in the plugin list.

Visual Studio

1. Update the GitHub Copilot extension via Extensions > Manage Extensions > Updates.
2. Open the Copilot chat window.
3. Use the model dropdown in the chat pane to switch.

The same version caveat applies. Visual Studio's extension update channel is separate from the IDE's own update channel, so an up-to-date IDE can still carry a stale Copilot extension.

Neither JetBrains nor Visual Studio is documented as syncing its model choice with VS Code. Treat each client's selection as local to that client.

Change model on github.com chat and in the CLI

The web chat on github.com and the Copilot CLI are separate clients with separate model selection, and this is where people get confused, because they assume a single account-wide setting.

github.com chat. The docs describe a model selector in the chat interface on the website. It behaves like the editor pickers: choose a model, and subsequent messages in that session use it. The web chat is useful precisely because it is not tied to an editor install, which makes it a quick way to check whether a model is available to your account at all. If a model appears on github.com but not in your IDE, the problem is your extension, not your entitlement.

Copilot CLI. The CLI exposes model selection through its own configuration. GitHub's CLI documentation covers the available flags and config keys; the model list there tracks what your account is entitled to, subject to the same org policy as every other client.

What does not sync. This is the part worth internalizing: the documented clients do not share a model selection. Setting a model in VS Code does not change JetBrains, does not change Visual Studio, does not change github.com chat, and does not change the CLI. If you work across two editors, you will set the model twice. There is no documented account-level "my preferred model" that all clients read.

Set a default for a whole team

This is the section developers never find, because it lives in organization settings rather than in any editor. On Copilot Business and Copilot Enterprise, admins can constrain which models members are allowed to use.

The mechanism, as the organization policy reference describes it, is an allow-list. The admin selects which models are permitted for the organization, and members then see only that subset in their pickers. A model that is not on the list does not appear, regardless of what the member's plan would otherwise expose.

Policy precedence. The rule to remember is that org policy narrows, it does not widen. A member cannot select a model the admin has not allowed, even if their personal entitlement would cover it. Conversely, an admin allowing a model does not grant it to a member whose plan does not include it. The effective set is the intersection of what the plan offers and what the org permits.

There is a second layer on Enterprise: enterprise-level policy can constrain what organizations within it are allowed to enable. If an org admin cannot turn on a model that the docs say exists, the enterprise policy above them is the next place to look. The policy reference pages lay out this hierarchy; the practical takeaway is that when a model is missing, you walk up the chain, not sideways through editor settings.

Setting a team default is a different thing from setting an allowed list. The documented admin controls govern availability. Whether a particular model becomes the default for new members is a client-side matter, and the docs do not describe a server-pushed default that overrides a member's local picker. In practice, teams that want uniformity enforce it through the allow-list down to a single model, which leaves members nothing to switch to.

For teams weighing whether the Copilot model controls are worth the admin overhead versus a different assistant, the alternatives roundup compares how other tools handle model selection and policy. Beetlix is our own product, and it also exposes model choice at the workspace level; the honest difference is that Copilot's controls are tied to GitHub org and enterprise structure, while Beetlix's are tied to its own workspace model. Neither is universally better, and if your identity and billing already live in GitHub, staying inside Copilot's policy system is the simpler path.

Verify the switch worked

Changing the picker label is not proof. The label reflects your selection; it does not prove the server honored it. Here is how to confirm.

In the editor. The most direct signal is the response metadata. Copilot chat responses carry a model attribution in the UI in current builds, and the docs describe the model name being surfaced alongside the response. If the label says one model and the response metadata says another, your selection did not take effect, and policy or auth is the likely cause.

In the logs. VS Code's Copilot extension writes to an output channel. Open the Output panel and select the GitHub Copilot channel. Request-level entries there show which model handled a call. This is the ground truth when the UI is ambiguous, and it is the first place to look when you suspect a policy override, because the log will show the model actually used rather than the one you picked.

On github.com. The web chat shows the model in use for the conversation. Because the web client is not affected by your local extension state, it is a clean control: if the web chat uses the model you expect and your IDE does not, the discrepancy is client-side.

A quick sanity check that costs nothing: ask the model to identify itself. This is not authoritative, since models can be wrong about their own identity, but a wildly wrong answer combined with a log entry showing a different model is a strong hint that something upstream is rewriting your choice.

Common failures

Policy override. The most common cause of "I switched but nothing changed." You selected a model, the request went out, and the org allow-list rejected it, so the service fell back to a permitted model. The picker may still show your selection, which is what makes this confusing. Check the output log for the model actually used, then check the org's allowed-model list. If you are not an admin, you cannot see the list, which is exactly why this failure is so hard to self-diagnose.

Stale auth token. Entitlement changes, plan upgrades, and org membership changes do not always propagate to an already-signed-in client. The symptom is a picker that is missing models you know you should have, or a selection that fails at request time. Signing out and back in forces a fresh token. In VS Code this is done through the Accounts menu; in JetBrains and Visual Studio it is in the plugin's sign-in UI. This fixes a surprising share of "the model disappeared" reports.

Premium request exhaustion. GitHub's docs describe premium requests as a metered allowance on paid plans, with different models consuming it at different rates. When the allowance runs out, higher-cost models stop being usable and the client falls back. The picker may still list them, which produces the same confusing pattern as a policy override. If a model worked yesterday and does not today, and nothing changed in your settings, check your premium request usage before you start reinstalling extensions.

Extension version drift. Covered above, but worth restating as a failure mode: a picker that never appears at all is almost always an old extension, not a plan problem. Update first, then troubleshoot.

Wrong account. Multiple GitHub accounts signed in at once is common on machines that handle both work and personal repos. The active account determines entitlement. If the picker shows the personal-plan model set when you expect the enterprise set, you are signed in as the wrong identity.

How this review was researched

This guide is based on GitHub's client-specific documentation for VS Code, JetBrains, Visual Studio, the web chat and the CLI; the organization and enterprise policy reference pages; the VS Code and JetBrains Copilot extension changelogs; and the live model pricing data used to describe cost tiers. No hands-on testing was performed, and no latency, benchmark or accuracy figures are asserted, because none were measured. Where the documentation is silent on a behavior, such as whether a server-pushed team default exists, this article says so rather than guessing.

For broader context on the product itself, see the usage guide and the full Copilot guide.