Roo Code（AI IDE Platform Market Research）

1. Introduction

Roo Code is an open-source AI coding agent built as a VS Code extension, forked from Cline in late 2024 under the name Roo Cline, and renamed to Roo Code in January 2025. Its core differentiation is not model integration but returning Harness's L3 orchestration control layer to user configuration: through a customizable "Modes" system, it turns what was originally a single fixed agent loop into a set of switchable roles with different roles, permissions, and prompts, and then orchestrates these roles into multi-stage workflows via the "Boomerang Tasks" mechanism.

In the taxonomy of AI IDE schools, Roo Code and its parent project Cline both belong to the "open-source human-in-the-loop" branch: local execution, bring-your-own-key (BYOK), per-step approval, and the human as the final gate. This group of documents studies the two as twins alongside Cline (see 09-cline.md): Cline uses the two fixed Plan / Act stages to answer "think before acting," while Roo Code uses an open mode definition system to answer "who does it, and what are they allowed to do." This difference makes Roo Code the best sample for observing the design orientation of a "user-configurable orchestration layer."

1.1. Developer and Product History

It should be noted that for an open-source project, a "company shutdown" does not equal "project death"—the repository under the Apache 2.0 license, Marketplace installs, and community forks (such as subsequent forks like Kilo Code) can continue to exist independently. But for enterprise evaluators, the disappearance of the commercial entity means the continuity of cloud services, SLAs, and security-response channels must be reassessed, a point elaborated in section 7.3.

1.2. Positioning and Latest Version

Roo Code is positioned as a structured in-VS-Code agent workflow platform: it does not require users to switch editors, but layers a customizable multi-role agent system into the existing VS Code environment. Compared with Cursor (an entire IDE), Roo Code is "adding an orchestratable agent team to an existing editor"; compared with Cline, Roo Code makes this orchestration a first-class citizen rather than a fixed process.

The latest version number is fast-moving information; at the time of writing, third-party sources indicated it was in the v3.5x series (still maintaining a high-frequency release cadence around February 2026). A verifiable current version number could not be obtained from the official release page, recorded as [To be filled].

1.3. Pricing and Licensing

2. Glossary

3. Feature Overview

3.1. Mode System

Five built-in modes make up Roo Code's default role division (source: the official Using Modes documentation):

There are four ways to switch modes: a dropdown menu, slash commands (`/architect`, `/ask`, `/debug`, `/code`, `/orchestrator`), cycling through modes via a keyboard shortcut, and the agent suggesting a switch within a conversation. Each mode is bound to its own sticky model, enabling cost optimization of "routing by task type to differently priced models" without adding manual operations.

Custom modes further open up this mechanism: teams can define a "tester that can only change test files" or a "documenter that can only write docs," using file-path regexes to hard-constrain their edit scope and distributing the definitions with the repository. A mode defined in the project-level `.roomodes` with the same name overrides the built-in mode, letting teams standardize AI behavior without changing product configuration.

3.2. Task Execution and Tool Capabilities

3.3. Cloud and Collaboration Capabilities

Roo Code Cloud extends some capabilities from local to cloud (third-party figure): automated GitHub PR review, Slack and Linear integrations, cloud agent tasks, and token usage analysis. In addition, a third-party source mentions a "review step"-type feature (Booster mode, appending a dedicated review after the output), which has not been confirmed by official documentation.

4. Platform Architecture

图 4-1｜Roo Code 平台架构：用户可控本地栈中的 Harness 六层

数据来源：基于本文分析绘制的示意图。

The key engineering implication of this architecture is that Roo Code puts all of Harness's six layers of capability into a user-controllable local stack. Context is assembled locally, tools execute locally, models connect directly to the user's own keys, and configuration is versioned with the repository—at the cost that organization-level L5 / L6 capabilities (audit, policy distribution, centralized observation) are not handled by the platform and must be built by the team (see sections 5.5 and 5.6).

5. Harness Design

5.1. L1 Context Engineering Layer

Roo Code's L1 is composed of four mechanisms:

1. Modes as a context framework. The system prompt injected with each request is determined by the current mode's role definition plus mode-specific instructions. Subtasks dispatched by the Orchestrator run in independent contexts and only return a summary—this is a structured context isolation: implementation details do not enter the parent session, and the parent session retains the task decomposition and acceptance status. This is more proactive than relying purely on compaction: context is not compressed away, but simply never enters the wrong window from the start.
2. Rules files in the repository. The `.roo/rules-{mode-slug}/` directory and the `.roorules-{mode-slug}` single file let "conventions for architects" and "conventions for roles writing code" be maintained separately, with rules taking effect selectively per mode rather than being injected in full.
3. Context mentions. The `@` system (files, folders, `@problems` diagnostics) provides an explicit context-selection entry point, handing part of the decision over "what the model sees" to the user.
4. No automatic whole-repo indexing. Unlike Cursor and Windsurf, Roo Code does not include vector indexing or semantic retrieval built in; cross-repo understanding relies on a combination of reading files + MCP + context mentions. This is a lower-noise choice in small repositories, but a clear shortcoming in large ones.

