Kilo Code Teardown — Open-Source VS Code Extension Wedge Against Cursor's $9B IDE Fork

TL;DR + Quick Facts

Kilo Code is an open-source AI coding agent that ships as a VS Code extension. It is the third generation of a fork lineage: Cline (the original autonomous agent) was forked into Roo Code (community-driven, faster cadence), which was then forked into Kilo Code (merged best-of from both, plus its own roadmap). The whole stack is MIT/Apache licensed, the source lives on GitHub, the binary is a one-click install from the VS Code Marketplace, and the only thing the company actually charges for is a token markup if you route your model calls through their proxy. Bring your own Anthropic, OpenAI, OpenRouter, or local Ollama key and the product is free forever.

That structural choice — extension instead of IDE fork, BYOK instead of seat license — is what makes Kilo interesting as a business teardown. It is staring directly at Cursor's roughly nine-billion-dollar valuation and saying: we do not need to fork the editor. We do not need to retrain developers on new keybindings. We do not need to charge twenty dollars a month. We ride VS Code, we collect a thin margin on inference, and we let the open-source flywheel do distribution.

Quick Facts

Field	Value
Founded	2025 (fork of Roo Code, which forked Cline in late 2024)
Pricing model	BYOK free, optional managed token routing with markup
Estimated MRR	~$50K (token pass-through margin, indie scale)
License	Apache 2.0
Distribution	VS Code Marketplace, JetBrains Marketplace, GitHub releases
Team size	Estimated 3-6, partly community contributors
Funding	Bootstrapped / community-funded (no announced VC round)
Direct competitors	Cursor, Windsurf, Cline, Roo Code, Aider, Claude Code, Continue.dev
Defensibility	Low individually, moderate as part of the open-source coalition

The teardown that follows is less about Kilo as a product and more about Kilo as a strategic position. If you are an indie builder looking at the AI coding space and concluding it is too crowded to enter, Kilo is the exact case study that says: the wedge is not features, the wedge is distribution shape.

The Cline → Roo → Kilo Fork Genealogy

To understand Kilo you have to understand what it inherited and what it left behind. The lineage matters because each fork happened for a specific reason, and those reasons map directly onto strategic decisions Kilo's founders made about what kind of company they want to be.

Cline (originally Claude Dev) was the first widely adopted autonomous coding agent that ran inside VS Code. Saoud Rizwan released it in mid-2024 as a personal project. The key insight at the time was that Claude 3.5 Sonnet was suddenly good enough to drive a real agent loop — read file, write file, run command, observe output, iterate — and that loop deserved a UI that lived in the editor instead of a separate chat window. Cline did one thing well: it gave Claude a hand inside your project. By late 2024 it had hundreds of thousands of installs and a passionate user base, but development was deliberately measured. Saoud rejected pull requests that did not match his taste, kept the surface area small, and resisted the community's push toward more configurability.

Roo Code (originally Roo Cline) was a fork that explicitly rejected that pace. The Roo team — anchored around developers who wanted faster iteration, more modes, more model providers, MCP support landed on day one — branched off Cline in late 2024 and started shipping features weekly instead of monthly. Roo added custom modes (Architect, Code, Debug, Ask), parallel browser actions, computer use, image input, and a settings surface that Cline's maintainer had explicitly chosen not to build. Within months Roo had eclipsed Cline in star growth and install velocity, demonstrating one of the oldest patterns in open source: when the original project's roadmap diverges from what the loudest users want, a fork that accelerates feature delivery will win the contributor pool even if the original keeps the brand.

Kilo Code is the fork-of-the-fork. The Kilo founders looked at the Cline-Roo split and made a different bet: they would not pick a side, they would merge the best of both and add their own opinions on top. Kilo pulls upstream from both Cline and Roo continuously, which means features that ship in either parent project land in Kilo within days. On top of that they added their own differentiators — a more polished onboarding, a tighter integration with the OpenRouter and Requesty proxies, a profile system that lets you swap between model+prompt combos with one click, and a managed billing layer for users who do not want to maintain their own API keys.

