Cursor Router adds Cost mode for Teams and Enterprise coding requests

• Cursor Router is live for Teams and Enterprise, and Cursor's admin-controls tweet says admins can enable it per team, allow or block models, set defaults, and disable selected optimization modes.
• Auto mode now has Intelligence, Balance, and Cost settings, and Cursor's mode tweet says the router sends harder work to frontier models and routine work to cheaper models.
• Cursor claims frontier-quality results at 60% lower cost, while Cursor's early-access tweet says customers saw no quality drop versus routing everything to Opus 4.8.
• The launch has a research prequel: Cursor's SQLite swarm thread said model mix changed the cost of rebuilding SQLite by 15x.
• The community immediately moved to custom routing, with Omar Saravia's question asking whether this should exist as open source instead of an API dependency.

Cursor's launch post says the classifier was trained on 600k+ live requests, evaluated across millions of production requests, and optimized for user satisfaction. The Router docs bury the operational gotchas: routed model names are hidden by default, Balance and Intelligence spend usage faster than Cost, and Grok 4.5 has to stay enabled for the router to work. Cursor's swarm research post is the prequel, with planner-worker model mixes ranging from $1,339 to $10,565 on the same SQLite task.

Cursor Router is a model router inside Cursor's Auto mode for Teams and Enterprise plans. Christmas came early for coding-agent cost nerds: model choice, spend policy, and admin governance are now one product surface.

The user-facing pieces:

• Entry point: select Auto in the model picker, then choose an optimization mode.
• Modes: Intelligence, Balance, Cost.
• Plans: Teams and Enterprise.
• Surfaces: desktop, web, iOS, CLI, and SDK, according to Cursor's changelog.
• Rollout: on by default for Teams; Enterprise admins enable it from the dashboard, per the same changelog.

The r/cursor launch post repeated the product framing from Cursor's blog: every agent request is classified by task type and complexity, then routed to the model Cursor expects to be most cost-effective at comparable quality. Wes Roth's summary captured the enterprise-facing version: lower cost, all surfaces, admin control over eligible models and modes.

Cursor describes Router as a classifier that runs before the model call. The classifier looks at:

• query
• context
• task complexity
• domain
• model behavior profiles

Cursor's launch post says it trained the router on 600k+ live requests and evaluated it through online A/B tests across millions of live requests. Cursor measured user satisfaction through AFC, plus keep rate, meaning how much generated code stayed in the codebase over time.

The cache detail is easy to miss. Cursor says the router is trained on data where routing causes cache misses, and its reported savings include cache-miss costs from production routing decisions.

The docs split Auto into three economic behaviors:

• Cost: uses the previous Auto routing logic, optimizes token spend, and keeps bundled Auto pricing.
• Balance: optimizes for intelligence, speed, and cost.
• Intelligence: routes harder tasks to the most capable models at lower cost than running one frontier model everywhere.

Cursor's Router docs say Cost is billed per million tokens regardless of which model handles the request. Balance and Intelligence bill at the routed model's rate under the team's plan or contract.

The same docs say Balance and Intelligence cost about twice as much as Cost on average, and up to two to four times as much depending on the selected mode. Cursor's models and pricing docs describe the broader split between Cursor Models and Other Models usage pools.

Cursor exposed Router as a governance surface, not just a model picker shortcut.

Admins can configure:

• router enablement per team or group
• which modes users can select
• the default mode
• allow lists and block lists for underlying models
• whether the routed model name is shown
• soft or hard enforcement of Auto

The changelog says routed model names are hidden by default. Cursor's Router docs add two constraints: Router respects Enterprise model access controls, and blocking too many models can reduce routing quality or disable the router.

Grok 4.5 is a special case. The docs say Cursor Router needs a powerful cost-efficient model for non-frontier turns, so enabling Cursor Grok 4.5 is required for the router to work.

Cursor's public numbers are all first-party, but they are production-traffic numbers rather than static benchmark trophies.

The reported cost data:

• Early access across dozens of enterprises: 30% to 50% lower cost at frontier performance, according to Cursor's launch post.
• Online A/B tests across millions of requests: frontier-quality performance at 60% savings, according to the same launch post.
• Three high-volume enterprise accounts: 30% to 50% savings on Auto-routed requests versus Opus 4.8 pricing, with no decrease in quality.
• Cost per commit: $6.76 for Intelligence, $4.63 for Balance, $7.34 for Opus 4.8, and $12.69 for Fable 5.

jediahkatz's cache-miss reply said cache misses can happen, but argued the routed setup still comes out cheaper. In another reply, jediahkatz's Composer comparison narrowed the case: teams already getting one-shot success from Composer 2.5 may not see the same savings.

Cursor telegraphed the economics two days before Router with its SQLite swarm experiment. The setup was unusually concrete: implement the 835-page SQLite manual in Rust, with no source code, tests, SQLite binary, or internet access, then grade against sqllogictest.

Cursor tested four model mixes in the swarm research post:

1. GPT-5.5 as planner and worker.
2. Grok 4.5 as planner and worker.
3. Opus 4.8 as planner, Composer 2.5 as worker.
4. Fable 5 as planner, Composer 2.5 as worker.

The new harness beat the old harness in every mix. Cursor said the new runs reached 73% to 85% by the four-hour cutoff, and every new configuration eventually passed 100% of the held-out suite.

The economic split was the point. Cursor reported $1,339 for the Opus 4.8 plus Composer 2.5 hybrid, versus $10,565 for GPT-5.5 alone. Workers carried at least 69% of the tokens, and over 90% in most runs.

Omar Saravia's planner-worker summary reduced the pattern to three roles: use a frontier model for decomposition and design trade-offs, cheaper workers for narrow implementation, and a recursive task tree to keep each agent's context constrained.

The launch turned routing from gateway infrastructure into an IDE-native feature. Matthew Berman's reaction put it plainly: model routing is first-class now.

The open design question is where routing should live. hwchase17's question asked whether routing needs to be harness-aware or can sit inside a harness-agnostic gateway, while mattlam_'s reply framed the same split as OpenRouter and Vercel-style gateways versus in-harness routers like Cursor.

Arindam Majumder's router analysis argued that Cursor's advantage is workflow ownership: it sees the request, the code context, the follow-up behavior, and what remains in the repo. The same post said standalone routers remain viable outside coding workflows and across multi-application enterprise routing.

Nick Dobos's router-provider joke captured the uncomfortable platform angle: a company that builds models and routes traffic has leverage over which prompts go to its own models and which go elsewhere.

Open routing projects showed up immediately around the launch. Kevin Kern posted Switchloom, an open-source tool for deterministic model routing across coding-agent runtimes.

The screenshot in Kern's post lists runtime choices for Codex, Cursor, Claude Code, OpenCode, and Pi. Its generated team includes an orchestrator, implementer, reviewer, and verifier, with model assignments such as gpt-5.6-terra and gpt-5.6-sol.

Omar Saravia's open-source question was partly about control: Saravia's post said different teams work with different trade-offs, so custom routing matters. In a follow-up reply, Saravia called it a useful open-source project for someone to take on.

Saravia's orchestrator note added a second pattern: routing to several models at once, or splitting one task across different models. mattlam_'s OpenBench thread pointed at the measurement side, with harnesses for Codex, Claude, Cursor, Devin, Grok Build, and Pi evaluated across correctness, token use, and latency.