Roo Code Shut Down in 2026: The Best Alternatives and How to Migrate Your Setup

roo-codeclinekilo-codevscode-extensionopen-sourcelocal-llmmigration

If you opened Roo Code this week and went looking for an update that never came, you are not imagining it. Roo Code — the popular Cline fork that introduced the Architect/Code/Ask/Debug “Modes” system — shut down on May 15, 2026. The team archived the GitHub repository, stopped shipping releases at v3.54.0, and said plainly that it no longer believes IDE extensions are the future of coding.

The extension still launches. That is exactly the trap. A frozen agentic extension keeps working until a model provider changes an API or a tool-call format, and in 2026 that happens roughly monthly. So the real question is not “does Roo Code still run today” — it’s “what do I move to before it breaks.” This piece answers that with verified facts and a concrete migration path.

TL;DR: Roo Code is dead but its DNA lives on. If you want the closest thing to the Roo experience — the same Modes, custom modes, and provider list — move to Kilo Code, which forked both Cline and Roo Code. If you want the most actively maintained, widely trusted option, move to Cline, which is Roo’s own official recommendation. Both are free and open source.

Roo Code (dead)ClineKilo Code
StatusArchived May 15, 2026 (v3.54.0)Actively maintainedActively maintained (GA April 2026)
Best forNobody newTrust + stability + simplest modelRoo refugees who want Modes back
LicenseApache 2.0 (frozen)Apache 2.0Apache 2.0 (ext), MIT (CLI)
ModesCode/Architect/Ask/Debug/OrchestratorPlan + ActArchitect/Coder/Debugger + custom
Cost$0 (but unmaintained)$0 extension, you pay model API$0 extension, $20 free credits to start
Local modelsYes (Ollama)Yes (Ollama)Yes (Ollama)

Honest take: If you were a Roo Code power user living in custom modes, go to Kilo Code — it preserves the mental model you already have. Everyone else should just install Cline and stop thinking about it. Do not keep running the archived Roo Code extension into the second half of 2026.

What actually happened to Roo Code

Roo Code started life as Roo-Cline: a fork of Cline that added a multi-mode system on top of the base agent. Where Cline gives you two states — Plan and Act — Roo Code shipped a library of role-driven modes (Code, Architect, Ask, Debug, Orchestrator) plus community-installable and user-defined custom modes, each with its own system prompt, file-access scope, and tool permissions. That structure earned it a real following: roughly 23,000 GitHub stars and over 3 million installs before the end.

On May 15, 2026, the team shut the whole thing down — the VS Code extension, Roo Code Cloud, and the Roo Code Router — and archived the repository. They committed to refunding unused Cloud and Router balances. The stated reason was not burnout or funding: the team said it does not believe IDE-embedded extensions are where AI coding is heading, and redirected its attention to a new cloud-agent project, roomote.dev.

The final extension build, v3.54.0, is the end of the line. There will be no bug fixes, no model-compatibility updates, and no new features. Roo Code’s own parting advice to extension users was direct: if you want a model-agnostic open-source extension, use Cline.

Does Roo Code still work — and for how long?

Yes, the archived extension still functions today. Archiving a repo is not a kill switch; your local install keeps running against whatever providers you already configured.

The problem is shelf life. Agentic coding extensions are tightly coupled to provider APIs and tool-call formats. When a provider tweaks its function-calling schema, deprecates a model ID, or changes streaming behavior, a maintained extension ships a patch within days. A frozen one just starts failing — silent tool-call loops, “model not found” errors, broken diffs. We have already seen this pattern bite other frozen tools. Treat Roo Code the way you’d treat an unmaintained dependency with a known clock on it: fine for a week, risky for a quarter, negligent for a year.

If you only ever used Roo Code as a chat box pointed at a stable model, you have more runway. If you leaned on agentic file edits, terminal commands, and tool use, migrate now while the migration is a 20-minute task and not an emergency.

Option 1: Cline — the safe default

Cline (formerly Claude Dev) is the project Roo Code itself points to, and the math backs that up. It’s Apache-2.0 open source, passed 1.5 million VS Code Marketplace installs by April 2026, and carries more than 59,000 GitHub stars. It is bring-your-own-key by default: you connect Anthropic, OpenAI, OpenRouter, AWS Bedrock, Google Vertex, Azure, or a local endpoint, and pay the model provider directly. The extension takes no markup.

