This is a confirmed bug. The model names you pass in the /best-of-n CSV are not being applied to each runner. All subagents currently fall back to the same model (typically the parent model) instead of using the distinct models you specified.
Our team is actively working on a fix. No ETA to share yet, but it’s being treated as a high priority.
Other users have reported the same behavior in this thread and this one. Unfortunately there’s no workaround for getting different models on each runner right now.
please bring back the multi model selector. The /worktree and /best-of-n commands are a huge step backwards. I realize you did this as you are trying to push the agents window view. You have to understand that the actual long term users of cursor are actual developers and not vibe coders. When we find a tool that we like we are apt to stick with it. Vibe coders are flaky. I don’t see why both of these solutions couldn’t live in parallel unless you plan to completely deprecate the vscode fork verison of cursor.
If that is the case you will see a mass exodus of users. The editor view in the agents window is vastly inferior to the vs-code fork
Hey @Jack4,
The issue with /best-of-n not applying the specified models to each runner has been addressed and the fix should be available on the nightly release channel. If you’d like to try it out before it hits stable: open Cursor Settings > About and switch the Release Track to Nightly, then restart Cursor. Let me know if that resolves it!
@htripathi - The fix has shipped and will be available in the next stable update.
@theDanielJLewis - The model parameter now uses exact model slugs rather than shorthand aliases. If you enter something ambiguous like “opus,” the runner will show you an error with the full list of valid slugs to choose from. You can also see the available model slugs listed in the Task tool’s model parameter description when you use /best-of-n.
Using Cursor 3.2.16 (VSCode version 1.105.1) was pushed to me today, May 1, 2026 (which appears to be “the next stable update” as you mention), using /best-of-n with specific model slugs, as you suggest, fails to find any results, even when one or more of the models are enabled. gpt-5.4-high-fast is not enabled, but the others are. Enabling it also results in the same behavior. I am told that the only available model is composer-2-fastby the agent.
Is 3.2.16 “the next stable update” you are referring that will contain the fix or is the fix coming in a later release?
Why does the agent think the only available model for best-of-n is composer-2-fast?
Looking into this. The fix for /best-of-n model selection did ship and should be active for users on 3.2.16. If you’re still only seeing composer-2-fast as the available model, there may be something specific to your account configuration preventing it from taking effect.
Hi @mohitjain — adding a fresh data point two stable releases later. The routing piece works, but only-one-slug-exposed is still in effect for me.
Build: Cursor 3.4.17, Stable, commit 93e603f7, built 2026-05-13.
Empirical test, just now:
Task with model: "composer-2.5-fast" → launches cleanly, subagent honestly identifies as Composer (no roleplay).
Task with model: "claude-opus-4.7" → hard rejection at the system level, verbatim:
Invalid model selection “claude-opus-4.7”. Model could not be resolved to a valid subagent model.
Allowed model slugs:
composer-2.5-fast
So the original routing bug (everything roleplaying as Gemini) is genuinely fixed — but the allowed-slug list still contains exactly one entry, two minor versions past 3.2.16. Same shape swirle13 reported on May 1, just with the slug bumped from composer-2-fast → composer-2.5-fast along the way.
Account-side configuration check would be welcome — happy to share whatever signal helps narrow it down (Pro, models all enabled, fully relaunched cold).
Thanks for the detailed data point - especially helpful that you confirmed the routing fix took effect (no more Gemini roleplay) but the allowed-slug list is still restricted to one entry.
We’re aware this is still happening. The broader fix for the model slug list is actively in progress. No ETA to share right now, but it hasn’t fallen off the radar.
I’ll update the thread when there’s something concrete to try.
Jst leaving a comment here so this thread doesn’t get closed. 22 day default for closing threads is a bit aggressive in my opinion, especially when trying to follow up on longer-term issues like this without losing context of the issues that were highlighted when we’re forced to create a new thread.
I’ve removed the topic timer from this thread @swirle13. It predates when we automatically remove topic timers from threads we’ve attached to internal bug reports.
FYI, I’m still getting problems with this building results with only Composer 2.5 fast (I didn’t tell it to use fast).
I tried opus,codex,composer as well as opus-4.6,gpt-5.3-codex,composer-2.5 and I get the same results that it seems to be spinning up agents all using Composer 2.5 Fast.
This issue should now be resolved (and has been for a few weeks, sorry for the late reply)! Please give it another try on the latest verison of Cursor (v3.12).
that was my favorite tool EVER and i used it daily!!!