Cline vs Roo vs Kilo Code: the open-source coding-agent fork tree, untangled

In the open-source AI coding world, Cline (originally Claude Dev) became the de facto standard VS Code extension for agentic coding through 2024. By early 2025 the project had spawned two notable forks — Roo Code (more autonomous, more aggressive) and Kilo Code (yet another fork, billionaire-funded as the r/ChatGPTCoding community calls it). All three are alive and shipping. All three look similar at first glance. They optimise differently in practice.

This review is from two months of running all three side by side on the same projects.

What all three share

A VS Code extension that:

• Talks to an LLM via your own API key (Anthropic, OpenAI, OpenRouter, local)
• Reads and edits files in your workspace
• Runs shell commands (with permission)
• Manages a multi-turn conversation alongside your edits
• Has a “plan first, then execute” mode
• Is GPL/Apache/permissive licensed — fully open source

The shared core is meaningful. They’re not just rebrands; they share substantial code lineage but have diverged enough that they’re no longer just renames of each other.

The three diverged philosophies

Cline — the canonical implementation

Cline is the original. It is the most conservative of the three: more “ask before doing” defaults, less aggressive auto-iteration, the philosophy of “the human is always one step away from the next action.”

For engineers who want OSS but don’t want a fully autonomous agent, Cline is the safest choice. The maintainers are slower / more deliberate about feature changes.

Roo Code — the autonomous one

Roo Code forked Cline to make it more autonomous. Less permission-prompting, more aggressive multi-step execution, custom modes, slash commands for common workflows.

A good r/ChatGPTCoding thread frames the difference: Cline is “AI pair programmer,” Roo is closer to “autonomous developer.” Whether that’s a feature or a bug depends on what you want.

Roo also moves faster on feature work — Claude Max integration, Anthropic Computer Use support, MCP server integration. If you want OSS that keeps pace with frontier capabilities, Roo is usually first.

Kilo Code — the experimental edge

Kilo Code is the fork-of-the-fork. It tries things even Roo doesn’t — more aggressive tool use, more flexible model routing, experiments with various agent loop patterns.

Kilo’s niche: engineers who want to push what an OSS agent can do, accept that the experimental edge sometimes means breakage, and value the right-now-ness of seeing new agentic ideas land before the upstream forks adopt them.

How they compare on the dimensions that matter

The single best video on the fork philosophy

Caleb Writes Code’s “Cline vs Roo” (4 min, 15K views, May 2025) is the cleanest distillation of the actual difference between the two forks I have seen anywhere — and the analogy he lands on is the framing every newcomer should hear first. “How much control should users have over the system prompt? It’s sort of like the analogy of automatic versus manual transmission. Cline asserts that people just want a reliable car that gets them from point A to point B, while Roo asserts that people should be given the option to decide exactly when to shift gears and engage the clutch for peak performance.”

His three-axis breakdown — how each tool interacts with your repository, with you, and with the LLM — is the right structure for any honest comparison. On repository interaction the two are nearly identical: both do a breadth-first search of the workspace, both create checkpoints you can revert to. On user interaction the gap appears: Cline runs in plan/act mode (the automatic transmission), Roo introduces “modes” — code, architect, ask, debug, orchestrator, plus custom — which are snapshots of system prompts you can switch between. On LLM interaction Roo gives you parameters Cline does not: temperature adjustment, custom intervals between API calls (useful when you are using rate-limited providers).

His follow-up video “How Cline actually works” (5 min, 18K views, April 2025) is worth watching to understand what is actually happening under the hood when you fire a Cline prompt. The relevant specifics for anyone choosing between the forks: the system prompt Cline sends is “nearly 13,000 tokens” with the full tool catalog and communication rules. The recursion loop creates a checkpoint, loads environment details + system prompt + custom instructions + conversation history, sends that as a context window to the LLM, processes the tool calls the LLM returns, and iterates until done. The context window is dynamically resized — “shrinking and growing it by removing the least relevant information when it starts to get too large.” All three forks inherit this architecture. They diverge mostly on what the system prompt says and how the user interacts with the loop.

