Copilot Auto vs Cursor Router: When Teams Should Pin a Model

GitHub’s September 14 changelog added efficiency, balance, and intelligence tiers to Copilot’s auto model selection, which sharpens a question teams evaluating Copilot against Cursor already face: when is automatic routing acceptable, and when should you pin a named model? The documented answer is to run auto for interactive work where the selected model is visible per response, and pin a named model anywhere reproducibility matters, because Cursor Router, which disallows hand-picking entirely, cannot serve as that baseline.

What changed on September 14: three tiers, one pool

The Copilot changelog entry describes three tiers that change how auto weighs cost, quality, and response time for each prompt. The detail that matters for operations is what does not change: “All three tiers use the same set of available models. Auto individually evaluates each prompt to select a best-suited model.” A tier switch is a weighting knob, not a roster change. A team that flips from efficiency to intelligence is not opting into a different catalog; it is rebalancing selection pressure within the same candidate pool.

Two more facts bound what the tiers mean in practice. First, billing follows the router’s choice, not the tier label: “Usage is charged based on the model auto selects, regardless of tier.” Paid subscribers get a 10% discount on usage billed through auto, but that discount applies to whatever model auto selected. It is a list-price fact, not evidence that the accepted patch cost less. Second, the rollout is uneven. Per GitHub’s auto model selection documentation, task-optimized auto is generally available in Copilot Chat on the web, in VS Code, in Copilot CLI, and in the GitHub Copilot app, but the new tiers are “only available on VS Code, Copilot CLI, and GitHub Copilot app.” If part of your team works in another IDE, the tiered control plane may simply not exist for them yet.

Two different answers to who picks the model

Copilot’s design keeps the user in the loop at two points. Routing itself combines two systems, one tracking real-time system health and availability and one evaluating task complexity, and routes along natural cache boundaries. GitHub’s stated reason is candid: “Switching models mid-session has shown increased cost without ample improvements in quality.” That observation justifies routing at cache boundaries rather than per token, but it is also a vendor-reported rationale that cuts both ways. If mid-session model switching raised cost without quality gains inside GitHub’s own measurements, the burden of proof sits on any claim that dynamic routing improves outcomes elsewhere.

Cursor sits at the opposite pole. Cursor Router’s documentation is blunt: “Cursor Router is data-driven and managed by Cursor. You can’t hand-pick which model handles a request, and the model pool changes over time as new models ship.” It routes simple requests to fast, efficient models and complex work to the most capable ones, which is the same conceptual split as Copilot’s task-complexity evaluation. Steering happens through an optimization mode, and the parallel to Copilot’s tiers is close: Cost keeps the previous Auto routing logic, while Balance and Intelligence run the router’s classifier on each request. The difference is control. Copilot lets a user bias the router with a tier and lets administrators carve models out of the pool. Cursor manages the decision end to end, and the router carries a hard dependency: enabling Cursor Grok 4.6 is a requirement for it to work, because the router needs a cost-efficient model when it is not calling frontier models.

Plan scope needs care here. Cursor’s documentation places configuration at the team level: “Admins configure Cursor Router from the team dashboard,” where routing can be turned on or off, and on Enterprise plans the router can also be configured per organization group. Enterprise teams must enable the router manually because it is off by default, and on Enterprise plans the router respects team model access controls, routing to an allowed model when one is blocked. The documentation never names a Teams plan tier explicitly, so confirm plan availability directly before assuming Router is included. For the tool-level comparison, see our Copilot, Cursor, and Claude Code comparison; this piece stays inside the routing-policy layer.

The control-boundary matrix

The useful comparison is not seat price against seat price. It is the boundary of who can decide what, on seven axes:

Three rows deserve emphasis. On exclusions, the systems fail differently: Copilot’s policy exclusions shrink the candidate pool, while Cursor’s Enterprise controls silently substitute. Both honor administrator intent, but substitution means a Cursor request can complete with a model nobody explicitly chose, which matters when you are trying to attribute a regression. On identity, the capabilities are closer than the defaults: Copilot shows the selected model to any user who hovers a response, while Cursor’s Underlying model display must be enabled by an admin, hidden is both the default and the documented recommendation, and it covers only Balance and Intelligence modes. Copilot’s hover turns routing into a loggable variable without anyone’s permission; Cursor’s can do the same, but only as a policy decision. The admin-controls row tilts toward Cursor: disabling modes and imposing Auto give administrators levers into mode selection and even the default model that Copilot’s documentation does not describe on the tier side.

Where automatic routing is operationally acceptable

The case for running auto as the default rests on three documented conditions. First, the selected model is visible per response, so surprises are detectable after the fact. Second, administrator policies can exclude evaluation models from the pool, which removes the roster’s most unstable element. Third, the tier system gives users a sanctioned way to trade cost against quality without abandoning the router.

The risk that remains is the evaluation-model category itself. GitHub’s supported-models reference warns that testing “revealed evaluation models may perform worse than other models on security-related, or other categories of prompts,” that they “may appear in the product with codenames rather than official model or provider names,” and that they may be added, updated, or removed without notice, with availability and rate limits that differ from generally available models. A codename you logged in week one of a pilot may not exist in week four. If evaluation models are excluded by policy, that instability is fenced off; if they are not, your auto baseline has a moving part you cannot name.