This three-step fork dynamic is something the broader AI tools market keeps under-discussing, and it matters for anyone considering a build in this space. The lesson is not that forks always win. The lesson is that in a permissively licensed, fast-moving category, the strategic question is not "can I out-engineer the leader" — it is "can I out-cadence them, and if I can, will the contributor pool follow." Roo answered yes to both for Cline. Kilo is making the bet that the same dynamic compounds: by being the most welcoming fork, the most aggressive merger of upstream changes, and the friendliest to enterprise users who want a single throat to choke, Kilo can be the version that consolidates the lineage's mindshare.

There is a risk inside that bet that needs naming. The Cline-Roo-Kilo chain is a coalition that lives or dies on Anthropic's pricing and Claude's continuing edge in tool use. If Anthropic changes its pricing model, locks down certain agentic patterns, or releases a first-party VS Code extension that obsoletes the entire third-party agent layer, the whole lineage gets squeezed simultaneously. Claude Code — Anthropic's own CLI agent, released in early 2025 — is already a partial version of that scenario. The Cline-Roo-Kilo lineage is functionally a distribution layer on top of Anthropic's API, and distribution layers on top of APIs get disintermediated when the API vendor decides to ship the application. Holding that risk does not invalidate the strategy, but it shapes the timing window. Anyone copying this playbook in 2026 has a meaningfully shorter runway than the original Cline team had in 2024.

What Kilo Does Differently from Cursor

The natural question is why Kilo, or any of its lineage, has a right to exist when Cursor raised roughly nine hundred million dollars at a nine-billion valuation and Windsurf was acquired by Cognition for a reported three billion. The answer hinges on a single architectural choice: Kilo is a VS Code extension, Cursor is a fork of VS Code.

A fork means Cursor ships its own editor binary. They take the open-source VS Code codebase, patch it heavily, rebuild it, and distribute it as a separate application. Every VS Code update has to be cherry-picked or merged. Every VS Code extension has to be re-verified against the forked runtime. Every developer onboarding involves convincing someone to install a new IDE and migrate their settings, keybindings, theme, and extension list. The fork model gives Cursor the freedom to change anything — they can rewrite the file tree, redesign the command palette, embed inline AI directly in the editor surface — but it costs them an entire platform engineering team and a one-IDE-per-developer ceiling.

An extension is the opposite trade. Kilo cannot change the file tree. It cannot embed inline ghost text the way Cursor can, because that requires editor APIs that VS Code does not expose to extensions. It is constrained to the panel that VS Code allocates to extensions, plus the inline decorations and code actions that the extension API permits. In exchange, Kilo gets things Cursor will never have: it installs in three seconds from the marketplace, it coexists with every other VS Code extension the developer already loves, it inherits every VS Code update for free, and it gets to ride the JetBrains and Cursor distribution surface too — yes, Kilo is on the JetBrains Marketplace, and yes, Kilo runs inside Cursor itself, because Cursor is downstream of VS Code and inherits the extension API.

That last point is the joke that pays the rent. A developer who loves Cursor's inline ghost text can install Kilo Code inside Cursor and use it for the autonomous-agent loop while keeping Cursor for the inline completion. Kilo is parasitic on Cursor's IDE work without being a competitor to Cursor's tab-completion product. The two coexist on the same machine for many users.

The other major architectural difference is the agent loop topology. Cursor's flagship UX is Composer mode: a chat panel where you describe what you want and the model edits across files. Kilo (and its Cline-Roo lineage) leans harder into multi-agent mode — explicit Architect, Code, Debug, Ask, Orchestrator modes where each mode has its own system prompt, its own model selection, and its own approval policy. The user can pin Claude Opus to Architect mode for planning, Sonnet to Code mode for implementation, Haiku to Debug mode for cheap iteration, and a local Qwen3-Coder model to Ask mode for offline use. That kind of model-per-mode configurability is something Cursor has been moving toward but does not expose with the same explicitness, partly because Cursor's product surface optimizes for the developer who wants one thing to work great rather than the developer who wants every knob.

