Roo Code 4.0 Orchestrator Mode 2026: Subagents Tested

Roo Code’s 4.0 release quietly did something the closed agentic IDEs have been charging for: it turned Orchestrator mode into a genuine multi-subagent system, where a coordinating task spawns scoped children with their own isolated context windows and pulls only the summaries back. It landed the same week Codex and Replit ate the coding-agent news cycle, which is why almost nobody has stress-tested it on a real repository. I spent a week running Roo Code Orchestrator mode against a mid-size TypeScript monorepo — 340 files, a Postgres schema, and three MCP servers wired in — to see whether the delegation model holds up at the handoff. The context isolation is real and it’s the single biggest reason to use it, but the subagent boundaries need more babysitting than the docs suggest.

What’s new in Roo Code Orchestrator mode

Orchestrator started life as Boomerang tasks: a parent task delegates a chunk of work to a child, the child completes it, and the result “boomerangs” back. In earlier versions this was largely a prompting convention layered on the mode system. In Roo Code 4.0 it’s structural. The orchestrator decomposes a request into discrete subtasks, assigns each one a mode (Code, Architect, Debug, Ask, or any custom mode you’ve defined), and launches it as a child task with a fresh context window seeded only by the instructions the parent wrote. The child cannot see the parent’s conversation history. When it finishes, it returns a completion summary, and that summary — not the child’s full transcript — enters the parent’s context.

That last detail is the whole ballgame. The failure mode of long agentic coding sessions is context rot: by turn forty, the model reasons over a window stuffed with stale file reads, abandoned approaches, and tool output from three problems ago. Boomerang tasks cap that. A refactor touching eight files becomes eight children, each seeing one file and one instruction, and the parent accumulates eight paragraphs instead of eighty thousand tokens of noise. In my test repo, a full-context single-task run of the same migration hit roughly 190K tokens before it forgot the naming convention it had established in turn six. The orchestrated version finished the same work with the parent sitting under 30K.

4.0 also tightens the surrounding machinery. Custom modes are now first-class delegation targets — define a mode with a narrow file-glob restriction and the orchestrator respects it, so your “docs” subagent physically cannot write to src/. MCP server access is scoped per mode rather than globally on, so a child task running a database migration gets the Postgres MCP server and nothing else. And because Roo Code is BYO-key, all of this runs on whatever model you already pay for — Claude, Gemini, a local model through Ollama, or a mix, including a cheap model for mechanical subagents and an expensive one for the orchestrator.

Why it matters

• Context isolation is the actual product. Every agentic coding tool is bottlenecked by window pollution. Boomerang tasks are the first widely available fix that doesn’t require you to start a new chat and re-explain the project.
• Per-subagent model routing cuts cost hard. Running the orchestrator on a frontier model and the children on a cheap fast one cut my token spend roughly 60% on mechanical work — renames, test scaffolding, doc updates — with no measurable quality loss.
• It’s free and open source with no vendor lock. This is the strongest open source coding agent answer to closed agentic IDEs. Your keys, your models, your data, and the extension is Apache-licensed in VS Code.
• Mode-scoped permissions make delegation safe. A subagent that can only touch *.md cannot silently break your build. This is the safety story that autonomous multi-file editing has been missing.
• Scoped Roo Code MCP servers reduce tool confusion. Handing a model twelve MCP tools degrades selection accuracy. Giving each child the two tools its job needs measurably improves it.
• It exposes the real skill ceiling: task decomposition. Orchestrator quality tracks almost entirely with how well the parent writes child instructions. That’s a prompt-engineering problem you can get good at, unlike waiting for a vendor’s agent to improve.

How to use Roo Code 4.0 Orchestrator mode today

1. Install or update the extension. From the VS Code command palette, or from the CLI:

   code --install-extension RooVeterinaryInc.roo-cline
   

   Open the Roo Code panel, confirm the version reads 4.x in the settings header, and add your provider key under Providers. Anthropic, OpenAI, OpenRouter, Google, Ollama, and LM Studio all work; Orchestrator requires no specific one.

2. Set per-mode models before anything else. In Settings, expand each mode and assign a model. My working configuration:

   Orchestrator  -> a frontier reasoning model (it only writes plans and summaries)
   Architect     -> same frontier model
   Code          -> a fast mid-tier model
   Debug         -> frontier model (debugging is where cheap models waste your time)
   Ask           -> cheapest available
   

3. Switch to Orchestrator mode and give it a goal, not a procedure. The mode plans the decomposition itself; over-specifying steps collapses it back into a single linear task. A prompt shape that works:

   Goal: migrate all API route handlers in src/api/ from the legacy
   callback style to async/await, keeping behavior identical.
   
   Constraints:
   - One subtask per file. Do not batch files.
   - Each subtask must run the file's existing tests before completing.
   - Do not modify shared middleware in src/api/_middleware/ — if a
     change there seems required, stop and report instead.
   - Return from each subtask: files changed, test result, and any
     behavioral difference you could not avoid.
   
   Start by listing the files you intend to delegate, then wait for my
   approval before spawning subtasks.
   

   That final line matters. Reviewing the decomposition before it spawns twenty children is the cheapest quality control available.

