Disabling subagents should actually disable Composer 2 usage legacy plan users should not be forced into Composer 2 Fast

Ideas Feedback
, ,
1

image
image1227×295 21.7 KB

I’m on a legacy Cursor plan with 500 credits/month, and I’m getting increasingly frustrated with how Cursor is handling model routing, max model gates, subagents, and the constant need to remind me how crappy Composer 2 is.

In my settings, I have the Explore subagent model disabled. Yet, Cursor still creates a “New subagent” and routes work through Composer 2.

That is exactly what I am trying to avoid.

I do not want Composer 2 near my codebase. I want to use the model I selected, such as Opus, and I expect Cursor to respect that choice. If I disable subagents, the IDE should not silently create subagents anyway. in order to override I need to select max… for what to burn my credits for no reason…

The current behavior feels especially bad for legacy-plan users. It increasingly feels like Cursor is making the old credit-based plan less useful by pushing more features behind Max Mode or forcing routing through Cursor’s own models. Previously, we could use the same amount of credits and tokens with the frontier models we chose. Now, more and more of the workflow seems designed to push users toward the newer pay-as-you-go model, even when we explicitly do not want that.

The frustrating part is not just the pricing. It is the lack of control.

If Composer 2 is optional, then make it optional. If subagents are disabled, they should be disabled. If a model is selected, that model should be used unless the user explicitly chooses otherwise.

Right now, the experience feels like this:

  1. I choose Opus.

  2. I disable the Explore subagent.

  3. Cursor still creates a subagent.

  4. That subagent uses Composer 2.

  5. The only reliable way to override this seems to be Max Mode.

That is not a good user experience.

I understand Cursor wants to promote its own model. That is fine. But forcing Composer 2 into workflows where users deliberately selected a frontier model is not acceptable. Composer may be useful for some people, but it should not be shoved into the middle of an existing workflow without clear consent.

Please give users a real setting for this:

  • Disable all built-in subagents completely.

  • Never use Composer / Composer Fast unless explicitly selected.

  • Make “inherit parent model” actually inherit the parent model.

  • Do not require Max Mode just to prevent unwanted model substitution.

Cursor is at its best when it gives developers control. This current behavior removes control and makes upgrading the IDE feel worse, not better.

I want to keep using Cursor, but I need it to respect my model choices and my plan. Right now, it feels like legacy users are being pushed into Composer and pay-as-you-go by design, rather than being given a straightforward, predictable product.

5

Hey, thanks for the detailed feedback. The request is clear, and it’s something we’ve heard before.

Quick status update: on request-based plans without Max Mode, auto-spawned subagents really do get routed through Composer no matter which model you picked for the main agent. The setting “Explore subagent model: Disabled” only affects the Explore subagent. It doesn’t cover other subagent types that Composer 2 spawns on its own during the process. So what you’re seeing isn’t exactly a bug, it’s a current limitation in how subagent routing works.

The points you listed make sense. Fully disabling built-in subagents, not using Composer unless the user explicitly picks it, making “inherit parent model” actually inherit the parent model, and not requiring Max Mode to prevent model swapping are all reasonable asks. They’re on our radar, and we keep getting similar reports. I’ll pass your post along with extra focus on the legacy plan angle, since the current behavior makes the old plan less predictable in practice. I can’t share an ETA. This isn’t only a product decision, it depends on what models will be available for subagents on different plans.

For now the only workaround is the one you mentioned, Max Mode. There isn’t another reliable way to block Composer for subagents on a request-based plan right now.

6

Thanks for the clarification, but the key issue remains,

“The only workaround is Max Mode” is not an acceptable answer.
And you wouldn’t accept it either in the real world.
This feels like paying for premium gas, then finding out the pump is mixing in a cheaper gas for part of the fill. And when its pointed out, the answer is basically:, “Yeah, that’s how it works now. If you want only premium, use the more expensive pump.”

That is the frustrating part. I chose a specific model for a reason. I should not have to pay extra just to stop Cursor from substituting a different model.
And to be clear, this is not only about cost. I also do not want my code routed through models I did not choose. I do not want Composer touching my code unless I explicitly select Composer.

In practice, this means Cursor changed the product behavior, legacy/request-based users lost control over model routing, and the only way to get that control back is to pay more and consume far more credits.

That feels punitive.

This was not how the product worked before. I selected a frontier model because I wanted that model working on my code. Now Cursor can route part of the work to Composer 2, even when I did not select Composer 2. Calling Max Mode the only workaround means users are being charged extra to undo a limitation Cursor introduced.

I should not have to pay more just to prevent Cursor from using a model I explicitly do not want. “Don’t use Composer on my code” should be a basic preference, not a premium workaround.

At minimum, Cursor should provide a hard setting:

Never use Composer or Composer Fast unless explicitly selected.

Until that exists, legacy users are left with worse control, less predictable model routing, and a more expensive path to get back behavior they effectively had before.