The model-per-mode pattern matters as a product positioning choice. It says, explicitly, that Kilo is for the developer who has opinions about which model to use when. That is a narrower audience than Cursor's, but a deeper one — those developers tend to be early adopters, vocal on Twitter and Hacker News, and willing to evangelize. The TAM-vs-NPS tradeoff is real, and the Cline-Roo-Kilo lineage has consistently chosen NPS.

Business Model: The Token Pass-Through Markup

Kilo's business model is so thin it almost is not a business model in the traditional sense, and that is exactly what makes it interesting as a teardown.

The product is free. The source is open. If you bring your own Anthropic, OpenAI, OpenRouter, Gemini, or Bedrock key, you pay zero dollars to Kilo and your inference bills go directly to your model provider. This is identical to how Cline and Roo work — the BYOK pattern is essentially the price of admission in the open-source coding-agent category, because nobody will install a closed-billing extension when Cline-the-original is free and identical.

The revenue mechanism is what Kilo (and Roo, separately) layers on top: a managed routing service. You can give Kilo your credit card, the company holds an account with each of the major model providers and with OpenRouter, and Kilo bills you a small markup on the tokens you actually consume. The convenience pitch is that you do not need to manage seven different API keys across seven different providers, you do not need to top up balances on each, and you get unified billing and usage analytics in one dashboard.

The markup is in the single-digit percentages — typically around five percent on inference cost, which is small enough that engineers do not notice it but large enough that, at scale, it produces a real margin. If a heavy user spends two hundred dollars a month on Claude tokens routed through Kilo, the company makes ten dollars from them. That sounds tiny until you stack it across thousands of users, at which point the math becomes a real business: ten thousand heavy users at ten dollars of markup a month is one hundred thousand dollars MRR with effectively zero cost of goods sold beyond the proxy infrastructure itself.

The estimated fifty-thousand MRR for Kilo specifically reflects an earlier point in that growth curve. Roo and Cline both predate Kilo and have captured the larger share of the lineage's user base. Kilo is the newer entrant racing to consolidate the merged audience, and at its current scale the markup revenue is plausibly in the high four to low five figures monthly. Founders shipping similar products should treat the fifty-thousand number as a snapshot of an indie business in its first year, not as a ceiling.

The honest version of this model is that it is not very defensible. Anyone can stand up an OpenRouter proxy and charge a markup on it. The actual moat — to the extent there is one — is that the markup is bundled into a product the user already chose for non-pricing reasons. The user came for the agent, the markup is a convenience tax they accept because manual key management is annoying. The product is the moat, the routing is the meter.

That has an important implication for the build-vs-buy decision an indie founder might face. If you are thinking about cloning this model, the order of operations is: build a great agent first, get distribution, and only then layer the routing markup on top. Building a routing-with-markup product without a hero application attached is a dead path — that is what OpenRouter itself sells, at a smaller markup, and nobody is going to choose your proxy over theirs without a reason. Kilo's reason is the agent. The proxy is downstream of that.

Kilo vs Cline vs Roo vs Cursor vs Windsurf vs Aider vs Claude Code

The AI coding category is now crowded enough that any teardown needs to place the subject inside the full landscape. The following comparison is deliberately opinionated — each entry is rated on the dimensions an indie builder would actually weigh when picking which product to model.

