Choosing Models in Your Assistant

VS Code exposes two separate model choices, not one. Chat — the panel-based conversation used for anything from a one-off question to a multi-file agentic change — is switched from the language model picker in the chat input field, which lists the models your plan and organization make available and groups faster models apart from deeper-reasoning ones. Completions (ghost-text and ghost-text-style inline suggestions) use a separate model, changed from the Chat menu in the VS Code title bar: select Configure Inline Suggestions…​, then Change Completions Model…​. The two pickers are independent, so a session can run a fast model for completions while chat uses a stronger one for a harder question:

See VS Code — Language models in Visual Studio Code and GitHub — About AI models in Copilot.

GitHub keeps two reference pages instead of a fixed table on every product page: the supported models page lists which models are currently available and to which surface (chat, completions, Copilot cloud agent, Copilot CLI, the GitHub Copilot app), including which ones offer an extended context window on some clients; the model comparison page groups them by what they are good at — general-purpose coding, fast/simple tasks, complex multi-file reasoning, and visual input — so a task can be matched to a category without memorizing individual model names. Both pages change whenever GitHub adds or retires a model, which is why this page links them instead of repeating their contents:

Selecting Auto in the model picker, instead of a specific model, routes each request to a model Copilot judges appropriate for that request’s complexity and for real-time model availability; hovering over a chat response shows which specific model actually answered it. Auto is a reasonable default when you would otherwise have to guess between a fast and a reasoning model on every request:

See GitHub — About AI models in Copilot.

As of the date above, VS Code Copilot Chat exposes a per-model Thinking Effort control for models that support adjustable reasoning: opening the model picker and selecting the arrow next to a model name opens a submenu with levels from None up through High, and the picker label then shows the chosen level next to the model name. GitHub’s own cloud-agent documentation describes the same idea in different words — a higher reasoning level can improve quality on a complex task at the cost of more time and more of the plan’s AI-request budget — confirming this is a real, current control and not something only VS Code exposes:

See VS Code — Language models in Visual Studio Code and GitHub — Changing the AI model used by Copilot cloud agent.

An organization owner controls which models beyond the plan’s basic set members may use from organization Settings → Copilot → Models, where each model-related policy has its own enforcement toggle; GitHub documents the equivalent enterprise-wide control separately. A model an org policy has not enabled simply will not appear in a member’s picker, which is worth knowing before assuming a missing model is a bug rather than a policy setting:

See GitHub — Managing policies for Copilot in your organization.

Claude Code’s model controls are session-level rather than split by feature. Running /model with no argument opens an interactive picker; running it with an alias or a full model name switches immediately, and the picker then asks whether to save the choice as the new default or apply it to this session only:

As of the date above, the documented aliases include a short-name family for the everyday tiers — sonnet (the latest Sonnet, for day-to-day coding), opus (the latest Opus, for complex reasoning such as hard architectural or debugging work) and haiku (the fast, efficient tier, for simple, well-scoped tasks) — plus fable, which selects the Fable model for your hardest and longest-running tasks, and best, which uses that Fable model where it is available to you and otherwise the same model as opus. default is not itself an alias: it clears any override and reverts to the account’s runtime default, which on most plans resolves to an Opus model rather than Sonnet. Anthropic documents further, more specialized aliases (a [1m] extended-context variant of a tier, and opusplan, which plans with opus and executes with sonnet) alongside this set; because the full alias list is exactly the kind of detail that changes with each Claude Code release, check Claude Code — Model configuration for the current one rather than treating any list here as exhaustive.

Effort is a separate control from the model itself: it adjusts how much the model reasons before answering, from a documented low end up through a documented high end, and which exact levels a given model supports varies by model. Set it with /effort inside a session, with the --effort flag at startup, or with the CLAUDE_CODE_EFFORT_LEVEL environment variable:

Fast mode is not a different model — it is a faster, costlier API configuration for the models that support it, toggled on and off with /fast. Turning it on when the current model does not support it switches the model to one that does; turning it off leaves you on that model rather than reverting automatically. As of the date above it is available only on Opus models, and on a subscription plan it is billed from usage credits rather than the plan’s included usage. It trades cost for latency, which is why Managing Context links it alongside Claude usage limits rather than repeating the cost figures here (never hard-coded on this page):

For a fixed model choice outside an interactive session — a script, a CI job, or a shell profile — pass --model on the command line or export ANTHROPIC_MODEL, which Claude Code reads at startup and which --model overrides for that one invocation:

See Claude Code — Model configuration, Claude Code — CLI reference and Claude Code — Speed up responses with fast mode.

Both tools converge on the same underlying trade-off — speed and cost on one end, depth of reasoning on the other, plus a separate axis for whether the model needs to understand an image — even though they expose it through different pickers:

Choosing a Model covers the underlying requirements-shortlist- evaluate-decide workflow this table is a shortcut for; use that page’s process whenever a task does not fit neatly into one of these three rows.

A model that wrote code, or reviewed it, is not the most reliable judge of its own output — the same blind spots that produced a mistake often keep it from noticing the mistake on review. Asking a second, independent model to review the first model’s diff or plan catches a class of errors that asking the same model to "double-check itself" tends to miss, at the cost of a second round of tokens. In practice this means running the second review in the other tool, or in the same tool under a different model:

Running that exact prompt against opus after sonnet produced the diff, or pasting it into Copilot Chat after Claude Code produced the diff, are both instances of the same pattern. This is a lightweight, ad hoc version of the deterministic-gate idea in Reviewing AI-Generated Code — a second model is a useful extra check, not a replacement for tests, linters and a human reviewer.

BYOK and fully local models — running an open-weight model yourself instead of calling a hosted one — are covered in depth by Running LLMs Locally, in particular Local Models in GitHub Copilot and Local Models in Claude Code; this page only notes that the same task-matching and cross-checking ideas above apply just as well when one side of the comparison is a locally run model such as llama3.1:8b under Ollama 0.34.