For everyday interactive work, drafting, refactors, exploration, this profile is acceptable. The cost of a suboptimal routing decision is a retry, and the per-response model identity gives you the data to notice patterns. Teams comparing how different tools expose model choice more broadly will recognize the pattern from our IDE context and agent economics comparison: the model menu matters precisely because model quality does not follow any vendor’s release calendar.

When pinning a named model is worth the friction

Pinning stops being pedantic in three situations, all sharing one property: you need to compare two outputs and attribute the difference.

• Regression triage. If last week’s generated migration passed review and this week’s did not, you need to know whether the model changed. Under Copilot auto you can check the hover identity and pin that model for a rerun. Under Cursor Router you can at most learn which model handled the request, and only if an admin enabled the display; you cannot hand-pick that model to reproduce last week’s conditions.
• Security-sensitive review. GitHub’s own warning that evaluation models may perform worse on security-related prompts, paired with its directive for thorough human review before production use, means security work should run against a named, generally available model, not whatever the pool contains that day.
• Acceptance gates. Any pre-merge check, benchmark harness, or pilot comparison that produces a number must hold the model constant, or the number measures the router’s mood instead of the tool.

This is where Cursor Router’s design becomes a hard constraint rather than a preference. Because it does not allow hand-picking and the pool shifts as models ship, Router cannot serve as a named-model baseline. A team standardizing on Cursor that needs reproducible conditions must define that baseline outside Router, through explicit model selection elsewhere in the product, and treat Router results as a separate, non-reproducible lane. On Copilot, the equivalent baseline is an explicit model choice with evaluation models excluded by policy.

A pilot worksheet that survives router drift

Because the four vendor pages behind this article include no independent head-to-head benchmark, the responsible move is a small internal pilot. The worksheet below is designed so that its results remain interpretable even if both vendors change their pools mid-pilot:

1. Fix the task set. Pick five to eight identical repository tasks from your own codebase: a bugfix with a failing test, a multi-file refactor, a feature with an acceptance test, a security-sensitive change (input validation, auth, deserialization), and a documentation or migration task. Same prompts, same repos, same acceptance checks for every lane.
2. Define lanes, not winners. Run at least three lanes: Copilot auto on a fixed tier, a pinned named model on Copilot with evaluation models excluded, and Cursor with Router enabled. Record the client and surface for each run, since Copilot tiers do not exist on every surface.
3. Log per run: selected model identity (hover in Copilot Chat; under Cursor Router, only if an admin has enabled the Underlying model display), retries to a passing acceptance check, observed cost per task from the billing console, and human review minutes before merge. Log the date, because evaluation models and Router’s pool can change without notice.
4. Score against acceptance checks only. Tests passing, review comments resolved, security checklist cleared. Vendor quality claims, including any savings framing attached to routing, stay out of the scoreboard.
5. Re-run one task weekly. A single repeated task is a drift detector: if its selected model identity or retry count shifts without any change on your side, the pool moved, and earlier numbers need an asterisk.

Cost per completed, accepted task is the only cost metric that survives both billing systems. Copilot bills the model auto selects regardless of tier, so a pilot run on the efficiency tier can still land on an expensive model; the 10% subscriber discount applies to that usage but says nothing about retries. Cursor documents the same structure from the other side: all Auto modes bill at the list price of the model each request is routed to, and third-party models also incur the Cursor Token Rate, so a Router lane’s costs follow the router’s choices, not your mode.

What this evidence cannot settle

Everything above rests on four vendor pages, and the gaps are specific. None of them measures routing quality or cost head-to-head, so neither vendor’s framing can be reported as a result, and this article deliberately names no winner. Cursor’s documentation covers Router’s modes, admin controls, and pricing, but it never states in so many words whether a Teams plan includes Router, so verify plan availability before committing a pilot lane to it. Copilot’s 10% discount is a list-price fact about selected-model usage, not a demonstrated saving on accepted patches, and GitHub’s cache-boundary rationale is a vendor-reported observation, not an independent measurement.

The operational verdict stands without those gaps being filled. Default to automatic routing for interactive work where the selected model is visible per response and evaluation models are excluded by policy. Pin a named, generally available model for regression triage, security-sensitive review, and any acceptance gate where you will need to explain a number later. And if your workflow runs on Cursor Router, build your reproducible baseline outside it, because a router you cannot hand-pick and whose pool changes as models ship can name the model behind a regression, when display is enabled, but cannot rerun that model under matched conditions.

Frequently Asked Questions

Which surfaces support the new Copilot auto model selection tiers?

Per GitHub’s auto model selection documentation, task-optimized auto is generally available in Copilot Chat on the web, in VS Code, in Copilot CLI, and in the GitHub Copilot app, but the new tiers are “only available on VS Code, Copilot CLI, and GitHub Copilot app.”

Can users hand-pick a specific model when using Cursor Router?

Cursor Router’s documentation is blunt: “Cursor Router is data-driven and managed by Cursor. You can’t hand-pick which model handles a request, and the model pool changes over time as new models ship.”