Cursor Router for QA can reduce the manual work of choosing an AI model for every coding task, but an automatic routing decision is still a variable in your test-engineering workflow. Cursor’s official July 22, 2026 announcement says Auto mode classifies each request using its query, context, complexity, and domain, then routes it to an underlying model. For QA teams, the right question is not simply whether routing works. It is whether the routed workflow produces acceptable test changes, reliable evidence, predictable controls, and a cost profile your team can defend.

This tutorial shows how to run a bounded pilot across Cursor Router’s Cost, Balance, and Intelligence modes. You will use the same representative QA tasks, fixed acceptance criteria, repeated runs, deterministic test execution, and human review. The goal is a local decision based on your repository and risk profile, not an attempt to reproduce Cursor’s vendor-reported benchmarks.

What Cursor Router officially supports

Cursor documents three optimization modes. Cost seeks good quality while optimizing spend. Balance targets strong everyday quality. Intelligence prioritizes frontier-level capability. Cursor says admins can enable Router by team or group, restrict available modes, set a default, allow or block underlying models, control whether the routed model is shown, and apply soft or hard enforcement for Auto.

The official changelog says Router is available across desktop, web, iOS, CLI, and the SDK, with Teams enabled by default and Enterprise enablement controlled from the dashboard. Check your current plan, organization settings, and official documentation before testing because access and controls can change.

Cursor also publishes production and early-access quality and cost observations. Treat those numbers as vendor-reported results from Cursor’s traffic and methodology, not a promise for your test suite. Your repository, prompts, test framework, acceptance criteria, cache behavior, model allowlist, and human review process can produce different outcomes.

QA scenario: evaluate automated test maintenance

Assume an SDET team wants to use Auto mode for routine test maintenance. The pilot covers three task classes:

  • Simple: add a missing negative API assertion to an existing test.
  • Medium: diagnose and repair a flaky Playwright locator without weakening the user journey.
  • Complex: design regression coverage for a checkout rule spanning UI, API, and fixture layers.

Use a disposable branch and a staging-only environment. Freeze the starting commit, dependencies, test data, instructions, and acceptance criteria. Never include production credentials or personal data in the pilot.

Step 1: define success before choosing a mode

Create a scoring rubric that does not depend on the agent’s own explanation. Include whether the requested behavior is covered, assertions check business outcomes, existing test intent is preserved, repository conventions are followed, focused and surrounding tests pass, the diff stays in scope, assumptions are disclosed, and recorded usage stays within budget.

Define hard failures separately. Examples include deleting an assertion to make a test green, adding a broad retry, changing application code outside scope, fabricating test evidence, exposing a secret, or attempting a production action.

Step 2: build a small evaluation matrix

Run each task in Cost, Balance, and Intelligence modes. Repeat each combination at least three times if your budget allows, starting from the same clean commit. Model routing and generation are not deterministic, so a single successful run is weak evidence.

Task Mode Score Hard failure Tests Review time Usage
API assertion Cost 0-10 Yes/No Pass/Fail Minutes Team metric
Flaky locator Balance 0-10 Yes/No Pass/Fail Minutes Team metric
Checkout coverage Intelligence 0-10 Yes/No Pass/Fail Minutes Team metric

Do not infer cost from output length alone. Use the usage or billing evidence available to your organization, sanitize exported records, and document exactly what the number represents.

Step 3: validate organization controls first

Before judging output quality, test the administrative boundary. Create a small pilot group rather than enabling Router for everyone. Confirm the expected default mode, permitted modes, model allowlist or blocklist, routed-model visibility setting, and soft or hard enforcement behavior.

Use both an ordinary member account and an administrator account. Verify that a member cannot select a restricted mode or bypass a blocked underlying model. If routed-model visibility is disabled, do not invent model-level conclusions from response style. Record only the mode and controls you can observe.

Step 4: run the simple task

Use an existing API test that checks only a happy path. Ask for one negative authorization assertion using the repository’s current style. Require the agent to identify the target behavior, change only the relevant test file, run the focused test, and summarize assumptions.

Review the diff against the rubric. A valid change should verify a meaningful response condition, preserve existing assertions, and avoid embedding credentials. Independently run the focused test and nearby API suite. Capture the command, commit, sanitized report, and reviewer score.

Step 5: run the flaky-test task

Provide a sanitized Playwright failure with its trace, screenshot, and error. Ask the agent to identify the root cause before editing. The acceptable fix should wait for meaningful application state or improve locator intent. It should not add a fixed delay, force-click, broad retry, or skipped assertion.

