Cursor Auto Routes a Hard Task to a Weak Model

Cursor's Auto router sends a complex refactor to a small model and you get shallow edits. Diagnose the routing signals and force the right model for hard tasks.

You hand Composer a non-trivial task: refactor an auth flow, propagate a type change across 30 files, design a migration. The model picker is set to Auto, and you get back a shallow patch that edits two files, misses the rest, and confidently declares the work done. Switch to Sonnet 4.6 or Opus 4.7 manually and the same prompt produces a thorough multi-file change set.

Fastest fix: for any “refactor / design / migrate / plan” task, click the model name at the bottom of the chat input and pick Sonnet 4.6 (or Opus 4.7 for architecture and novel design). Auto is the right default for typos, single-file edits, and “explain this function” — not for cross-file work.

Why this happens: Auto optimizes for intelligence, cost, and reliability using only the signals it can see (prompt length, attached files, keywords, server health). It cannot see your intent, and per Cursor’s own docs it draws from a separate, cheaper usage pool, so it leans toward smaller models when the request looks small. The fix is partly configuration, partly prompt hygiene, and partly knowing when not to use Auto at all.

How Auto actually routes (June 2026)

Two facts that the older “Fast Requests” mental model gets wrong:

  • Auto picks per request, from a cheap pool. Cursor docs state Auto “selects the best model balancing intelligence, cost-efficiency, and reliability.” It bills from a dedicated Auto pool (roughly $1.25/M input and $6/M output as of June 2026) that is much cheaper than calling a frontier model directly. Cheap pool plus a “this looks simple” signal is exactly how a hard task lands on a small model.
  • Billing is usage credits, not Fast Requests. Cursor retired the old fixed “fast premium requests” counter in mid-2025. Paid plans (Pro $20, Pro+ $60, Ultra $200 per month, as of June 2026) now include a dollar-denominated usage pool instead. Crucially, Auto usage is effectively unlimited on paid plans and does not draw down that pool — which is why the router happily reaches for it.

So “Auto is broken” is usually wrong. Auto is calibrated for small tasks and is doing its job; the failure is using it for work it was never tuned to route.

Common causes

Ordered by likelihood for under-routing.

1. Prompt too short for the actual scope

Auto reads prompt length as a complexity proxy. Refactor auth to use JWT is 24 characters. The router sees a tiny request and picks a fast model, even though the work behind those characters is enormous.

How to spot it: your prompt is one line, the task spans many files, the result is shallow. Long, explicit prompts trigger heavier models far more reliably.

2. No files attached to the chat context

When the @-context is empty, Auto assumes a generic question and routes to a small model. Even a long prompt with no context reads as “probably a Q&A turn.”

How to spot it: the context chips above the input show zero attached files, folders, or docs.

3. Task type doesn’t match Auto’s heuristics

Auto’s routing is tuned for common shapes: small inline edits, single-file Q&A, simple completions. “Write a migration,” “design an interface,” “plan an architecture” do not fit those shapes and get under-routed. Cursor staff and community testers describe Auto as a blend of “various cheap models” that works fine “unless you’re doing anything novel.”

How to spot it: the task is design-heavy or cross-file but phrased like a casual question. The output is plausible but thin.

4. Chat history pollution biases routing

Auto can use the running conversation as a signal. If the last several turns were trivial (“add a log line,” “rename this var”), the next request inherits that “small-task session” prior even when the new prompt is huge.

How to spot it: starting a fresh chat with the exact same prompt produces a noticeably better answer than reusing the long-running session.

5. Codebase indexing not complete

If indexing is still running or stale, @codebase context is thin. Auto sees a small effective context and routes down. See Cursor indexing never completes.

How to spot it: the status bar shows indexing in progress, or @codebase returns very few hits for a known-good query.

6. Cursor silently fell back to Auto

There is a recurring bug where Cursor reverts your manually selected model to Auto, especially after a model has degraded performance or during an Auto-routing incident (Cursor’s status page logged an Auto-routing degradation on June 16, 2026). You think you are on Opus 4.7; the badge under the response says Auto.

How to spot it: check the model badge under the actual assistant turn, not the picker. If it says Auto when you chose otherwise, this is your bucket.

Which bucket am I in?

SymptomMost likely causeJump to
One-line prompt, multi-file task, shallow resultPrompt too short (1)Step 2
No @files / @folders attachedEmpty context (2)Step 2
”design / migrate / plan” task phrased casuallyHeuristic mismatch (3)Steps 1, 5
Same prompt is better in a fresh chatHistory pollution (4)Step 3
@codebase returns few hits, status bar indexingStale index (5)indexing guide
Badge says Auto though you picked a modelSilent fallback (6)Step 1

Before you start

  • Note which model Auto actually picked: hover the response or read the model badge under the assistant turn (not the picker).
  • Confirm indexing is complete and the open workspace is the one you think it is.
  • Save the prompt text. You will rerun it with an explicit model selection.
  • Glance at the Cursor status page to rule out an active Auto-routing incident.

Step-by-step fix

Ordered fastest to most thorough.

Step 1: Switch the model picker off Auto for hard tasks

The lowest-effort fix. Click the model name at the bottom of the chat input (or the dropdown at the top-left of the Cmd+K inline-edit popup):

chat input -> model name -> Sonnet 4.6   (or Opus 4.7 for design / planning)

