GitHub has added three optimization tiers to Copilot's automatic model selection: Efficiency, Balance and Intelligence. The setting changes how the router weighs cost, response time and expected quality for each prompt, while keeping the same pool of models available to the user.
The change sounds like a simple preference control, but it exposes an important part of modern coding-agent infrastructure: model selection is becoming a runtime policy rather than a one-time choice by the developer.
There is also an important limit. Selecting Efficiency does not set a spending cap, and selecting Intelligence does not force every request onto the most expensive model. GitHub says billing still follows whichever model Auto actually selects.
The router now has an explicit objective
Copilot Auto already chose models dynamically. GitHub's documentation says task-optimized routing considers task complexity together with model health and availability, and tries to reserve higher-cost reasoning models for work that needs them.
The new tiers add a user-controlled objective to that process.
Efficiency prioritizes lower cost and suits fast, straightforward work. Balance weighs cost, quality and latency together. Intelligence prioritizes quality for more complex tasks. All three tiers use the same set of models, and Auto still evaluates prompts individually.
That last detail matters. Even under Intelligence, GitHub says a simple request such as adding a docstring can be routed to a smaller model. The tier therefore changes the router's preference function; it is not a fixed mapping between a tier and a specific model.
A routing preference is not a budget guardrail
The naming could easily encourage the wrong operational assumption.
A team might read “Efficiency” as a cost-control mode. But GitHub states that usage is charged according to the model selected by Auto, regardless of the tier. Paid subscribers continue to receive a 10 percent discount for Auto, but the bill still depends on routing decisions and token usage.
Aipolix's analysis is that Efficiency should therefore be treated as an optimization preference, not as a deterministic financial control.
If an organization needs a hard spending ceiling, it still requires separate budget controls, usage monitoring or model-policy restrictions. A probabilistic router that tries to prefer cheaper models is useful, but it cannot substitute for a limit enforced outside the routing algorithm.
The same distinction applies to Intelligence. It expresses a preference for quality, not a guarantee that each request will use a frontier model or achieve a particular benchmark score.
Policy still constrains the model pool
GitHub's documentation says Auto only chooses among models available under the user's plan and organizational policies. Models excluded by administrator settings, data-residency requirements or FedRAMP restrictions are not eligible.
This is a strong architectural property because it separates two decisions.
The organization defines which models are allowed. The router then optimizes among that permitted set. A user can ask for an Intelligence preference without silently bypassing an enterprise prohibition on a particular provider or model.
That separation becomes more important as routing systems become more autonomous. Cost and quality optimization should happen inside an authorization envelope, not determine the authorization envelope itself.
Why this matters for coding agents
Coding agents increasingly perform long, multi-step sessions rather than single chat turns. One session can contain repository exploration, code generation, testing, debugging and review. Those steps do not all need the same model.
A routing layer can save money by assigning easy work to smaller models and reserving expensive reasoning for difficult steps. GitHub also says its task-optimized router changes models along natural cache boundaries because switching mid-session can otherwise increase cache-related cost without enough quality benefit.
The new tier control makes that orchestration visible to users instead of leaving the objective entirely implicit.
It also creates a new observability requirement. If teams are going to compare Efficiency, Balance and Intelligence, they need to measure not only aggregate cost but also which models were selected, latency, task completion, retries and downstream review effort. GitHub already exposes the model used for each response in supported Copilot surfaces, which provides part of that evidence.
Rollout and remaining unknowns
The three tiers are rolling out in Visual Studio Code, Copilot CLI and the GitHub Copilot app. GitHub describes this as the first step toward more customizable model selection.
The company has not published a benchmark showing how much each tier changes cost, latency or coding quality, and it does not publish a deterministic rule for which model a given prompt receives. That means teams should not infer a fixed savings percentage from the labels.
The engineering significance is elsewhere: a multi-model coding product now exposes routing intent as a first-class control while keeping billing and enterprise model policy separate.
That is a useful direction, but it also makes the distinction between optimization and enforcement clearer. “Prefer cheaper” is not the same control as “never spend more than this,” just as “prefer intelligence” is not the same as “always use the strongest model.”