We’re excited to introduce /multitask, a new way for Cursor to parallelize agent work with async subagents!
Use /multitask in the Agents Window to have Cursor run async subagents instead of adding each request to the queue. Cursor can also break larger tasks into smaller chunks and assign them to multiple subagents at the same time.
If you already have queued messages, you can ask Cursor to multitask on them instead of waiting for the current run to finish.
/multitask is useful for:
Running several independent requests at once
Speeding up larger tasks that can be split into smaller pieces
Keeping agent work moving while a current run is still in progress
We’d love your feedback!
What kinds of queued tasks are you using /multitask for?
How well does Cursor split larger tasks into useful subagent work?
What would make multitasking easier to control or understand?
If you’ve found a bug, please post it in Bug Reports instead, so we can track and address it properly, but also feel free to drop a link to it in this thread for visibility.
This is really interesting. Is there any mechanism that prevents the async agents from colliding with each other or stepping on each other’s toes with code changes?
Great question. For this initial version (which we consider v0—there’s still a lot of work to do to make parallel agents feel seamless), there’s nothing specific in place. In our tests, agents have done a pretty good job of coordinating their changes and avoiding conflicts. We’re currently working on functionality to further improve this!
In most cases, these subagents just use the same model as the parent agent. There are a few corner cases (BYOK, request-based pricing) where this is not the case.
You can also request what model is used in natural language!
@Colin I’d like to ask for clarification on how BYOK works as an edge case for/multitask.
Specifically, I’m using /multitask through the Cursor GUI with a BYOK model, qwen3.6-plus, which depends on my custom “OpenAI API Key” setting. However, Cursor seems to repeatedly turn off that custom OpenAI-compatible API key. As a result, some /multitask runs fail because the model is no longer available.
In my recent testing, roughly 1 out of 4 /multitask runs failed for this reason.
Is BYOK expected to be supported reliably inside /multitask, or is this currently a known limitation/edge case?
@Colin Yeah, I have seen subagents launch when using a BYOK model in Planning mode. However, I still run into some limitations. For example, with qwen3.6-plus, Cursor sometimes gets stuck in the “Reconnecting” state for no apparent reason. Restarting the Cursor GUI usually resolves it.
Btw, could you clarify what’s being fixed here?
This is a bug that should be fixed in 3.3 (rolling out now).
Specifically, I’m now on version 3.3.16, and I’m glad to report that the OpenAI API Key toggle didn’t get switched off once during a full workday
With that fixed, wonder if you’re still facing an issue here?
Cursor sometimes gets stuck in the “Reconnecting” state for no apparent reason.
Nope, the “Reconneting” thing was actually observed on version 3.3.16, where restarting Cursor GUI and launching into the same workspace resolved this connection issue.
This being said, though, is there a best practice guide on troubleshooting BYOK connection issue, with Cursor GUI (and maybe with the Agent on CLI as well)? @Colin Thanks again!
I haven’t found a good use for this yet. I’ve always found it better to use subagents that are on their own worktrees.
I have the model run them with run_in_background: False so the model waits on them to finish, and I specify to launch them all with the same request, so that they’re done in parallel and it blocks on that request.
Each subagent creates its worktree, receives its prompt, and gets to work. Once all 3 finish, the model that was running it applies the changes from each after reviewing them.
When should I be using this? Is it just an alternative for people who don’t want to use subagents or separate chats w/ worktrees?
Can we add a button or make it automatic that in multitask mode the sub agents will auto split into their own panes. Tracking what’s being done is very hard without that.
Although I did find that multi panel view to be quite buggy (not scrolling properly and not sticking to the bottom of the chat) so that needs work as well before I’d consider this feature regularly useable.
Can a second response of the main agent kick off a new sub-agent which still reuses the context of a previously run sub-agent? (Or in layman’s terms, it would feel like you’re asking that previously finished sub-agent to continue work using a new prompt additional to existing context, instead of creating a new sub-agent with a clean context.)
PS: @Bakhtiyor_Akhatov try to imagine if your task can be split up into independent mini tasks spread out across a team of humans (or minions if you’re Gru), and all those mini-work are integrated back into a single body of large work. If it makes sense for the task at hand, then multitask can be useful.
I found this very useful for working on large tasks without using the whole context window for the same agent. So far this has been great. I am looking forward to future updates on this feature
Multitask is worth it when there are genuinely independent workstreams or when you want the foreground free for follow-up questions while work happens in the background. It’s probably overkill for anything that shares context or is a single coherent task.
