Cursor Router makes model choice invisible. Your release evidence cannot be

Cursor can now choose a model for every request instead of asking a developer to choose one model for an entire coding session. That sounds like a small interface change. It is actually a new production dependency: a classifier decides which model sees the request, a model switch can change cache behavior, and the available pool can change after a vendor release.

In its Cursor Router announcement, Cursor says it trained on more than 600,000 live requests, evaluated on millions of routed requests, and observed roughly 30–50% lower cost for three high-volume early-access accounts compared with pricing all of that traffic at Opus 4.8 rates. It also reports lower cost per commit for its Balance and Intelligence modes than for the named single-model comparisons.

Those are useful vendor observations, not a savings forecast for your repository. Cursor’s satisfaction classifier, keep rate, customer mix, model pool, prompts, and harness all belong to Cursor’s environment. A team shipping a payments integration, a multilingual onboarding flow, or a compliance-sensitive admin tool has a different task distribution and a different cost of failure.

The change to make today is not “turn routing on” or “ban routing.” Create an accepted-change audit before Auto becomes the team default. Measure the complete work unit—from request to reviewed, merged result—and preserve enough routing evidence to explain a regression.

This field note proposes a 36-task, two-arm rollout, a route receipt, and a promotion matrix. Y Build did not run Cursor Router, reproduce Cursor’s figures, or compare the named models. Every threshold below is a starting hypothesis for your team, not a reported result.

What Cursor released, and what remains unknown

Cursor Router is available to Teams and Enterprise customers across desktop, web, iOS, CLI, and the SDK. It classifies each request using the query, context, task complexity, domain, and Cursor’s knowledge of model behavior. Admins can choose Cost, Balance, or Intelligence, enable the router for a group, restrict modes, and allow or block underlying models. The release changelog adds an operationally important detail: the routed model may be shown or hidden, and hidden is the default.

Cursor says its online evaluation includes the extra cache-miss cost created by switching models within a conversation. Its quality signals include whether a user appears to move on or correct the agent, plus how much generated code remains in the repository. A separate explanation of Cursor’s agent-harness measurement describes keep rate, satisfaction inferred from follow-up messages, latency, token efficiency, tool-call count, and cache-hit rate.

The published numbers are still aggregate vendor claims. The announcement does not expose the routing classifier, per-category sample sizes, confidence intervals, model-selection confusion matrix, routing version history, or a customer-level distribution behind the three highlighted accounts. “No decrease in quality” depends on Cursor’s quality proxy. “Cost per commit” does not reveal whether a commit survived review, required a follow-up fix, or shipped.

Several product questions are also open for a new team rollout:

• Can your admin export the selected model for every routed request, even when the user interface hides it?
• Can you pin the eligible model pool and router mode for the duration of an experiment?
• What happens to an in-progress conversation when the selected model changes?
• Can sensitive repositories exclude a provider, model version, or region without silently changing the comparison arm?
• Can you distinguish router savings from unrelated changes in the agent harness?

Do not turn those unknowns into accusations. Turn them into acceptance criteria.

A router is a release system, not a cheaper model picker

A single-model policy has obvious limitations, but it is legible. The team knows which model was intended, can reproduce a request against the same snapshot when it remains available, and can attribute a price change to a published rate or a larger prompt.

A request-level router inserts a policy between intent and execution. The router can improve the match between task and model, but it can also change three things at once:

1. Capability: a routine edit may go to a cheaper model while a migration goes to a frontier model.
2. Economics: the chosen model, prompt size, cache state, retries, and follow-up turns determine the real bill.
3. Governance: the selected provider may have different data handling, geographic, contractual, or organizational approval constraints.

Academic routing work supports the basic opportunity without validating Cursor’s implementation. RouteLLM learns to choose between stronger and weaker models using preference data and reports cost-quality trade-offs on public benchmarks. FrugalGPT studies prompt adaptation, model approximation, and cascades. Both show why heterogeneous models can outperform a one-model-for-everything policy under a budget. Neither proves that a coding-agent router will preserve your merge quality or data boundary.

