Cursor Keeps Switching to Composer 2 Fast? How to Fix the Model Routing Bug (2026)

If you keep selecting Composer 2 in Cursor and keep ending up on Composer 2 Fast anyway, you are not imagining it and you have not misconfigured anything. This is a documented Cursor bug, confirmed by Cursor staff on the community forum in March 2026 ("No conspiracy here. It's a bug, and we're going to fix it"). The cost difference is real: per Cursor’s published pricing, Composer 2 Fast is metered at roughly 3x the per-token rate of regular Composer 2 (Fast is the higher-throughput, lower-latency tier), so silent routing to Fast quietly inflates spend.

This is a troubleshooting runbook. It tells you the fastest working fix first, why the bug exists, every confirmed workaround ranked by reliability, how to verify which model you are actually running, and when to stop fighting it and just change versions. If Cursor is also dragging on your repo, our companion runbook on fixing Cursor on big codebases covers the performance side.

What exactly is the Composer 2 Fast bug?

There are actually three overlapping symptoms reported across the Cursor forum. They share a root cause but show up differently depending on where you work:

The forum thread "Model reverts to composer-2-fast on each new chat" documents the IDE case directly: you select Composer 2, open a new chat tab, and the picker is back on Composer 2 Fast. A Cursor team member acknowledged it publicly and a moderator confirmed "the model selection for Composer 2 is being silently switched to Composer 2 Fast."

The CLI case is worse because it is invisible. As staff member deanrie put it on 14 May 2026: "--model composer-2 is accepted, but it actually gets routed to fast. So if you want guaranteed composer-2 non-fast right now, it only works via the SDK." The CLI may even print "Composer 2" in its init banner while billing you for Fast.

Why does Cursor keep switching the model?

Two changes stacked on top of each other and produced the confusion:

1. The picker merge. In Cursor 3.0.13 (released around 8 April 2026), Composer 2 and Composer 2 Fast stopped being two separate entries in the model picker. (For how Composer 2 itself works in Cursor 3, see our Cursor 3 + Composer 2 walkthrough.) They were merged into a single "Composer 2" item with a Fast toggle, and that toggle ships ON by default. The same merged-picker behavior carried into later 3.1.x builds. So after the update, every existing user was effectively switched to the more expensive Fast variant unless they went and turned the toggle off.
2. The persistence bug. On top of the merge, the Fast toggle / model choice does not reliably persist. Open a new chat and the state resets to the default, which is Fast. Cursor's moderator described the root cause as: "The Composer 2 model selection doesn't persist and resets to Composer 2 Fast when you open a new chat."

So the "bug" you are hitting is really default-Fast-plus-non-persistent-state. The picker merge changed where the setting lives; the persistence bug throws your setting away every new session. The CLI variant is a separate routing defect on the cursor-agent backend where the composer-2 id is accepted but resolved to the fast model.

Which fix should I use first?

Ranked by reliability, most reliable first. Use the SDK route if you need a hard guarantee; use the IDE toggle if you just need it working now.

Fix 1: the confirmed SDK workaround

This is the only path Cursor staff have explicitly confirmed gives you guaranteed non-fast Composer 2 right now. Pass the model as a structured object with the fast param disabled rather than passing a bare id string or a CLI flag:

model: {
  id: "composer-2",
  params: [{ id: "fast", value: "false" }]
}

Per deanrie (14 May 2026), the CLI has no documented flag syntax for this override, so if non-fast Composer 2 is a hard requirement for an automation or CI job, drive it through the SDK rather than cursor-agent --model composer-2. A related Composer routing gotcha shows up when wiring third-party models in — see the Composer caveat fix in our DeepSeek V4 in Cursor setup guide.

Fix 2: re-toggle Fast off in the IDE

This is the fastest working fix inside the editor. Per Cursor staff member mohitjain, the steps in the merged picker are:

1. Click the model name at the bottom of the chat panel to open the picker.
2. Hover over Composer 2 in the list to reveal the small Edit button on the side.
3. Click Edit and turn the Fast toggle off.

A keyboard shortcut also exists (default Ctrl+Shift+/ on Windows), though forum users reported it conflicts with some European keyboard layouts, so the menu route is the dependable one. The catch: because of the persistence bug, you will likely have to repeat this in each new chat. It is a workaround, not a cure.

Fix 3: re-select the model each new chat?

The simplest community-and-staff-confirmed workaround for the new-chat reset is exactly what it sounds like: after opening a new chat tab, manually re-select Composer 2 (and confirm Fast is off) before you send the first message. Existing chats keep the correct model; only freshly opened ones reset. Several users in the "sporadically" thread report this is the only thing that holds until a real fix ships. Treat it as a habit, not a solution.

How do I verify which model I'm actually on?