5.2. L2 Tools and Execution Layer

The security model of tool execution centers on "per-step approval + tiered auto-approval":

• By default, every file write, command execution, and browser operation requires user approval, and the approval UI shows the full diff and command content.
• Auto-approval can be enabled separately by operation category (read, write, command, browser, MCP), granular to the category rather than to individual commands; the official FAQ directly warns to be "extremely cautious" about command auto-approval.
• MCP connects external systems in a protocol-based way, and tool exposure is constrained by the current mode's `mcp` permission group.
• No OS-level sandbox (compare Codex CLI's Seatbelt / Landlock, see 05-codex-cli.md). Roo Code's guardrails are a combination of "human + checkpoints + git," not process isolation.

Known weakness: mode permissions control what tools the agent "requests," but once a command is approved it executes with full authority in the user's terminal, and the command's internal behavior (destructive operations nested inside scripts) is not constrained by mode permissions. This is the shared boundary of all tools that rely on approval rather than sandboxing, which this group of documents has analyzed structurally in documents 02 and 05.

5.3. L3 Orchestration and Control Layer

This is the most recognizable layer of Roo Code across the platforms in this group:

1. Single loop: within each mode is a standard agent loop of "request → tool call → observe result → iterate."
2. Mode orchestration (Boomerang): the Orchestrator dispatches subtasks via `new_task`, subtask summaries are returned on completion, and the Orchestrator plans the next step accordingly; by default each subtask handoff requires human approval, and it can be configured to be automatic in exchange for higher autonomy. A typical chain: Architect produces a plan → Code implements → Debug troubleshoots → Code fixes → back to the Orchestrator for acceptance.
3. User-configurable orchestration: unlike Cline's fixed two-stage Plan / Act, Roo Code's orchestration topology is defined by the user—adding a "tester" mode and writing the Orchestrator's dispatch rules into its instructions can change the workflow itself. This is equivalent to turning L3 from a product preset into a versioned asset inside the repository.

From an engineering standpoint, mode orchestration should be treated as a lightweight workflow engine: it lacks heavyweight semantics such as DAG, retries, and timeouts, but wins on zero infrastructure, distribution with the repository, and readability/auditability. It suits workflows with "stage outputs" as nodes (spec → implementation → review), but not long pipelines requiring programmatic guarantees—the latter should be handed to CI or terminal-type tools.

5.4. L4 Memory and State Layer

There is no official automatic memory mechanism (compare Claude Code's auto memory, see 02-claude-code.md); cross-session project knowledge relies mainly on the discipline of "writing it into rules files."

5.5. L5 Evaluation and Observability Layer

• Token usage tracking: the local session displays token consumption; Roo Code Cloud provides usage analysis (third-party figure).
• Checkpoints + git diff: the rollback mechanism itself constitutes the most basic "mechanical criterion"—whether a change is good or bad is judged by tests and diff review, but this is the user's discipline, not the product's evaluation layer.
• No built-in eval / regression suite / trace system: no official eval or trace capability was found, recorded as "no result." In its open-source form, teams typically build L5 on test frameworks and CI, and Roo Code is only responsible for bringing changes into a state that can be judged by those mechanisms.

5.6. L6 Governance and Security Layer

Roo Code's L6 is isomorphic to Cline's—a minimal realization of "human approval as governance":

Structural assessment: Roo Code hands the lower bound of L6 to the human gate of "default approval" and the upper bound to the auditability of open-source code. For high-trust small teams of 3–10 people, this minimal governance is sufficient; for organizations needing RBAC, audit export, and a responsible vendor entity, it is insufficient—a sharp contrast with the enterprise closed loop of GitHub Copilot in document 03.

5.7. Harness Differences from Cline

In one sentence: Cline turns "think before acting" into a product process, while Roo Code turns "who does it and what they are allowed to do" into a user asset. The former is more convenient for individuals; the latter has stronger orchestration expressiveness for teams.

5.8. Summary of the Six Layers

6. Real-World Use Cases

Note: this section truthfully describes data availability. No enterprise adoption cases with quantified metrics officially published by Roo Code were found, so this section cites no unverified quantitative effect figures.

Only two kinds of citable, solid information exist:

1. Scale signals: VS Code Marketplace installs exceed 3 million, GitHub stars approximately 24,000, and 300+ contributors; multiple third-party sources state that developers at companies such as Apple, Microsoft, Amazon, and ByteDance have mentioned the tool in beta testing or usage surveys (all weak signals).
2. Reproducible workflow patterns (based on capability combinations described in official documentation, not quantified cases):

• Multi-stage feature development: the Orchestrator decomposes the requirements → Architect produces the design document (can only write Markdown, naturally preventing unauthorized code writing) → Code implements per the spec → Debug locates failing tests → the Orchestrator aggregates acceptance.
• Standardizing team behavior: the project-root `.roomodes` defines team-specific roles that override built-in modes (e.g., a "migration assistant only allowed to change `src/legacy/`"), distributed with the repository, so new members get consistent agent behavior upon cloning.
• Cost-tiered routing: Architect / Orchestrator are bound to high-capability models, Code is bound to a cost-effective model, using the sticky model to automatically shift gears when switching modes.

7. Summary

7.1. Strengths

1. User sovereignty over L3 orchestration: the mode system turns roles, permissions, and prompts into versionable assets inside the repository, making it the design with the strongest expressiveness for "team-customized agent workflows" across this group of platforms.
2. Boomerang's context isolation: independent subtask windows + summary return structurally alleviate long-task context rot, more proactively than relying purely on compaction.
3. Truly open source + no model markup: Apache 2.0, BYOK, local execution, with the lowest vendor-lock-in risk.
4. Fine-grained permission declaration: mode × tool group × path regex writes "what this role must not touch" into configuration rather than verbal convention.

7.2. Limitations

1. No whole-repo indexing or sandbox: neither L1's retrieval depth nor L2's process isolation matches the leading terminal-type and IDE-type products.
2. L5 / L6 must be self-built: with no evaluation system or organization-level governance, scaling teams need to add test gates and audit chains.
3. Risk of the commercial entity ceasing operations: the original team ceased operations in April 2026 (third-party figure), so the continuity of cloud services and compliance commitments requires renewed due diligence; being open source keeps the code alive without doubt, but "someone is responsible" and "the code exists" are two different things.
4. High token consumption: multi-mode and subtask chains naturally consume more tokens than a single loop, widely noted in third-party reviews ().

7.3. Applicability Boundary and Selection Advice

Selection advice: evaluate Roo Code together with Cline, using "how much orchestration expressiveness the team needs" as the criterion—if only Plan / Act is needed, choose Cline (larger community, simpler mental model); if permissions and context need to be split by role, choose Roo Code. If the goal is spec-first engineered delivery, then both are only transitional, and you should look at the 12 Kiro documents.

Information Gap Declaration

1. Current version number and release cadence: no verifiable version could be obtained from the official release page, recorded as [To be filled]; third-party figures indicate the v3.5x series.
2. Original development team ceased operations in 2026-04, Roo Code Router closed in 2026-05, and Roomote launched: all from third-party sources, not confirmed by first-party official sources.
3. Roo Code Cloud tier pricing and cloud agent hourly rates: third-party figures.
4. SOC 2 Type 2 compliance statement: third-party figure.
5. Booster mode (review step): not confirmed by official documentation.
6. Enterprise quantified adoption cases: no first-party quantitative data officially published was found, and no marketing-figure numbers were adopted.
7. Implementation details of Checkpoints (storage location and limits of shadow git): inferred from official feature descriptions; implementation details were not verified item by item.

8. References

1. Roo Code official documentation · Using Modes — RooCodeInc, 2026. https://docs.roocode.com/basic-usage/using-modes
2. Roo Code official documentation · FAQ — RooCodeInc, 2026. https://docs.roocode.com/faq
3. Roo Code official documentation site — RooCodeInc, 2026. https://docs.roocode.com/
4. Roo Code GitHub repository (Apache 2.0) — RooCodeInc, 2024–2026. https://github.com/RooCodeInc/Roo-Code
5. Roo Code official website — RooCodeInc, 2026. https://roocode.com/
6. Roo Code — VS Code Marketplace — RooVeterinaryInc, 2024–2026. https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline
7. Roo Code topic entry — AI Wiki (third-party), 2026. https://aiwiki.ai/wiki/roo_code
8. Roo Code vs Cline: AI Coding Extensions Battle — Serenities AI (third-party), 2026. https://serenitiesai.com/articles/roo-code-vs-cline-ai-coding-2026
9. Roo Code Review 2026 — Vibe Coding (third-party), 2026. https://vibecoding.app/blog/roo-code-review
10. Introducing the Model Context Protocol — Anthropic, 2024-11-25. https://www.anthropic.com/news/model-context-protocol
11. Terminal-Bench official site (model + Harness system evaluation scope) — Stanford / Laude Institute, 2025–2026. https://www.tbench.ai/
12. 2025 Stack Overflow Developer Survey — Stack Overflow, 2025-07-30. https://survey.stackoverflow.co/2025/