Google's Antigravity is the most expensive proprietary fork to date

Yesterday, Google released Antigravity, a “next-generation IDE” for agentic development.

Very quickly, people (especially on Hacker News), couldn’t help but notice that Antigravity looked like a VS Code fork at its core.

Our research reveals that Antigravity isn’t just a VS Code fork, but a literal Windsurf fork (see evidence below). Windsurf is proprietary software that Google licensed for close to $2 billion.

NOTE: Since forking is usually associated with open-source software (even though you can technically fork any codebase), we decided to coin a term for this specific case of forking closed-source, proprietary software: PORK (a proprietary fork.)

*PORK (Proprietary Fork): A codebase forked from closed-source software for internal or commercial use — with none of the transparency of open-source forks.

Background: Google licensed Windsurf’s technology for around $2 billion shortly before Windsurf got acquired by Cognition (the makers of Devin).

Google’s deal sparked controversy. Vinod Khosla, a billionaire venture capitalist, criticized the deal, saying: “Windsurf and others are really bad examples of founders leaving their teams behind…”

We now have a pretty good idea of the main reason why Google paid so much for the licensing fee: Their new IDE, Antigravity, is a literal fork of Windsurf.

This makes Antigravity the most expensive proprietary fork in the history of tech.

The evidence: People have spotted Windsurf features that appear almost unchanged inside Antigravity:

Code analysis reveals references to “Cascade”, Windsurf’s proprietary agentic system, directly in Antigravity’s codebase.

Digging deeper makes the similarities even more obvious:

The UI similarities were also striking:

Some people who worked at Windsurf also now hold similar roles for (drumroll) Antigravity:

What’s surprising is how little Google did to hide the fact that Antigravity appears to be a Windsurf fork, to the point where people have started making jokes about it:

Kilo Code (that’s us!) started as a fork of a fork.

• We forked Roo Code

• Roo Code forked Cline

• Both Roo and Cline are open-source repositories

• Kilo Code is also open source

On the proprietary side:

• Antigravity forked Windsurf

• Windsurf forked VS Code

This “fork chain” is actually good for users overall: they get a combined set of features in one tool instead of juggling 2–3 different apps.

For example, in the Kilo early days we described it as “a superset of Roo Code and Cline.” That was a big part of why people started using us: they liked specific features in Cline (like the memory bank) but missed them in Roo, and vice versa. Kilo Code brought the best features from both Roo and Cline in a single package, which laid a great foundation to start adding our own.

It’s interesting to see the “fork of a fork” pattern gaining traction in the closed-source world too. But there’s a key difference between PORKs and open-source forks: transparency

With Kilo Code, we clearly state that we are a fork of a fork. Roo Code does something similar.

For Kilo, we have a clear statement about Kilo being a fork of a fork in our Github repo. Roo Code does something similar.

With Google’s Antigravity, you have to do your own digging and follow scattered clues to figure out that it’s Windsurf under the hood, and then read an article like this one to see the full picture.

You can’t fork PORKs: Kilo Code is an open-source repo, which means you can fork us (unlike with PORKs) and keep the fork chain rollin’.

Here’s the problem with forking IDEs: They’re all separate applications. You basically need to open a separate window to use them and install a separate package which counts as a separate app in your operating system.

This applies to Cursor, Windsurf, Antigravity, or any other VS Code fork.

That creates real workflow friction. Imagine switching your primary IDE every few weeks. Some developers are already getting tired of this:

Kilo Code takes a different approach: we’re not a separate IDE. Instead, we plug into your existing tools as a VS Code / JetBrains extension. We follow a simple principle:

Forks should be easy to use.

You shouldn’t have to abandon the IDE you already know and love. You should be able to install an extension and get the benefits of the fork right inside your current setup.

The true spirit of forking is to make more functionality available with as little friction as possible. With the current set of features, the easiest way to do that is as an extension.

What’s your take on this? Comment below!