Cline’s own “Ideal Setup for Cline” video (4 min, 47K views, May 2025) is the vendor configuration guide and worth a watch for the “three pillars” framing it lands on: Model + Cline Rules + MCP. That maps directly onto how Roo and Kilo users should configure their setups too — pick the right model for the right mode, write rules for the patterns you want enforced, install MCP servers for the integrations you need. The pillars apply regardless of which fork you pick.

What the community is saying

The r/cline and r/RooCode signals in 2025 are denser than r/ChatGPTCoding on this specific question:

“Cline with Qwen 3 Coder - 100% Local” (226 ups, August 2025) was the watershed thread that pulled the local-LLM-curious crowd into the OSS-fork ecosystem. The OP successfully ran Cline against Qwen 3 Coder 30B locally via LM Studio for the first time and reported it actually worked. A top comment confirmed: “I have used Qwen3-Coder-30B-A3B-Instruct with 6 bit MLX in my MacBook Pro M4 Max 128GB laptop using LM Studio and it does ~90 token / sec and it’s super good to be used with Roo Code. Faster than ever and free!” The forks’ BYOK posture is what made this moment possible — Cursor users could not do this without their own routing, but Cline/Roo/Kilo just need the OpenAI-compatible endpoint pointed at LM Studio.

The “Switched from Cursor to Roo Code and I’m not looking back” thread (139 ups, July 2025) is the canonical migration story for the post-Cursor-pricing-crisis converts. A high-trust comment under it: “I as well am a refugee of Cursor, happy to be accepted into this community. Roo is fantastic.” Another: “In my opinion Roo Code is leading agentic coding tool on the market, even better than Claude Code. If the Claude Code had the same rules and mindset something like Roo Code CLI I would never look at different tool.” Reasonable people disagree on whether Roo actually beats Claude Code, but the migration energy in the comments is real.

The most useful integration story is “Claude Code now available in Cline – Any plans for Roo integration?” (105 ups, June 2025), where the question got answered the same day: yes, already in the nightly build, then released to main. This is the speed-of-shipping signal that the fork ecosystem actually delivers on. The forks copy from each other within days, not months — Cline ships Claude Code provider, Roo ships it shortly after, Kilo follows.

The broader r/ChatGPTCoding context — including the “Cline isn’t ‘open-source Cursor/Windsurf’” thread (247 ups) and the Roasting Every Coding Agent piece — frames the forks as occupying a different conceptual slot than the closed-source IDEs. The honest read: the community respects Cline, Roo, and Kilo for being OSS in a space dominated by closed-source. But the recurring complaint is that the fork tree itself dilutes the ecosystem — three near-identical products competing for the same niche means each has less momentum than the unified project would have.

This is a real cost. It also reflects what happens when you have OSS that works — people fork.

Where each fits in a real coding stack

For most engineers in 2025, the answer is none of them as primary:

• Cursor for tab completion + IDE-native AI
• Claude Code for terminal-based agent work
• Cline/Roo/Kilo as a backup OSS option, for engineers who specifically want OSS

The legitimate use cases for picking one of the three as primary:

1. You are in JetBrains, not VS Code → none of Cursor / Windsurf are there, Cline’s JetBrains plugin is a viable option
2. You need OSS for compliance / audit / supply-chain reasons → these are the only credible choice
3. You work on a fully air-gapped / local-only setup → these support Ollama / LM Studio cleanly
4. You want maximum BYOK flexibility → all three are best-in-class here

For our money, Roo Code is the best default among the three. Pace of feature work matches what Cursor / Claude Code are doing, OSS guarantees are real, the autonomous mode is genuinely useful.

If Roo feels too aggressive, fall back to Cline. If you want to experiment, try Kilo for a weekend.

The trajectory

The interesting open question for the rest of 2025: do these three forks reconverge, or does the tree keep branching?

Reconvergence is possible if Anthropic / Microsoft / someone steps in and provides a “blessed” OSS extension. Continued fragmentation is more likely if the current trajectory holds — each fork serves a slightly different audience and has a reason to exist independently.

The community signal in May 2025 leans toward continued fragmentation, with periodic “we should unify” discussions that never quite happen.

For the broader OSS-AI-coding context, see our Aider review and Continue.dev piece. For the closed-source alternatives, Cursor vs Copilot and our Claude Code review.