That is why the release unit must be the routed system: classifier, eligible pool, model snapshots, harness, cache behavior, admin policy, and human review. If any of those changes, the experiment version changes.

Define an accepted change before counting savings

A request is not the product outcome. A response is not the outcome either. Even a commit is only an intermediate artifact.

For this audit, define an accepted change as a task whose final diff:

• satisfies a written task-specific acceptance check;
• passes the repository’s deterministic checks;
• receives human review without a severity-one correction;
• is merged or deliberately accepted into the release candidate;
• remains unreverted through the audit window.

Use a short audit window appropriate to the release cadence—perhaps 48 hours for a daily product and seven days for a weekly release. The point is not to wait forever. It is to catch the common case in which an apparently complete agent edit creates immediate repair work.

Then calculate fully loaded cost per accepted change:

(agent usage cost
 + rerun cost
 + reviewer minutes × agreed internal rate
 + author correction minutes × agreed internal rate
 + rollback or incident minutes × agreed internal rate)
÷ accepted changes

This is not an accounting standard. It is a comparison instrument. Use the same internal rate and time-capture rule for both arms. Keep subscription seat cost separate unless routing changes the number of seats required during the experiment.

Cursor’s cost-per-commit figure is still relevant: it is closer to delivered work than token price. The audit extends that idea one step further because a low-cost commit that is rejected, heavily rewritten, or reverted is not a saving for a small team.

Build a task deck that can expose wrong routing

Random production traffic is realistic but difficult to interpret. A generic coding benchmark is comparable but may not represent the work you ship. Use a fixed task deck drawn from your own recently completed work, then replay it in isolated branches or disposable repository copies.

Start with 36 tasks across six buckets:

Use six tasks per bucket. Include easy and difficult examples inside every bucket so a router cannot appear intelligent merely by sending an entire category to the strongest model. The EACL 2026 study How Robust Are Router-LLMs? found that evaluated routers could make blunt category-level choices, including routing all coding and mathematics queries to the strongest model even when weaker models could handle some of them. It also found safety-relevant category failures. That result is about the evaluated routers, not Cursor Router, but it justifies testing within-category variation.

Freeze the task statement, starting commit, available tools, repository rules, time ceiling, and acceptance checks. Remove secrets and customer data. Do not reuse an unresolved production vulnerability as a convenient fixture.

Run two arms without pretending the world stands still

Compare one Router mode with one intentionally chosen single-model baseline. For most teams, Balance versus the current daily-driver model is the clearest first decision. Testing Cost, Balance, Intelligence, and several single models at once spreads 36 tasks too thin and invites post-hoc storytelling.

Treat 36 tasks as a release screen, not a statistically powered proof of superiority. Its job is to reveal local regressions, correction cost, and missing evidence before a broader cohort—not to produce a universal percentage claim.

Randomly assign runs within each task bucket:

• Arm A: Cursor Router in the selected mode.
• Arm B: the team’s existing single-model default.

If running both arms on every task is affordable, use all 36 tasks twice. Otherwise split matched tasks by difficulty and alternate arms, then rerun every disagreement. Keep reviewers blind to the arm until they record acceptance and correction severity. A developer who knows that one diff came from the “cheap” arm may unconsciously review it more harshly.

Control what you can: same repository state, same rule files, same tools, same time ceiling, same acceptance command, and no human hints after the initial request. Record what you cannot control: service incidents, model retirements, harness releases, and router pool changes. The goal is not laboratory purity. It is an honest decision under production-like conditions.

Use a minimum observation window spanning normal and peak working hours. A router optimized partly for availability can behave differently when a provider is degraded. If an outage occurs, preserve it as a named stratum instead of deleting the “messy” data.

Preserve a route receipt for every task

An aggregate dashboard can tell you that spend fell. It cannot explain why a high-risk migration failed or whether a blocked provider was used. Create one receipt per task, joining system telemetry to the final artifact.

