Heads up: Roo Code was shut down on May 15, 2026, and its repository is now archived (read-only). I am writing about it anyway, on purpose, because the ideas it introduced did not die with it. They became the standard way agentic coding tools work. The community carried the plugin forward (as Zoo Code), and its closest relatives, Cline and Kilo Code, are alive and well. Read this as a lesson, not a buying guide.

Most software fades away quietly. Roo Code went out differently. It reached three million installs, became one of the most loved AI coding tools on the planet, and then its own creators looked at their success and said, more or less, “we think this entire category is about to be obsolete,” and shut it down to chase something else. That is a wild story on its own. But the reason Roo Code is worth your time is not the dramatic ending. It is one genuinely clever idea it gave the AI living in your code editor, an idea that quietly spread everywhere. Let me teach you that idea, the story around it, and why it matters even now that the tool is gone.

First, where Roo Code came from

To understand Roo Code, you have to meet its family, because it was never a lone invention. It was one branch of a fast-growing family tree, and that tree explains a lot.

It starts with a tool called Cline. In June 2024, just days after a powerful new AI model was released, a developer built a small VS Code extension that could actually do things in your project: edit files, run terminal commands, work through a task step by step, instead of only suggesting text. That was Cline, and it caught fire.

Then something very common in open-source happened. Because Cline was open source, other people copied its code to build their own version with different priorities. That copy is called a fork. Roo Code was a fork of Cline, made by people who wanted faster updates and more features. Later, Roo Code itself got forked into a tool called Kilo Code. Three tools, one bloodline, sharing actual code history.

Cline the original, June 2024 Roo Code forked Cline, 2025 Kilo Code forked Roo, late 2025 each fork copied the one above
The bloodline: Cline, then Roo Code, then Kilo Code. Each one copied the code of the one before it and went its own way. They genuinely share git history, which is why a feature one of them invents tends to show up in the others. This is the quiet engine of open-source progress.

Now, a question you might have, because I had it too. You may have heard that Roo Code “was used in everything.” Let me be precise, because the truth is more interesting than the rumour. Roo Code was not secretly buried inside Cursor or Windsurf. But two things made it feel omnipresent. It was installed three million times, an enormous footprint. And more importantly, its big idea spread far beyond its own code, copied and adapted by tool after tool. Roo did not get embedded in everything. Its ideas did. And here is that idea.

The big idea: give the AI different hats

Picture the problem Roo Code was solving. You have one AI assistant in your editor, and you ask it to do wildly different things. Sometimes you want it to carefully plan a big change without touching a single file. Other times you want it to aggressively write code and run commands. Other times you just want it to answer a question. If you give one assistant unlimited power for all of these, it gets dangerous and unfocused, like a single employee who is allowed to do anything at any time with no job description.

Roo Code’s answer was elegant: give the AI named roles, called modes, and let each mode have its own personality and, crucially, its own set of permissions. Switching modes is like the AI putting on a different hat for a different job. Click through them below and watch how the permissions change. This is the heart of what made Roo special.

Roo Code's modes, the idea that spread across the whole ecosystem. Each mode is the same underlying AI, but wearing a different hat with different powers. Notice how Architect mode literally cannot edit your code files: that restriction is the point, not a limitation. It keeps the planner from going rogue while it is supposed to be just planning.

Why is this such a big deal? Because it solves the trust problem. The scariest thing about an AI agent is that it might do something destructive you did not intend. Modes put guardrails on the AI based on what job it is currently doing. When you are just planning, the AI literally cannot edit your files even if it wanted to. You get the AI’s help with far less of the anxiety. That single design choice, named roles with scoped permissions, is now everywhere in agentic coding tools, and Roo Code is the one that made it famous.

How a mode actually works under the hood

Let me pull back the curtain, because the mechanism is simpler than it sounds and worth understanding. When you pick a mode and give Roo a task, it builds one big instruction sheet, called a system prompt, and sends it to the AI model. That sheet is assembled fresh from a few ingredients.