Do not trust the picker label alone, especially in the CLI where the init banner can say "Composer 2" while the request routes to fast. Verify on output, not on the dropdown:

• IDE: open the picker before sending and confirm the Composer 2 entry shows the Fast toggle off. Re-check after every new chat — that is where the reset happens.
• Cost / usage page: the most trustworthy signal is your usage dashboard. Composer 2 Fast is metered at roughly 3x the per-token rate of regular Composer 2 (per Cursor’s published pricing, linked above). If a session you intended as non-fast shows fast-rate usage, you were routed to Fast regardless of what the picker said.
• CLI: assume --model composer-2 is fast unless you are on the SDK with the explicit fast: false param. The flag being accepted is not confirmation; staff explicitly stated it routes to fast.
• Behavioral tell: Fast is noticeably quicker and lower-latency. If "Composer 2" suddenly responds much faster than it did yesterday, you were probably silently moved to Fast. If you are still deciding whether Composer is even the right model for your work, our Cursor Composer vs Claude Sonnet comparison covers that choice.

When should I just downgrade or upgrade?

Version juggling is a blunt instrument here, so use it only deliberately:

• The merged picker arrived in 3.0.13 (~8 April 2026). Builds before the merge presented Composer 2 and Composer 2 Fast as two distinct entries, which sidesteps the toggle-default problem entirely. If you must have a separate non-fast entry and cannot use the SDK, a pre-3.0.13 build is the only structural way to get it back — but you give up every later fix and feature, so this is a last resort, not a recommendation.
• Upgrading does not currently fix it. As of mid-May 2026 the persistence bug and the CLI routing defect were both still open with no shipped fix and no ETA from staff. Upgrading to the latest 3.x keeps you current but does not resolve the reset.
• Practical stance: stay on a current build for security and feature reasons, drive guaranteed non-fast through the SDK, and use the Edit-toggle habit in the IDE. Re-check the Cursor changelog and the linked forum threads — staff said they would post when the CLI routing fix lands.

Is Cursor doing this on purpose?

No, per Cursor's own staff. A Cursor team member responded directly on 22 March 2026: "No conspiracy here. It's a bug, and we're going to fix it." A moderator separately confirmed the team is aware and tracking it. The reason it feels deliberate is that the default lands on the more expensive Fast variant and the bug keeps re-applying that default — an unfortunate combination, but a defect rather than a dark pattern according to the people who wrote it.

FAQ

Why does Cursor keep changing Composer 2 to Composer 2 Fast?

Because Cursor 3.0.13 merged the two models into one picker entry with a Fast toggle that defaults to ON, and a separate persistence bug discards your toggle choice when you open a new chat. The state resets to the Fast default. Cursor staff have confirmed this is a bug.

What is the fastest fix for the Composer 2 Fast bug?

In the IDE: click the model name, hover Composer 2, click Edit, toggle Fast off — repeat in each new chat. For a guaranteed non-fast result programmatically, use the SDK with params:[{id:"fast",value:"false"}], which Cursor staff confirmed actually works.

Does the CLI --model composer-2 flag actually use Composer 2?

No. Cursor staff confirmed on 14 May 2026 that --model composer-2 is accepted but silently routed to composer-2-fast. Only the SDK with the explicit non-fast param guarantees regular Composer 2 right now.

How do I confirm which model Cursor actually used?

Check your usage/cost dashboard rather than the picker label. Composer 2 Fast is metered at roughly 3x the per-token rate of regular Composer 2 (per Cursor’s published pricing). Fast-rate usage on a session you intended as non-fast means you were routed to Fast. Unusually fast responses are also a tell.

Has Cursor shipped a fix for the Composer 2 Fast routing bug?

Not as of mid-May 2026. Both the IDE persistence bug and the CLI routing defect were still open on the Cursor forum with no shipped fix and no ETA. Staff said they would post when the CLI routing fix lands.

Should I downgrade Cursor to get the old picker back?

Only as a last resort. Builds before 3.0.13 keep Composer 2 and Composer 2 Fast as separate entries, but downgrading forfeits every later fix and feature. Prefer the SDK route for a hard guarantee and the Edit-toggle habit in the IDE.

Why does Composer 2 Fast cost more than Composer 2?

Fast is the higher-throughput, lower-latency variant and is metered at roughly 3x the per-token rate of regular Composer 2 (per Cursor’s published pricing). Being silently routed to Fast is what makes this bug a billing problem, not just an annoyance.

If you are scaling a team on Cursor and want engineers who already know its model routing, billing tiers, and agentic workflows cold rather than learning them through bugs like this, Codersera can help you hire vetted remote developers experienced with Cursor and modern AI coding tooling. See codersera.com/hire to extend your engineering team with people who are productive on this stack from day one.