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!
