Official nesting depth for subagents — how deep is reliable in current Cursor?

Support Help
, ,
1

Hi Cursor team,

I’m designing multi-agent workflows and want to confirm the intended and reliable nesting depth for subagents in the latest Cursor (IDE + CLI if they differ).

What docs say today
Subagents FAQ states that since Cursor 2.5, nesting is allowed with a hard cap: the main agent and its direct subagents can launch children, but a subagent launched by another subagent cannot launch further ones (effectively max depth = 2 below the main agent).

What we’re seeing / hearing
Forum threads suggest nesting is fragile in practice, e.g.:

  • Subagent delegation not working in Cursor IDE 3 — middle orchestrators often don’t delegate
  • System Prompt breaking reliable Subagent Spawning — “do not spawn additional subagents” reminder conflicts with parent instructions
  • Nested subagent could not be spawned in cli — CLI vs IDE differences
  • Nested subagents don’t inherit model in MAX mode — L2+ model inheritance issues

Some changelog wording also sounded more open-ended (“and so on”) than the two-level FAQ rule.

Questions

  1. In the latest Cursor, what nesting depth is supported by design (main → L1 → L2 → …)? Has that changed since 2.5 / early 3.x?
  2. At which depth is nesting considered reliable in production (vs “possible but flaky”)?
  3. Does reliability differ between IDE, CLI, and Cloud Agents?
  4. Is the system reminder that discourages child spawning intentional long-term, or something you’re planning to relax when the parent explicitly requests nested Task launches?
  5. For deep pipelines, is the recommended pattern still flat dispatch from the main agent (main → specialists) rather than a middle orchestrator?

Thanks!

6

Hey there! The Subagents FAQ is current: supported depth is main → L1 → L2. An L2 subagent can’t spawn further.

The cap itself is solid. What can feel flaky is an L1 orchestrator hesitating to delegate - put explicit “you MUST spawn child subagents via the Task tool” in that subagent’s prompt. Prefer a general-purpose/custom middle agent; built-ins like Explore/Shell/Browser don’t spawn further.

IDE and current CLI match that two-level rule. Cloud Agents today effectively support one level from the main agent; deeper nesting there isn’t available yet, and our team is looking into it.

The “don’t spawn extra subagents” reminder is intentional (with a carve-out when the user/parent instructions ask). Flat main → specialists is still the most reliable pattern; one middle orchestrator works if its prompt explicitly requires Task launches.

7

Thanks for the quick reply!