audit_id: router-2026-07-23-017
task_id: auth-session-rotation-04
bucket: risky-migration
arm: router-balance
router_mode: balance
router_version: unknown
eligible_models_policy: team-policy-2026-07-23
selected_models:
  visible_to_user: false
  exported_values: []
started_at: 2026-07-23T01:15:00Z
ended_at: null
usage:
  input_tokens: null
  cached_input_tokens: null
  output_tokens: null
  provider_cost_usd: null
workflow:
  follow_up_turns: 0
  reruns: 0
  tool_errors: 0
  human_correction_minutes: null
acceptance:
  deterministic_checks: pending
  reviewer_decision: pending
  severity_one_correction: false
  merged: false
  reverted_in_window: false
policy:
  provider_allowed: pending
  privacy_mode_enforced: pending
result: pending

null, unknown, and an empty array are valid results. They expose an observability gap instead of fabricating precision. If the selected model is hidden and the admin export does not reveal it, record that fact. The inability to investigate a route may itself block rollout for a high-risk repository.

Cursor’s Admin API documentation describes granular usage records including model, token consumption, and cost. Confirm that the current endpoint and your plan expose the fields needed for routed requests before the experiment; documentation coverage is not proof that every workspace exports every Router field.

Measure five outcomes, not one blended score

Do not compress the audit into a single “router score.” A weighted score lets a large cost reduction hide a small number of severe failures. Report five separate outcomes.

Treat the acceptance delta and severity-one failures as gates. Treat cost, time, and cache as optimization metrics after those gates pass. Report medians and tails because one expensive repair can erase savings across many trivial changes.

RouteJudge proposes router-level records that preserve the query, routing decision, responses, preference labels, cost, latency, and task metadata. Its public pairwise design is broader than this repository audit, but the record shape makes the same point: router evaluation needs decision-level evidence, not just a model leaderboard.

Also keep subjective review separate from deterministic acceptance. A reviewer can prefer the style of one solution while tests reveal a broken migration. Conversely, a mechanically correct patch can impose maintenance debt. Both signals matter; neither should silently overwrite the other.

Test cache, conversation switches, and correction loops

Request-level routing happens inside conversations, while coding tasks often depend on context accumulated over several turns. A model switch can lose provider-specific cached input savings even when the visible conversation remains intact. Cursor says its production evaluation includes cache-miss cost, but your mix of large rule files, attached documentation, and long sessions may differ.

Add three scripted conversation fixtures:

1. Stable continuation: inspect, edit, test, and explain one feature across four turns.
2. Late difficulty spike: begin with a local edit, then reveal a cross-file failure that requires deeper reasoning.
3. Correction loop: reject the first patch with a fixed test failure and require one repair.

For each fixture, capture selected-model visibility, input tokens, cached input tokens, follow-up count, total cost, and whether the final change is accepted. Do not infer a model switch solely from a cache miss; context pruning, prompt changes, or provider behavior can also change caching.

The useful question is not “Did the router switch?” It is “Did the full conversation reach an accepted change at lower fully loaded cost without creating an investigation gap?” A switch that costs more but rescues a difficult task can be valuable. A cheap first turn that causes three correction turns may not be.

Make provider and privacy policy part of quality

Routing expands the set of possible model providers. That can be operationally useful, but a request is not acceptable if it violates the repository’s provider policy, even when the code is excellent.

Cursor’s data-use overview says Privacy Mode prevents Cursor and model providers from using customer data for training, and that Cursor maintains zero-data-retention agreements with providers. It also documents exceptions around abuse detection and says non-ZDR models are designated or require admin opt-in. Cursor’s May 2026 model-controls update says enterprise admins can block providers or model configurations and can block new providers or versions by default.

Translate those controls into a local policy test:

• list permitted providers and model classes for each repository tier;
• enforce Privacy Mode at the organization level where required;
• block newly introduced providers by default for sensitive work;
• include a synthetic canary task for every policy tier;
• verify the exported route against the policy, not only the dashboard setting;
• stop the experiment if the selected provider is unknown where disclosure is required.