4. Define Roo Code custom modes with file restrictions so subagents can’t stray. Create .roomodes in your project root:

   {
     "customModes": [
       {
         "slug": "test-writer",
         "name": "Test Writer",
         "roleDefinition": "You write and repair tests only. You never modify implementation code. If a test fails because the implementation is wrong, you report it rather than fixing it.",
         "groups": [
           "read",
           ["edit", { "fileRegex": "\\.(test|spec)\\.(ts|tsx|js)$", "description": "Test files only" }],
           "command"
         ]
       },
       {
         "slug": "docs",
         "name": "Docs",
         "roleDefinition": "You update documentation to match code that already exists. You never invent features.",
         "groups": ["read", ["edit", { "fileRegex": "\\.(md|mdx)$", "description": "Markdown only" }]]
       }
     ]
   }
   

   The orchestrator can now delegate to test-writer, and the child is mechanically incapable of editing src/. This is enforcement, not instruction — the edit is rejected at the tool layer.

5. Wire MCP servers and scope them per mode. Project-level config lives in .roo/mcp.json:

   {
     "mcpServers": {
       "postgres": {
         "command": "npx",
         "args": ["-y", "@modelcontextprotocol/server-postgres",
                  "postgresql://localhost/myapp_dev"],
         "alwaysAllow": ["query"]
       },
       "filesystem": {
         "command": "npx",
         "args": ["-y", "@modelcontextprotocol/server-filesystem", "./docs"]
       }
     }
   }
   

   Then disable servers on modes that don’t need them. A Code subagent with database access will eventually decide it needs to inspect the database. Take the tool away and it does the job you asked for.

6. Add project rules so every subagent inherits your conventions without the parent restating them. Put them in .roo/rules/:

   # .roo/rules/01-conventions.md
   - Package manager is pnpm. Never run npm or yarn.
   - All new files use named exports. No default exports.
   - Run `pnpm test --filter <package>` before declaring a subtask complete.
   - If a change requires touching more than 3 files, stop and report.
   

   Rules files load into every task, parent and child. This is the correct place for standards; putting them in the orchestrator prompt means they get lossily paraphrased into each child instruction.

7. Watch the first three handoffs, then let it run. The failure signature is a child that returns a confident summary describing work it didn’t finish. Check the diff, not the summary. If a child overreaches, tighten its mode’s file regex rather than adding more prose to the prompt — constraints beat instructions.

How it compares

Capability	Roo Code 4.0	Cline	Cursor	GitHub Copilot Agent
Multi-subagent delegation	Yes, Orchestrator/Boomerang with isolated child contexts	Plan/Act only, single context	Background agents, limited parent-child scoping	Single agent per task
Per-subagent model routing	Yes, per mode	Plan vs. Act models only	Model per chat, not per subtask	Model selection, no routing
Custom modes with file-level permissions	Yes, regex-enforced	No	Rules only, not enforced	No
MCP support	Yes, scoped per mode	Yes, global	Yes, global	Yes, global
Pricing	Free extension, BYO key	Free extension, BYO key	Subscription plus usage	Subscription
Open source	Yes	Yes	No	No
Best for	Multi-file work you want decomposed and auditable	Focused single-thread edits	Fast in-editor iteration	Repo-native PR workflows

The honest framing: Cursor still wins on raw in-editor speed and polish, and Copilot Agent wins when your workflow is fundamentally “open a PR from an issue.” Roo Code wins when the task is big enough that context management becomes the binding constraint — and it’s the only one of the four where you can inspect and modify the orchestration logic yourself.

What’s next

The obvious next step is parallel subtask execution. Today’s Boomerang tasks run sequentially — the orchestrator spawns a child, waits, absorbs the summary, spawns the next. That’s the right default for correctness, but eight independent file migrations have no reason to serialize. Parallel children with a merge step separate a twenty-minute run from a three-minute one, and it’s the most requested item in the community discussions.

Watch also for better subtask verification. Right now the parent trusts the child’s completion summary, which is exactly the wrong place to extend trust to a language model. A verification pass — a cheap child whose only job is to diff what changed against what was asked — would close the biggest reliability gap in the system. Some users already hand-roll this with a custom “reviewer” mode, and it works well enough that it should be built in.

Longer term, the interesting question is whether mode definitions become portable. A .roomodes file is a genuinely useful artifact — a team’s encoded knowledge about which agent gets which permissions — and there’s no reason it should stay locked to one extension. If a shared format emerges across VS Code AI coding agent tools, the moat around closed agentic IDEs gets a lot shallower, fast.

Frequently Asked Questions

Is Roo Code Orchestrator mode free?

The extension is free and open source. You pay only for model inference through your own API key, or nothing at all if you run local models via Ollama or LM Studio. There is no Roo Code subscription tier.

What’s the difference between Boomerang tasks and Orchestrator mode?

They’re the same mechanism under two names. Boomerang was the original community term for the delegate-and-return pattern; Orchestrator is the shipped mode that implements it. In Roo Code 4.0 the docs and UI use the terms interchangeably.

Do subtasks share context with the parent task?

No, and that’s the point. A child task starts with a fresh context window containing only the instructions the orchestrator wrote for it, plus your project rules files. It returns a completion summary to the parent. Neither can read the other’s full transcript, which keeps long runs from degrading.

How many subtasks can one orchestrator spawn?

There’s no hard cap, but practical quality drops past roughly fifteen to twenty children in a single run because the parent’s accumulated summaries crowd its own window. For larger jobs, split the work into multiple orchestrator runs with a written handoff between them.

Can I use Roo Code Orchestrator mode with local models?

Yes, though be selective. Local models handle mechanical subagent work — renames, boilerplate, test scaffolding — acceptably. The orchestrator itself needs strong reasoning to decompose tasks well, and that’s where a smaller local model noticeably underperforms. A hybrid setup with a frontier orchestrator and local children is the sweet spot.

Does it work outside VS Code?

Roo Code ships as a VS Code extension and works in VS Code-compatible editors such as Cursor and Windsurf. A CLI is in development, but as of 4.0 the orchestrator experience is editor-bound.