Cline’s interaction model is simpler than Roo’s. Instead of a mode library, you toggle between two states:

  • Plan mode — Cline explores the codebase, asks clarifying questions, and proposes a strategy without editing files.
  • Act mode — once you approve the plan, Cline executes it: edits files, runs terminal commands, and iterates.

For most developers this is a feature, not a downgrade. The Roo Code Modes system was powerful but had a learning curve; a lot of people never used more than two modes anyway. If your Roo workflow was essentially “plan, then build,” Cline’s Plan/Act maps onto it cleanly with zero configuration.

Where Cline wins decisively is trust and momentum: it’s the most-installed open-source agent in this category, it ships frequently, and its MCP support, checkpointing, and provider list are kept current. We cover its cost behavior in depth in our Cline review and its privacy-first local setup in Cline + Local LLM.

Option 2: Kilo Code — for Roo refugees who want their Modes back

If the Modes system is the specific thing you’ll miss, Kilo Code is the closest landing spot. Kilo Code is unusual in that it forked both Cline and Roo Code, merging their feature sets — so it inherits Roo’s role-driven modes (Architect, Coder, Debugger, plus custom modes) on top of Cline’s agent core. The VS Code extension reached general availability in April 2026, is Apache-2.0 (the CLI is MIT), reports over 1.5 million users, and raised an $8M seed round, which matters here only because it signals the project isn’t about to repeat Roo’s disappearing act.

Kilo’s pitch is breadth: access to 500+ models, bring-your-own-key at zero markup, and several genuinely free paths to get started:

  • $20 in free credits for new users, so you can try models without configuring any API key.
  • Kilo’s own built-in free models.
  • OpenRouter free-tier models — Qwen3, GLM 4.5 Air, DeepSeek R1, Kimi K2 — at no cost.
  • NVIDIA’s API catalog via the OpenAI-compatible provider.
  • Free Codestral autocomplete through Mistral.

For a developer coming off Roo Code’s billing shock — or off the GitHub Copilot usage-based billing change that pushed a lot of people toward free alternatives in the first place — that free-model stack is the realistic zero-cost replacement.

The genuinely free path: OpenRouter free tier or local Ollama

Both Cline and Kilo Code separate the tool (free) from the model (you pay, or you don’t). Two routes get your monthly cost to literal zero.

Route A — OpenRouter free models. Sign up at OpenRouter, grab an API key, and select a :free model variant. This is fastest to set up and needs no GPU, at the cost of rate limits and the privacy trade-off of sending code to a hosted endpoint.

Route B — local models via Ollama. Run the model on your own machine. Nothing leaves your network, there are no token bills, and there are no rate limits — but you need the hardware, and small local models are weaker at long agentic tool-use chains than a frontier API. For what actually fits in 8GB, 16GB, or 24GB of VRAM, see our sister site’s hardware breakdown at runaihome.com’s local model VRAM guide.

Here’s the local wiring for Cline, which is identical in spirit for Kilo Code:

# 1. Pull a capable local coding model
$ ollama pull qwen2.5-coder:14b
pulling manifest
success

# 2. Confirm the Ollama server is up
$ curl http://localhost:11434/api/tags
{"models":[{"name":"qwen2.5-coder:14b", ... }]}

Then in the extension: open the provider settings, choose Ollama as the API provider, set the base URL to http://localhost:11434, and pick qwen2.5-coder:14b from the model list. One real gotcha to watch: local models default to a small context window, and Ollama silently truncates anything past it, which makes the agent “forget” files mid-task. Set the context length explicitly — we document the full fix in Cline + Ollama tool-use loop fix.

How to migrate your Roo Code setup

The migration is mostly about three things: your custom modes, your project rules, and your provider config. None of it is locked inside Roo.

1. Export your custom modes. Roo Code stored project-scoped custom modes in a .roomodes file at your repo root (global modes live in the extension’s settings JSON). Open it and copy the definitions out — each entry has a slug, a name, a roleDefinition (the system prompt), and groups (the allowed tool/file scopes):

