Feature Request: Recursive Subagents, CLI Support, and Flexible Model Selection for Task Tool

Feature request for product/service

AI Models

Describe the request

Feature Request: Recursive Subagents, CLI Support, and Flexible Model Selection for Task Tool

Category: Feature Requests


Context

Following up on Subagent configured model not honored and related threads. The current subagent system has significant limitations that restrict advanced agentic workflows. I’d like to propose three improvements.

1. Multi-Level Recursive Subagents with Total Concurrency Control

Current behavior: Subagents cannot spawn their own subagents. The hierarchy is flat — only one level deep.

Proposed behavior: Allow subagents to recursively launch child subagents (N levels deep), with a configurable total concurrency limit across all levels to prevent resource exhaustion.

Why this matters: Long-running agents suffer from context rot — as context accumulates, reasoning quality degrades. When a subagent faces a complex, relatively independent sub-problem, it should be able to spawn a child agent with a clean context window. However, the current design does not support recursive invocation — once a model is running inside a subagent, it completely loses the ability to spawn child processes for context reset. The very capability that the parent agent uses to delegate work is stripped away at the subagent level. Recursive subagents with a total concurrency cap would fix this asymmetry while keeping resource usage safe and predictable.

2. Cursor CLI Support for Subagent Capability

Current behavior: The Cursor CLI (cursor command) does not support launching subagents via the Task tool.

Proposed behavior: Bring full subagent/Task tool support to the Cursor CLI, so that automated and scripted workflows can leverage the same multi-agent capabilities available in the IDE.

Why this matters: Many power users run Cursor in headless/CLI mode for CI pipelines, batch processing, and scripted development workflows. Without subagent support in the CLI, these workflows are limited to single-agent execution, missing out on the parallelism and context isolation that subagents provide.

3. Direct Model Selection in the Task Tool

Current behavior: The Task tool’s model parameter only accepts a single enum value: "fast". To use any other model (e.g., Opus, Gemini, GPT), you must define a dedicated subagent_type template — there is no way to specify an arbitrary model ID directly on a general-purpose Task invocation.

Proposed behavior: Expand the model parameter to accept actual model identifiers (e.g., claude-opus-4-5, gemini-3-pro, gpt-5-2) in addition to the existing aliases. This would allow agents to dynamically select the best model for each subtask without requiring a pre-defined subagent template for every model.

Why this matters: Different models have distinct strengths in different scenarios. Today, switching models requires opening a new chat window and manually selecting one — breaking flow and losing context. A far better experience is to let the agent spawn a subagent with a specific model directly within the current conversation. This is also a prerequisite for any serious Agent Swarm architecture, where an orchestrator dynamically routes subtasks to the best-suited model.


Summary

# Feature Core Need
1 Recursive subagents Clean context for complex, independent sub-problems
2 CLI subagent support Parity between IDE and CLI workflows
3 Flexible model selection In-conversation model routing for Agent Swarm

These three features together would significantly improve the power and flexibility of Cursor’s multi-agent system. Happy to discuss implementation details or trade-offs.