Run the repaired test repeatedly and execute the surrounding journey in CI. Compare the explanation with trace and DOM evidence. If a run passes only after weakening an assertion, mark it as a hard failure even if the command exits successfully.

Step 6: run the complex coverage task

Give the agent a checkout requirement with explicit business rules, existing UI and API tests, fixture constraints, and a request to propose coverage before editing. Score boundary cases, data isolation, layer selection, observability, and maintainability.

Require a human to approve the plan before implementation. After the change, inspect every assertion and fixture. Run deterministic UI, API, and integration checks that correspond to the proposed coverage. A persuasive plan is not evidence that the implemented suite covers the rule.

Step 7: measure repeatability and review burden

For each repeated run, reset the branch and reuse the same inputs. Track acceptance score, hard failures, test results, unnecessary files changed, reviewer corrections, review time, and recorded usage. Also note whether the routed model was visible under your organization’s settings.

Look for distributions rather than one winner. A lower-cost mode may suit a narrow assertion task while producing excessive rework on complex coverage. A higher-intelligence mode may improve a difficult plan but add unnecessary changes to a simple test. Your policy can assign modes by task risk rather than forcing one setting everywhere.

Step 8: test failure and governance paths

  1. A member tries to select a restricted optimization mode.
  2. A request would require a blocked underlying model.
  3. Model display is hidden and the evaluator records only observable facts.
  4. The agent proposes accessing production or secrets.
  5. A test command fails but the narrative claims completion.
  6. The generated diff exceeds approved scope.
  7. The organization changes the default mode.
  8. The team rolls back to its previous selection policy.

Document who can change these settings and how reviewers learn that a policy changed. Routing behavior may evolve as the classifier and model pool change, so re-run a compact evaluation after material configuration or product changes.

Step 9: choose a rollout rule

Summarize results by task class. A sensible decision may allow Cost for well-specified low-risk edits, Balance for normal maintenance, and Intelligence for approved complex analysis. Another team may keep manual selection for security-sensitive work. The evidence should decide.

Set stop conditions such as secret exposure, repeated weakened assertions, control bypass, unacceptable variance, or review effort above the team’s threshold. Keep merge and release approval with accountable people.

Screenshot plan

  1. Cursor Router documentation showing three modes.
  2. The admin panel with sensitive names redacted.
  3. A mode restriction tested with a member account.
  4. The fixed task-and-acceptance matrix.
  5. A sanitized API-test diff and deterministic result.
  6. A Playwright trace beside the locator fix.
  7. The repeated-run score sheet.
  8. The final rollout and rollback rule.

QA checklist

  • Use current official Cursor documentation as the source of truth.
  • Freeze the commit, inputs, environment, and rubric.
  • Test all three modes on representative tasks.
  • Repeat runs instead of trusting one sample.
  • Verify group enablement, restrictions, defaults, visibility, and enforcement.
  • Score hard failures separately from average quality.
  • Run tests independently and preserve sanitized artifacts.
  • Measure reviewer corrections and time, not only output.
  • Treat vendor benchmarks as context, not guarantees.
  • Keep human merge and release approval.

Common mistakes

  • Comparing different prompts: changing the task invalidates the mode comparison.
  • Trusting a green command: the wrong tests or weakened assertions can still pass.
  • Assuming the routed model: use only visibility your configuration permits.
  • Ignoring variance: one excellent run can hide repeated failures.
  • Using production data: evaluate with sanitized staging fixtures.
  • Optimizing only for spend: include review time, correction effort, and risk.

References

FAQ

What is Cursor Router?

Cursor describes it as a classifier behind Auto mode that considers the request, context, complexity, and domain to select an underlying model.

Which Router mode should a QA team use?

There is no universal answer. Evaluate all three on representative tasks with fixed criteria, repeat runs, deterministic tests, and review-effort measurements.

Do Cursor’s published results guarantee our results?

No. They are vendor-reported observations. Your repository, prompts, controls, model pool, and acceptance criteria can differ.

Can Auto mode replace test review?

No. Routing does not prove test intent, coverage, security, privacy, or release readiness. Keep deterministic validation and human approval.

Conclusion

Cursor Router for QA is best evaluated as a controlled workflow component, not a magic quality switch. Test each mode on the same real tasks, validate admin boundaries, repeat runs, measure cost and review effort, and independently execute the affected tests. The safe pattern is automatic routing for bounded assistance, deterministic tools for evidence, and accountable people for decisions.