# See what custom modes you defined in this project
$ cat .roomodes
customModes:
  - slug: test-writer
    name: Test Writer
    roleDefinition: >-
      You write thorough unit tests and never modify source files.
    groups:
      - read
      - - edit
        - fileRegex: \.(test|spec)\.(ts|js)$

In Kilo Code, recreate these in the custom-modes UI (or paste them into its equivalent config) — because Kilo forked Roo, the mode schema and the role/groups concept carry over almost one-to-one, which is the single biggest reason Roo users land there. In Cline, there’s no direct modes equivalent; fold each mode’s roleDefinition into a Cline rule or a Plan-mode instruction instead.

2. Bring your rules. If you used .roo/rules/ or a .roorules file for project conventions, copy that guidance into the new tool’s rules mechanism — Cline reads .clinerules, Kilo reads its own rules directory. This is plain text; it’s a copy-paste, not a conversion.

3. Re-add your provider. Whatever key you used in Roo (Anthropic, OpenRouter, a local Ollama endpoint) plugs into the new extension’s settings the same way. Your API keys are yours; Roo never held them hostage.

Budget about 20 minutes for a project with a handful of custom modes. The rules and provider steps are trivial; recreating modes is the only part that takes real attention.

A problem you’ll hit, and the fix

The most common post-migration complaint is not “my modes are gone” — it’s “the new agent burns tokens faster than Roo did.” Two things usually cause it. First, Cline and Kilo both checkpoint aggressively and re-read files to stay grounded, which is more context per turn than a stripped-down Roo session. Second, people switch to a more expensive default model during the move without noticing.

The fix is to be deliberate about model tiering instead of pointing everything at a frontier model. Use a cheap, fast model (a free OpenRouter variant, DeepSeek, or a local qwen2.5-coder) for boilerplate, refactors, and test generation, and reserve an expensive model for genuinely hard reasoning. In Kilo this is a per-mode setting; in Cline you switch models per task. That single habit is usually the difference between a $5/day and a $30/day BYOK bill.

Who should pick what

  • You were a casual Roo user (plan, then build): install Cline. It’s the most maintained, most trusted option and the migration is nearly free.
  • You lived in custom modes and Orchestrator: go to Kilo Code. It’s the only option that preserves the Modes mental model you already invested in.
  • You want zero cost and full privacy: either tool plus local Ollama. Check the VRAM guide first so you pick a model your hardware can actually run.
  • You’re still on the archived Roo Code extension: migrate within the next few weeks, not at the end of the year. The clock is ticking on provider compatibility.

The one thing nobody should do is treat Roo Code as a long-term home because “it still works.” It works the way a parked car with the engine running works — fine right now, and not your plan for next quarter.

FAQ

Is Roo Code completely gone? The company shut down all Roo Code products (extension, Cloud, Router) on May 15, 2026 and archived the repository at final version v3.54.0. The extension you already installed still runs, but it receives no updates of any kind.

Will the Roo Code extension stop working? Not on a fixed date — but it degrades over time. As model providers change their APIs and tool-call formats, an unmaintained agentic extension breaks in ways no one will patch. Expect a useful life measured in weeks to a few months, not years.

What’s the closest replacement to Roo Code? Kilo Code, because it forked both Cline and Roo Code and kept the Modes system. If you don’t specifically need modes, Cline is the simpler, more widely used choice — and it’s Roo’s own recommendation.

Can I move my custom modes over? Yes. Copy your .roomodes definitions into Kilo Code’s custom-modes config (the schema is nearly identical). For Cline, translate each mode’s role definition into a Cline rule or Plan-mode prompt, since Cline doesn’t have a one-to-one modes feature.

Why did Roo Code shut down if it had 3 million installs? The team said it no longer believes IDE extensions are the future of AI coding and pivoted to a cloud-agent project, roomote.dev. It wasn’t a popularity or funding failure — it was a strategic bet against the extension model itself.

Are Cline and Kilo Code actually free? The extensions are free and open source (Apache 2.0). You pay only for model usage, and that can be $0 if you use OpenRouter free-tier models, Kilo’s built-in free models, or a local model via Ollama.

Sources

Last updated June 24, 2026. Roo Code’s shutdown, version numbers, and the licensing and free-tier details for Cline and Kilo Code were verified against the sources above on this date. Tool pricing and features change frequently; verify current state before relying on it.

Was this article helpful?