AI coding tools
GitHub Copilot Auto Adds Three Routing Preferences, but Cost Mode May Still Choose Large Models for Complex Prompts
Copilot Auto now lets users adjust the weighting of cost, quality, and latency across three tiers—Efficiency, Balance, and Intelligence—but all three share the same model pool. Actual charges still depend on the model selected by the router and the number of tokens used; tier names are neither price caps nor guarantees of a specific model.
Starting September 14, GitHub added three preferences—Efficiency, Balance, and Intelligence—to Copilot’s automatic model selection, initially rolling them out to VS Code, Copilot CLI, and the GitHub Copilot app. These preferences do not create three separate model lists. Instead, they change how the router weights cost, quality, and response time across the same pool of available models. Even with Intelligence selected, a simple prompt such as adding a docstring may still be routed to a smaller model.
Auto makes decisions based on factors including task complexity, real-time model health, and availability. It also respects constraints related to plans, data residency, FedRAMP, and models excluded by enterprise administrators. GitHub says routing occurs at natural cache boundaries, avoiding mid-session model changes that would invalidate the cache. Users can see which model actually handled a request in the response or terminal output. This allows teams to replace per-request model selection with higher-level intent settings, but it also delegates some performance reproducibility to a routing strategy that may change with model availability.
The billing rules are especially important to understand separately: all three tiers are billed according to the input, output, and cached tokens of the model actually selected. Paid plans receive a 10% discount when using Auto; Intelligence is not pinned to a single expensive model, nor does Efficiency impose a hard budget. Output pricing and long-context rates can differ by tens of times across models, so CI workflows, batch agents, and long-running refactoring tasks should still record the model, token usage, and cost for each turn.
GitHub has not disclosed the candidate-model weights, quality benchmarks, routing stability, or cost distributions for the three tiers, and it does not currently provide organization-level hard limits. Engineering teams should next monitor model selection, cache hit rates, and tail costs for the same test suite at different times. For workflows that require auditing or deterministic reproducibility, explicitly pinning a model remains easier to track than relying on Auto.