Product	Form Factor	License	Pricing	Strength	Weakness
Kilo Code	VS Code / JetBrains extension	Apache 2.0	BYOK free, ~5% markup on managed routing	Best-of-both fork, multi-agent modes, fastest upstream merge	Smaller install base than parents, newer brand
Cline	VS Code extension	Apache 2.0	BYOK free, no managed billing	First-mover, simplest UX, strongest brand recall	Conservative roadmap, fewer modes, slower cadence
Roo Code	VS Code extension	Apache 2.0	BYOK free, optional managed routing	Most aggressive feature velocity, largest fork community	Less polish than Kilo, settings sprawl
Cursor	VS Code fork (full IDE)	Closed source	$20/mo Pro, $40/mo Business	Inline tab-completion is best in class, Composer mode mature	$9B valuation pressure, IDE migration friction, closed source
Windsurf	VS Code fork (full IDE)	Closed source	$15/mo Pro, free tier available	Cascade flow agent loop is genuinely novel, fast inline	Acquired by Cognition, future direction uncertain
Aider	Terminal CLI	Apache 2.0	BYOK free, no managed billing	Git-native commits, no UI overhead, headless-friendly	No editor integration, learning curve, terminal-only
Claude Code	Terminal CLI + IDE plugins	Anthropic proprietary	$20/mo Pro, $200/mo Max, API metered	Anthropic-native, best-in-class Claude integration	Single-vendor lock, no GPT or local model support
Continue.dev	VS Code extension	Apache 2.0	BYOK free, enterprise tier	Strong enterprise positioning, custom model hosting	Less agentic than Cline lineage, more autocomplete-focused
GitHub Copilot	VS Code / JetBrains / Vim plugin	Closed source	$10/mo individual, $19/mo business	Microsoft distribution, deeply embedded in GitHub	Slower to adopt agent patterns, less configurable

A few observations the table cannot capture in cells alone.

The split between "fork the IDE" and "ship an extension" is the most consequential strategic choice in the category. Cursor and Windsurf chose fork. Cline, Roo, Kilo, Continue, and Copilot chose extension. The fork camp can change the editor itself but pays the platform tax. The extension camp inherits the platform but lives within its API. Both camps have produced billion-dollar outcomes (Cursor, Windsurf-via-Cognition) and indie-scale outcomes (Cline, Roo, Kilo, Aider). It is too early to declare a winner — and probably wrong to frame it as a single winner takes all. There are clearly different developer segments that map to different form factors.

The split between BYOK and bundled pricing is the second most consequential choice. Cursor and Windsurf bundle inference into a subscription, which means they take pricing risk on every token a heavy user consumes — if Claude raises prices or if a single user hammers the agent loop, the bundled-pricing companies absorb the cost. Kilo, Cline, Roo, and Aider pass that risk to the user via BYOK, which is why they can charge nothing or near-nothing for the product itself. The bundled approach is better for casual users who want predictable monthly costs. The BYOK approach is better for heavy users who want to control which models run when and do not want to subsidize lighter users in the same subscription pool.

Claude Code is the wild card. Anthropic launched it in early 2025 as a first-party CLI agent, and it has been quietly eating into the Cline-Roo-Kilo audience among Claude-loyal developers. Anthropic has not (yet) shipped a VS Code extension to directly challenge the lineage, but the strategic possibility is permanently on the table. The lineage's response has been to lean harder into multi-model support — Kilo and Roo both work great with GPT, Gemini, and local models, which positions them as the model-agnostic choice against Anthropic's first-party single-vendor product.

For an indie builder, the table maps to a single question: which adjacent niche is being underserved by all nine of these products? The honest answer is that the broad horizontal AI coding agent is now well covered, and the indie wedge is vertical — security audit agent, legacy COBOL migration agent, Solidity-specific agent, embedded C agent. We will return to this in the Playbook.

Open-Source as Distribution

The Cline-Roo-Kilo lineage is the cleanest contemporary example of open source as a distribution strategy rather than open source as a software philosophy.

Cursor and Windsurf both raised hundreds of millions of dollars and used that capital to buy distribution — paid ads, conference sponsorships, developer relations teams, growth-hacked referral programs, integrations with bootcamp curricula. They have to do this because the IDE-fork form factor requires a heavyweight install and a behavior change from the developer. You cannot trial Cursor on a whim; you commit to it as your primary editor.

Cline did the opposite and got to a comparable user base on a vastly smaller marketing budget. The distribution channels were the VS Code Marketplace's algorithmic surfacing of fast-growing extensions, Hacker News and Reddit threads from delighted early users, Twitter posts from developers showing off agent workflows, and the GitHub stargazer flywheel where each star nudged the project higher in search rankings. Roo continued the same playbook, with the addition of explicit positioning against Cline ("Cline but faster, with more modes"). Kilo continues it again, with positioning that consolidates both parents.

The mechanics of why this works are worth pulling apart, because they generalize to other categories.