Auto is a good default for “fix this typo” or “explain this function.” It is the wrong default for “refactor,” “design,” “migrate,” “plan,” or anything cross-file. Build a habit: a heavy verb in the prompt means a manual model. If the badge under your response still reads Auto after you selected a model, you hit the silent-fallback bug (cause 6) — reselect and resend.

Step 2: Expand the prompt and attach context explicitly

A vague prompt with no context routes down. Reframe:

Refactor src/auth/* from session cookies to JWT.
@src/auth @src/middleware @docs/auth-design.md

Constraints:
- Keep the public API (login, logout, refresh) unchanged
- Update tests in src/auth/__tests__/
- Use jose for signing, not jsonwebtoken
- Migration plan for existing session DB rows

Produce a step-by-step plan first, then execute.

Length, attached folders, and structured constraints all push Auto toward heavier models. Even on Auto, this often gets you the right routing.

Step 3: Start a fresh chat for major tasks

Long chats inherit prior-turn bias. For anything serious, open a clean Composer chat (Cmd+N / Cmd+L) and paste the big prompt into it. The router then scores the request on its own merits instead of the session’s small-task history.

Step 4: Pin a default model for engineering repos

Cursor is built on VS Code, so per-project settings live in .vscode/settings.json committed to the repo. The chat default is reliable:

{
  "cursor.chat.defaultModel": "claude-sonnet-4.6"
}

This makes the auth-refactor repo open on Sonnet by default while a docs repo can stay on Auto. The Composer-specific key has changed across Cursor releases — if a cursor.composer.defaultModel line does not stick, set the default instead under Settings -> Models and pick the model per chat. Restart Cursor after editing workspace settings so it reloads them.

Step 5: Two-pass it — plan with a strong model, execute with Auto

For long executions you want to keep cheap, use a strong model to draft a detailed plan, then hand the plan to Auto:

Pass 1 (Opus 4.7):
Produce a detailed step-by-step plan for the JWT migration. List every file to
touch and the diff intent for each. Do not execute yet.

Pass 2 (Auto):
Execute the plan from the previous message exactly. Do not reorder steps.
For each step, edit the named file and report back.

The explicit plan substitutes for the routing signal Auto could not infer.

Step 6: If routing stays wrong, send feedback

Cursor uses aggregate feedback to tune Auto. After a bad routing decision, give the response a thumbs-down and note in the comment that Auto under-routed a complex task. There is no per-account “force strong model” switch, so this is a slow lever — Steps 1 and 4 are what actually fix today’s session.

How to confirm it’s fixed

  • Re-run the same prompt with Sonnet 4.6 forced; the output is deeper than Auto’s was, and the model badge under the response reads claude-sonnet-4.6, not auto.
  • Run a clearly trivial prompt (rename foo to bar in this file) on Auto; it picks a fast model and is correct. Auto is not broken, just calibrated for small tasks.
  • Cross-file refactors with explicit context and a workspace-pinned default now consistently engage the strong model on the first try.

Long-term prevention

  • Default to manual model selection for Composer in engineering repos; reserve Auto for chat-style Q&A.
  • Write longer, more specific prompts even when you “know what you mean” — the router does not.
  • Always attach @folder or @codebase context for cross-file tasks.
  • Use the two-pass plan-then-execute pattern for big migrations.
  • Watch your monthly usage credits so a near-empty pool is not a hidden variable (Settings -> Usage).
  • Keep a reusable “hard task template” snippet that pre-attaches structure and constraints.

Common pitfalls

  • Believing “Auto means best model available.” Auto means “cheapest model the router thinks will work” — a different optimization.
  • Re-running the bad prompt unchanged hoping for a different result. Same inputs, same routing.
  • Setting a default model only in user settings, so it leaks across projects. Prefer per-project .vscode/settings.json.
  • Mixing trivial and serious work in one chat session; the trivial turns bias the heavy one.
  • Forgetting that index depth affects routing. Stale index means thinner context means weaker routing.
  • Burning Opus 4.7 usage on tasks Sonnet 4.6 handles equally well, then running low when the genuinely hard task needs it.

FAQ

Q: Can I force Auto to always pick a strong model?

No — Auto is the router, and there is no per-account override. But pinning cursor.chat.defaultModel (or selecting the model per chat) effectively bypasses it for the work that matters.

Q: Why does Auto route differently for the same prompt on different days?

Cursor docs say Auto factors in current server reliability and can hop models during outages or rate-limit blips, on top of per-request complexity scoring. It is not deterministic, and an Auto-routing incident (such as the one on June 16, 2026) can change behavior for hours.

Q: Does a longer prompt always mean better routing?

Length is one signal. Specificity, attached context, and verbs like “design,” “refactor,” “plan” matter more. A 500-character vague prompt routes worse than a 200-character precise one with @folder context.

Q: Should I just always use Opus 4.7?

No. Opus burns usage credits the fastest. Match the model to the task: Sonnet 4.6 is the workhorse for most cross-file work; reserve Opus 4.7 for novel design or genuinely hard reasoning.

Q: I selected a model but the response shows Auto — why?

That is the known silent-fallback bug (cause 6). Cursor sometimes reverts to Auto when a model degrades or during a routing incident. Reselect your model and resend, and check the status page.

Tags: #Cursor #Troubleshooting #Composer large project #AI coding