IngredientWhat it contributes
Role definition"You are an architect who plans but does not edit." The personality of the current mode.
Tool descriptionsThe exact list of tools this mode is allowed to use, and how to call them. Architect's list is short; Code's is long.
RulesSafety and behaviour rules, like asking before doing something risky.
Your custom instructionsAnything you or your team added, such as "always write tests" or "edit only Markdown files."
Workspace contextRelevant facts about your project so the AI is not working blind.
How a mode becomes a prompt. Switching modes mostly changes the first two ingredients: the role and the allowed tools. The AI model is the same; what changes is the job description and the keys it is handed. This is why modes are powerful without needing a different AI for each one.

Once that prompt is built, the agent runs a loop. It reads context, decides on one action, proposes it, waits for your approval, acts, and repeats. The approval step is the seatbelt.

1 readlook at the code and task
2 decidepick one tool to use
3 ask youshow the change, wait for OK
4 actmake the edit or run it
repeatuntil the task is done
The agent loop. Read, decide, ask, act, repeat. Step three is the human-in-the-loop gate that made these tools trustworthy: the agent proposes, you approve. The mode you are in decides which actions are even on the menu at step two.

The cleverest trick: the boomerang

There is one more idea in Roo Code worth showing, because it is genuinely smart and it solves a real headache. What happens when a task is too big for one mode? Roo had a special mode, the Orchestrator, also nicknamed Boomerang, whose whole job was to manage other modes.

Here is the problem it solves. An AI has limited memory. If one agent tries to do a huge, ten-part task, its memory fills up with the details of part one and it gets confused by part ten. The Orchestrator avoids this by acting like a project manager. It breaks the big task into small subtasks and sends each one to a fresh specialist, who works in its own clean memory and reports back only a short summary. The detail stays with the worker; only the result comes back. Like a boomerang, the task is thrown out and returns.

🪃 Orchestrator holds the big plan subtask ↓ subtask ↓ 🏗️ Architect own clean memory 💻 Code own clean memory 🪲 Debug own clean memory each returns only a short summary ↑
Boomerang tasks. The Orchestrator keeps the master plan but does none of the detailed work. It throws each subtask to a specialist mode that works in its own fresh memory, then returns only a tidy summary. This keeps every agent focused and stops the big task from drowning in detail. It is multi-agent teamwork, built from the same modes idea.

The plot twist: it walked away from its own success

So here is the ending I promised. By early 2026, Roo Code had three million installs and was beloved. And the team chose to shut it down.

Their reasoning is the most thought-provoking part of the whole story. They came to believe that the era of AI plugins living inside your code editor is ending. Their bet is that the future of coding agents is not a tool inside your editor at all, but agents running in the cloud that you talk to from places like Slack, working on their own while you do other things. So they ended Roo Code to pour everything into that new bet. Whether they are right is one of the genuinely open questions in software right now.

Jun 2024
Cline is born. The first popular agent that actually edits files and runs commands inside VS Code.
2025
Roo Code forks it and adds the modes idea, custom roles, and diff-based editing. It takes off.
Late 2025
Kilo Code forks Roo, raising funding to combine the best of Cline and Roo into one polished tool.
Early 2026
Roo Code crosses 3 million installs. One of the most used AI coding tools in the world.
May 2026
Roo Code shuts down, betting the company on a cloud-first agent instead. The community forks the plugin to keep it alive.
The short, dramatic life of Roo Code. Notice how each step built on the last, and how the ending was a choice, not a collapse. The team did not fail. They decided the whole category was about to change and jumped early.

What to actually carry away

Roo Code is gone, but you just learned the three ideas that outlived it, and they are the ideas behind almost every serious coding agent today.

First, modes: give one AI different named roles, each with its own scoped permissions, so it is focused and safe instead of an all-powerful loose cannon. Second, the human-in-the-loop agent loop: the agent proposes an action and waits for your approval before doing anything real, which is what makes trusting it possible. Third, orchestration: when a job is too big, a manager agent splits it into clean subtasks handled by specialists, so nobody drowns in detail.

These are not Roo Code trivia. They are the working vocabulary of modern AI coding, and now they are yours. Tools will keep being born, forked, and retired. That churn is normal and even healthy. But the good ideas, like the ones Roo Code popularised, do not retire. They get inherited. The next time you use a coding tool that lets you switch between a planning mode and a building mode, you will know exactly where that came from, and why it was such a quietly brilliant idea.

← Back to blog