Copilot gets three cost-vs-quality tiers in auto model selection

If you use GitHub Copilot's auto mode to let the service itself pick which model answers each prompt, you now have one more lever. The September 14, 2026 changelog introduced three tiers that tell the automatic selector how to weigh cost, quality, and response time on each request.

Until now, auto was a black box: it looked at the prompt and picked a model, period. Now you declare the intent, and the selector optimizes within it. It's a small configuration change, but it shifts day-to-day behavior, especially for anyone who pays by usage and watches their Copilot bill climb without understanding why.

What the three tiers are

There are three options, all using the same set of available models. What changes is the selection criteria:

• Efficiency: prioritizes keeping cost low. Good for quick, straightforward tasks.
• Balance: weighs cost, quality, and latency together. It's the sensible default for day-to-day work.
• Intelligence: prioritizes quality, designed for complex tasks.

The important detail, which the changelog makes a point of clarifying: the tier is a preference, not a lock. auto still evaluates each prompt individually. GitHub's own example is a good one: adding a docstring to an existing function can end up using a small, efficient model even with the tier set to intelligence, because the task doesn't require more than that. In other words, intelligence doesn't mean "throw the most expensive model at everything": it means "when the decision is ambiguous, lean toward quality."

How to configure it

The feature is rolling out gradually in Visual Studio Code, Copilot CLI, and the GitHub Copilot app. It wasn't listed for JetBrains or Visual Studio in the announcement, so if you live in a JetBrains IDE, you'll have to wait.

In VS Code, the path is the chat's model selector: where you currently choose between auto and the named models (GPT, Claude, etc.), there's now an option to set the auto tier. It's a UI setting, not a file one, so don't expect a new settings.json to version in your repo just yet. In Copilot CLI, the choice appears in the tool's configuration.

Since the rollout is gradual, if you don't see the option yet: confirm you're on the latest version of the Copilot Chat extension and of VS Code, then restart. In enterprise-managed environments, it's worth checking whether the org's policy allows auto mode at all, because no tier shows up if auto is disabled by policy.

What this changes on the bill

Here's the point that matters to whoever builds and pays the bill. Billing is based on the model auto actually selected, regardless of the tier. The tier has no price of its own, nor is it a spending cap. It influences the choice, and the cost comes from the choice.

In practice, this means:

• Setting everything to efficiency tends to pull more prompts toward smaller, cheaper models, so the bill goes down, with the risk of weaker answers on tasks that would call for a bigger model.
• intelligence pulls toward the expensive side when the task justifies it, so you pay more in exchange for quality.
• Paid subscribers still get the 10% discount on usage billed through auto. That discount belongs to auto mode itself, not to a specific tier, so it applies across all three.

What GitHub doesn't deliver yet is per-prompt visibility into which model was chosen and how much it cost. The changelog admits this is "the first step" toward giving more visibility into the trade-offs. So, for now, you configure the intent somewhat in the dark: you can track aggregate consumption in Copilot's usage metrics (which recently even gained VS Code agents), but not a "this prompt cost X because it used model Y."

How I'd think about choosing the tier

You can't just say "use X" without context, because the right cost depends on what you spend most of your time doing. The approach I'd take is to treat the tier as a setting that follows the type of work, not one you set once and forget:

• Boilerplate, docstrings, renames, trivial tests, commit messages: efficiency. These are tasks where a small model gets it right and a big model is a waste of tokens.
• Bulk of the day-to-day work (implementing a middling function, understanding a snippet, refactoring something contained): balance. It's the default I'd leave on most of the time.
• Debugging concurrency, designing a schema migration, understanding a distributed bug, reviewing architecture: intelligence. Here the quality difference in the model pays for itself, because a bad answer costs you more in time than the price difference of the model.

The problem is that switching tiers for every task is friction, and nobody keeps up friction. So the pragmatic move is: pick the tier that describes the majority of your prompts (for almost everyone that's balance) and bump up to intelligence selectively for the hard moments, then switch back. If you live in a codebase of repetitive tasks and the bill matters, efficiency as a baseline already changes the number at the end of the month.

When this doesn't help

The honest counterpoint is worth stating. If you already pick the model by hand, prompt by prompt, the tier gives you nothing, because it only acts when the mode is auto. Anyone with a strong preference for a specific model (whether for perceived quality or to standardize behavior across the team) keeps pinning the model and ignoring this new feature.

Another case: if your bottleneck is cost predictability, the tier doesn't solve it, because it isn't a spending limit. You don't configure "don't spend more than X per prompt," you configure a preference that the selector can override when it judges the task calls for it. For a real cost cap, the control is still turning off expensive models via org policy, not the tier.

And there's a team-level side effect: if each developer uses a different tier, the quality of Copilot's answers starts varying between people, which can turn into noise during code review ("why did his Copilot suggest this and mine didn't?"). It's not a bug, it's a consequence of having a per-person lever. It's worth having a minimal team agreement on which tier is the standard.

What remains open

The feature is clearly a beginning. What's missing is the part that would close the loop: knowing, after the fact, which model auto chose for each prompt and how much that cost, so you can adjust the tier using data instead of intuition. GitHub itself signals that's where this is heading, with "more visibility into the trade-offs."

For now, the concrete value is this: you've gone from an absolute black box to having an intent knob. It's not fine-grained control, but it's more than you had, and for anyone who uses auto all day, choosing between efficiency and intelligence according to the type of work is the kind of adjustment that shows up on the bill at the end of the month without costing anything to configure. The auto model selection documentation has the up-to-date list of models the three tiers share, and it changes frequently, so it's worth checking before assuming model X is still available.