Analysis
Copilot Auto Is Now a Per-Prompt Budget Decision
GitHub Copilot’s automatic model selection now has efficiency, balance, and intelligence settings. The names sound like three model lists. In its September 14 announcement, GitHub says they use the same eligible pool and make a different routing decision for each prompt.

That turns “auto” into a small policy engine. It weighs expected quality and usage cost, chooses a model, and bills according to the model selected. Paid users receive a ten-percent discount when they use auto selection.
The setting changes the objective, not the inventory
An efficiency setting does not guarantee a cheap model, and intelligence does not pin the most expensive one. The router still estimates what each prompt needs. Two similar requests can therefore have different cost and behavior.
That is reasonable for an individual who wants less model management. It complicates organizational evaluation. A team can no longer attribute a result to one fixed model simply because Copilot was set to auto.
Measure work completed, not prompt price
The cheapest request is not cheaper if it produces a patch that takes longer to repair. The most capable model is wasteful when the task is boilerplate. I would compare tiers using accepted changes, review time, escaped defects, retries, and reported usage per completed task.
The benchmark set should include small transformations, repository navigation, debugging, multi-file changes, and tests written from an existing contract. Average cost without task mix is not useful.
A comparison another engineer can repeat
Before changing a team default, I would choose a small set of completed tasks whose requirements and expected behavior are already known. Include a mechanical edit, a bug involving more than one file, and a change that must preserve an authorization rule. Remove sensitive data and use tasks the organization permits the service to process.
Start each attempt from the same commit in a fresh workspace and conversation. Keep repository instructions, tools and permissions the same. Alternate the order of tiers so the last setting is not always evaluated after the reviewer has learned the answer. Run multiple attempts; one attractive patch is not a reliable comparison.
This is the record I would keep for each attempt:
Task and starting commit:
Client/version and date:
Auto tier; selected model if exposed:
Acceptance checks defined before the attempt:
Checks passed; review findings:
Human correction time; retries:
Reported usage and billing units:
Accepted / rejected / unfinished:
Do not count a generated patch as completed work until it passes the same acceptance checks and review used for the other tiers. Keep failed and abandoned attempts in the totals. If model identity or usage attribution is unavailable, record that limitation rather than assigning the result to an assumed model.
Compare each task type separately before combining results. A setting that handles mechanical edits cheaply may still be a poor default for a permissions change. The evaluation itself consumes usage, so set its budget and stopping condition beforehand. This is a proposed procedure, not a claim that I have benchmarked these tiers.
Reproducibility still needs a pinned path
For everyday assistance, changing the selected model is a feature. For an evaluation, regulated workflow, or regression investigation, it is a variable. Record the chosen model where GitHub exposes it, preserve prompts and repository state when policy permits, and pin a model for tests that must be comparable over time.
Administrators should also decide who controls the tier and which models are eligible. A user-visible preference is not the same as a spending policy. Budget alerts and usage limits remain necessary because a router optimizes the objective it was given, not the organization’s entire cost model.
I like automatic routing for low-stakes interactive work. I would not use it as evidence that one named model improved productivity unless the selected-model distribution and task mix were part of the result.
Source
GitHub: configure cost and quality in Copilot auto model selection.