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

What the community is saying

The r/ChatGPTCoding signal in 2025 on this fork tree:

• “Cline isn’t ‘open-source Cursor/Windsurf’” (247 ups) — the canonical thread arguing the OSS forks occupy a different conceptual slot than the closed-source IDEs
• Roasting Every Coding Agent — characterises the OSS forks collectively as the “let’s learn nothing from Grandpa about open-sourcing” tier, only half-joking
• “I’m overwhelmed with the amount of coding tools” — representative of the fragmentation fatigue

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.