First, the VS Code Marketplace itself is a discovery channel that rewards fast growth. Extensions that pick up installs quickly get featured in the editor's recommendation panel, which in turn drives more installs, which compounds. Cline rode that algorithm hard in late 2024. Roo rode it in early 2025. Kilo is riding it now. Anyone copying the playbook in 2026 enters a marketplace where the curve has steepened — getting algorithmic featuring now requires more initial velocity than it did eighteen months ago, because the bar has moved up.

Second, the open-source contributor flywheel is real and underestimated. Cline and Roo both have hundreds of contributors who have submitted code, written documentation, filed detailed bug reports, and evangelized the product in their communities. Each contributor is a distribution node — they tweet about their merged PRs, they recommend the project at meetups, they write blog posts when they get nontrivial features shipped. This is distribution that money cannot easily buy, because it requires the project to actually merge contributions and credit contributors visibly.

Third, the permissively licensed source code itself is a distribution surface. Companies that want to ship their own internal AI coding tools can fork Cline or Roo or Kilo, customize them for their stack, and deploy them inside their org without buying licenses. Some of those companies eventually become customers of the managed routing layer, or they hire the original maintainers as consultants, or they sponsor specific features. The license, in other words, creates a free trial that goes far deeper than a fourteen-day SaaS trial ever could.

The pattern only works if the project is genuinely good and if the maintainers are genuinely responsive. Open source is not a marketing trick; it is a long-term commitment to a community that will turn on you fast if you treat it as one. Cline's maintainer learned this when his refusal to merge community PRs led to the Roo fork. Roo's maintainers, having absorbed that lesson, have been deliberately more inclusive — and Kilo is the next generation of the same logic. The companies that win in this space are the ones that treat the contributor pool as their actual product and the routing markup as the side business.

Why VS Code Extension Beats IDE Fork for Indie

The deepest strategic question this teardown opens is: if you are an indie founder with one to three engineers and no VC funding, should you build a VS Code extension or a VS Code fork?

The answer is overwhelmingly extension, and the reasoning is structural.

Forking VS Code is a platform engineering problem. You need someone on the team who can keep up with Microsoft's release cadence, port security patches, manage the build pipeline across macOS, Windows, and Linux, sign binaries with platform certificates, handle automatic updates without breaking installed user state, and maintain compatibility with the thousands of extensions your users will expect to keep working. Cursor and Windsurf can do this because they have the headcount for it. A two-person indie team cannot, and the gap shows up immediately in churn — fork-based IDEs that fall behind upstream VS Code by even a few weeks start losing users to the more polished alternatives.

Extensions, by contrast, push all that platform work back to Microsoft. You write TypeScript against the VS Code Extension API, you publish to the marketplace, and you ship features at your own cadence without ever worrying about whether the editor itself runs on the user's machine. That is the entire reason the Cline-Roo-Kilo lineage exists with such small teams.

The extension form factor also has a hidden distribution advantage that gets underweighted: the VS Code Marketplace itself functions like an app store with five to ten million developers walking through it every week. Featured extensions get hundreds of thousands of organic installs without any marketing spend. Fork-based IDEs have to acquire every user through paid or earned media, because the user has to go to a website, download a binary, and install it as a separate application. The marketplace is essentially free distribution that the fork model does not have access to.

The tradeoff, again, is feature ceiling. An extension cannot rewrite the editor. It cannot change the file tree, cannot embed AI in the same surfaces Cursor can, cannot rebrand the application itself. If the feature you want to build absolutely requires editor-internal changes, the fork is the only path. But for the vast majority of indie use cases — agents, autocomplete, code review, documentation generation, refactoring tools — the extension API is more than sufficient.

The Kilo founders made the extension bet, and the bet is paying off. It is also the bet most indie founders considering this space should make, with one important caveat: the horizontal agent slot is now occupied by Cline, Roo, and Kilo, and competing head-on in 2026 is harder than competing in 2024 was. The opening for new entrants is vertical — pick one language or one workflow that is underserved and build the agent for that, not the agent for everyone.

That brings us to the Playbook.