This is not a claim that Cursor violates its policy. It is ordinary acceptance testing for a dynamic dependency. A configuration screenshot proves intent; a route receipt provides execution evidence.

Use explicit promotion and rollback gates

Choose thresholds before seeing results. The following matrix is deliberately conservative and should be adjusted to the cost of failure in your product.

Promotion should name a scope: one team, selected repositories, one Router mode, one eligible model policy, and one review date. Do not write “Router approved” without those qualifiers.

Rollback must also be rehearsed. Confirm that admins can disable Router, restore the single-model default, retain audit records, and notify users whose active conversations may be affected. A feature flag that exists but requires a support ticket is not an immediate rollback.

NIST’s AI RMF Measure guidance recommends monitoring production behavior, comparing production with pre-deployment measurements, documenting overrides, and reassessing metrics as models and operating settings change. For a router, that means approval expires: repeat a small sentinel deck after a router release, eligible-pool change, major model update, price change, or material shift in repository work.

Know when this experiment does not apply

This protocol is for a small team deciding whether to standardize a request-level router in coding work. It does not evaluate general chat, customer-support routing, medical or legal decision systems, or a router you cannot observe at all.

Thirty-six tasks can reveal obvious local problems; it cannot estimate rare failure rates or prove universal superiority. Human review introduces variation. Recently completed tasks may leak familiarity to developers. Replayed repositories omit production pressure. Fully loaded cost depends on an internal time rate that may be contentious. The single-model baseline may itself change during the window.

The cited routing papers study different model pools, tasks, labels, and constraints. RouteLLM and FrugalGPT do not validate Cursor Router. RouteJudge is a proposed evaluation platform, not evidence that Cursor exposes its fields. The EACL robustness findings show failure modes in tested routers, not a demonstrated Cursor defect. Cursor’s reported savings remain Cursor’s results until independently reproduced in a comparable environment.

Do not run this audit with real secrets, unisolated production writes, or unresolved customer incidents. If a repository cannot tolerate provider ambiguity, require route disclosure before any experiment rather than attempting to discover it afterward.

A two-day field plan for a small team

On day one, choose the baseline model and one Router mode. Select 36 sanitized tasks from recent work, assign six buckets and difficulty labels, write acceptance checks, freeze starting commits, and agree on correction-time capture. Configure provider allowlists and Privacy Mode. Verify that the admin export exposes the model and usage fields you intend to audit. If it does not, record the gap and decide whether low-risk repositories can proceed.

On day two, run the paired tasks in isolated branches, keeping reviewers blind to the arm. Store one route receipt per run. Re-run disagreements and the three multi-turn conversation fixtures. Calculate acceptance, correction, fully loaded cost, delivery time, and governance separately. Review tail failures before averages.

End with a signed decision note containing the cohort, repositories, Router mode, baseline model, eligible pool policy, observed window, failed tasks, unresolved unknowns, rollback owner, and expiry date. If the gates fail, the useful output is not a disappointing benchmark. It is a precise reason not to make an invisible dependency the default yet.

Cursor Router may lower the price of ordinary coding work. The release question is whether the saving survives review, correction, policy, and time. Count accepted changes, preserve route evidence, and make the router earn its place in the shipping system.

References

1. Cursor — Introducing Cursor Router
2. Cursor — Router changelog
3. Cursor — Continually improving our agent harness
4. Cursor — Admin API
5. Cursor — Data Use & Privacy Overview
6. Cursor — Model controls, spend management, and usage analytics
7. Ong et al. — RouteLLM: Learning to Route LLMs with Preference Data
8. Chen, Zaharia, and Zou — FrugalGPT
9. Lai, Hu, and Ye — RouteJudge
10. Kassem, Schölkopf, and Jin — How Robust Are Router-LLMs?
11. NIST — AI RMF Measure Playbook