Copilot Adds Cost and Quality Tiers to Auto

Daily Code Guide GitHub News

GitHub is expanding Copilot’s automatic model selection with three routing preferences: Efficiency, Balance, and Intelligence. The choices let developers indicate whether cost, an overall tradeoff between cost and quality, or response quality should receive the most weight when Copilot evaluates a prompt.

The change matters because Auto remains task-driven rather than model-specific. Selecting a tier does not assign a fixed model, create a separate model pool, or guarantee a particular price, response time, or quality level. Copilot continues to evaluate prompts individually and selects from the models available to that user.

What changed in Copilot Auto

According to the September 14 GitHub changelog, Auto now supports three preference levels:

  • Efficiency: prioritizes cost and is intended for fast, straightforward tasks.
  • Balance: weighs cost, quality, and latency for everyday development work.
  • Intelligence: prioritizes response quality for more complex tasks.

These preferences influence how Auto chooses among available models. They do not add models to a subscription or bypass restrictions imposed by a plan, organization, enterprise, or model policy. The Copilot model-selection documentation also notes that even the Intelligence preference can route a simple prompt to a smaller model when that is considered appropriate.

That behavior is important for teams interpreting the feature. Intelligence should not be treated as a command to use the most capable or most expensive model for every request. Similarly, Efficiency does not guarantee that every prompt will use the least expensive model available. The tier is a routing preference, not a fixed model selection.

Ad

Where the tiers are available

GitHub’s documentation distinguishes between the broader Auto capability and the three new tier preferences. Auto with task optimization is generally available in Copilot Chat on GitHub.com, Visual Studio Code, Copilot CLI, the GitHub Copilot app, and Copilot cloud agent.

The Efficiency, Balance, and Intelligence tiers are documented as available in Visual Studio Code, Copilot CLI, and the GitHub Copilot app. The original changelog describes the tier feature as rolling out in those products, while the expanded documentation describes the relevant Auto capability as generally available. Developers should therefore treat availability as product-specific rather than assume that every client exposes the same controls.

Availability can also depend on the user’s Copilot plan, subscription type, administrator settings, model policies, data-residency or FedRAMP requirements, evaluation-model policies, and the models currently available to that user. GitHub documents Auto as available with all Copilot plans, but that does not mean every plan or organization can access the same model set.

What this means for usage and billing

Copilot usage is charged according to the model Auto selects, not according to the name of the tier. Two prompts submitted with the same preference can be routed to different models and therefore produce different usage charges.

GitHub’s billing documentation says usage depends on the selected model and the number of input, output, and cached tokens consumed. Usage is converted into AI credits at a rate of one AI credit equal to $0.01 USD. Paid-plan users receive a 10% discount when using Auto in Copilot Chat, Copilot CLI, the GitHub Copilot app, or Copilot cloud agent, as documented in the Copilot usage optimization guidance.

The available documentation does not establish that billing records expose a dedicated tier-level line item. Usage and billing systems can expose information such as the selected model, quantity, price, discount, gross amount, and net amount, but the exact representation of the Auto discount—and whether the selected tier appears separately—is not documented.

When cost or capability matters, users should inspect the model Copilot selected. GitHub documents selected-model visibility in Copilot Chat by hovering over a response, in Copilot CLI through the terminal, and in the GitHub Copilot app through the model picker next to Auto. That information is more useful for analyzing a specific request than relying on the tier label alone.

Implications for developers

The three preferences provide a practical way to express intent without requiring developers to choose a model for every prompt. Efficiency may fit short explanations, straightforward edits, or other routine work where minimizing usage cost is the main concern. Balance is a reasonable choice when everyday work requires a compromise among cost, latency, and answer quality. Intelligence is better suited to complex tasks where response quality is the primary consideration.

None of those choices removes the need to review the result. Model routing remains dynamic, and generated code still requires human review and normal security validation before it reaches production.

Developers should also avoid assuming that a preference is portable across every Copilot surface. The supplied documentation does not explain whether a selected tier synchronizes between Visual Studio Code, Copilot CLI, and the GitHub Copilot app. It also does not provide definitive click-by-click instructions for selecting the tiers in each supported product. Standard client documentation explains how users select Auto from a current-model picker, but it does not establish where the three preference levels appear or how they are changed.

Administrative considerations

Administrators can influence the environment in which Auto operates. Enterprise-managed settings can make Auto the default model for new conversations, while users can still select another model for an individual conversation. Enterprise and organization administrators can also control access to individual Copilot models, which changes the pool from which Auto can select.

However, the supplied administrator documentation does not show that an organization or enterprise can enforce Efficiency, Balance, or Intelligence. The documented controls cover Auto defaults and model availability, not a policy that requires one specific Auto tier. Teams should not describe the tier preference as an enforceable enterprise-wide setting unless GitHub documents that capability separately.

For administrators monitoring costs, model-level and token-level usage remain the relevant signals. A tier can change routing behavior, but it is not itself a fixed pricing category. Current client and extension versions are recommended when accurate usage and pricing information is important, although the supplied material does not identify a separate version requirement for the tier feature.

What you should do

  1. Match the preference to the workflow. Start with Efficiency for cost-sensitive, straightforward work; use Balance for routine development; and consider Intelligence for complex tasks where quality matters most.
  2. Check the selected model. If a request has meaningful cost or capability implications, verify which model Auto used instead of inferring it from the tier name.
  3. Review organizational policies. Confirm which models your plan, organization, or enterprise makes available before assuming Auto can select a particular model.
  4. Use supported clients and current versions. The three tiers are documented for Visual Studio Code, Copilot CLI, and the GitHub Copilot app. Keep client and extension versions current where usage accuracy matters.
  5. Do not assume cross-client synchronization. GitHub’s supplied documentation does not establish that a tier preference follows a user between clients.

Availability remains qualified

The feature is a routing control layered onto Auto, not a new guarantee about model access or pricing. GitHub’s rollout language and expanded documentation differ in emphasis, so readers should rely on the product-specific availability described above and verify what their installed client exposes.

The model pool can change, and policies can limit it. As a result, the same tier may behave differently across accounts or over time. That variability is part of the feature’s design and is why selected-model visibility and usage monitoring remain important.

Sources

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top
Ad
Ad
Ad