VS Code and its forks: landscape in 2026

The rise of VS Code

When Microsoft shipped VS Code in 2015, the field was different: Sublime Text owned the "fast, lightweight" niche under a paid licence, TextMate still had a following on the Mac, JetBrains and Visual Studio owned the heavyweight IDE end, and Vim and Emacs served people who preferred keyboard-driven, programmable editors. The most direct rival was GitHub's Atom, launched a year earlier and built, like VS Code, on Electron, the very runtime GitHub had created. Atom was the "hackable text editor" with the open-source story and the community momentum. VS Code won anyway, on speed and on the extension model; Microsoft bought GitHub in 2018 and shut Atom down in 2022. The editor that arrived as a challenger became the thing everyone else now starts from.

Much as most web browsers today are really Chromium underneath, we are now watching a new generation of editors rise on top of VS Code. Today engineers are playing with a lot of these, each one wrapped around an AI agent and shipped by a company that is not Microsoft. The most heavily funded, most aggressively marketed coding tools of the last two years are, underneath the branding, the same base with different harness and services around it.

Let's take a look at how these products are built, so you can make a better decision when picking an editor, or get a clearer insight into what people in your organisation are already using.

Why VS Code is a good foundation to build on

VS Code was almost designed to be forked, even if that was never the explicit intent. Four decisions Microsoft made years ago turned it into the default chassis for AI IDEs:

• A permissive licence on the core. The Code OSS repository is MIT-licensed. Anyone can clone it, rebrand it, modify it, and ship a commercial product on top, without negotiating anything with Microsoft. The branded "Visual Studio Code" build you download from Microsoft adds proprietary pieces and a different licence, but the engine underneath is free to take.

• A clean extension model. VS Code's architecture separates the editor from extensions, which run in a separate extension host process — shared by all extensions and communicating with the editor over well-defined APIs. The same model standardised the Language Server Protocol (LSP) and Debug Adapter Protocol (DAP), so language intelligence and debugging are portable across any editor that speaks them. A fork inherits the entire extension ecosystem for free.

• Monaco, a reusable editor core. The actual text editor, Monaco, is a self-contained component. Forks do not have to rebuild the hard part: cursor handling, folding, multi-cursor, syntax highlighting, diff views.

• Electron helps it run everywhere. Cross-platform desktop delivery is solved out of the box. A startup can ship a polished IDE on macOS, Windows, and Linux on day one without a platform team.

Put those together and the cost of producing a credible IDE drops from "years and a large team" to "build fast on top and ship." The hard, differentiated work moves up the stack to the AI layer: the agent loop, the context engine, the model routing.

The current field

Because the editor layer is shared, the real differences are now in the AI experience and in how much autonomy each tool expects you to hand over. Here is the mid-2026 field.

You may want to pay attention to two things here. The first is that the entrants are backed by serious partners: three of the six are AWS, Google, and Alibaba, with ByteDance making four big-tech backers; OpenAI pursued Windsurf, and in June 2026 SpaceX agreed to acquire Cursor's parent, Anysphere, for $60 billion in an all-stock deal expected to close in the third quarter pending regulatory approval. The IDE is now strategic surface area for the cloud and model vendors, because whoever owns the editor owns the default model, and a daily touchpoint with every engineer.

The second is that vendor stability is not a given. Windsurf is the cautionary tale: it went from independent (Codeium) through a high-profile talent-and-licensing arrangement with Google to an acquisition by Cognition, all inside a single year. Standardising on a young IDE vendor also banks on ownership, model partnerships, and product direction staying recognisable. Nor is open source a guaranteed escape hatch. Void, an Apache-2.0-licensed VS Code fork positioned as an open-source Cursor alternative, drew real attention and was then deprecated and archived.

The tools in detail

Below is a short profile of each editor mentioned in this article. Given the current speed of development, treat it as a snapshot.

Visual Studio Code (VS Code)

Developer Microsoft · Started first released in April 2015, with the core open-sourced as Code OSS under the MIT licence · Status actively developed on a monthly cadence; the dominant editor and the base every fork below starts from · Link code.visualstudio.com

VS Code supplies the inherited editor layer: Monaco, the extension host, LSP and DAP, the integrated terminal, Git, debugging, Remote Development, and first-party GitHub Copilot integration. Forks start from that mature base before adding their own AI overlay, marketplace choices, telemetry defaults, and governance model.

Launched in 2015, VS Code topped the Stack Overflow Developer Survey as the most-used editor by 2018, just three years in, displacing tools like Vim, Emacs, and Sublime Text that had decades of accumulated loyalty.

The core, Code OSS, is MIT-licensed on GitHub and is widely used as a base for other editors. The "Visual Studio Code" product you download from Microsoft is built on top of it: the same engine plus proprietary telemetry, Microsoft branding, and the closed Visual Studio Marketplace. Community builds like VSCodium exist precisely to strip those proprietary pieces back out and ship a clean, fully open binary of the same editor.

Cursor

Developer Anysphere · Started company founded in 2022, editor launched in 2023 · Status actively developed, the category leader, and heavily funded; in June 2026 SpaceX agreed to buy Anysphere for $60 billion (all-stock, expected to close in Q3 pending regulatory approval), exercising an option it took in April · Link cursor.com

Known for predictive multi-line "Tab" autocomplete, an agent mode that plans and edits across many files, whole-repository indexing for context, multi-model routing across frontier providers, and project rules (the .cursor/rules directory) for conventions. Many of the conventions other forks adopted (such as agent mode, repo indexing, rules files) started here.

Its core technical decision was to create a codebase-wide context engine. Cursor indexes your entire repository and draws on that index to answer questions and make edits with full project context. That is what makes it feel meaningfully smarter than file-scoped autocomplete in a large codebase, and it is the capability most of the other forks have since raced to match.

Cursor is also the tool most associated with "vibe coding." Andrej Karpathy, the former Tesla AI director and OpenAI founding member, coined the phrase in early 2025 to describe building software by describing intent and letting the model write the code, rather than typing it precisely yourself.

A couple of details matter for security review. The first is that even when you supply your own model API key, requests still route through Cursor's backend instead of going directly to the provider. Cursor's own explanation is that it performs the final prompt assembly server-side, so "bring your own key" does not mean "your code never touches Cursor's infrastructure." The second is that codebase indexing uploads chunks of your code to compute embeddings. Cursor states that the plaintext used for embeddings does not persist after the request, but the embeddings themselves, along with metadata such as file names and hashes, may be stored. Neither is necessarily disqualifying; both are the kinds of data-flow detail an enterprise review needs to address before standardising, the same audit posture covered in AI coding agents and compliance.

Windsurf

Developer Codeium (Exafunction), now Cognition · Started Codeium founded in 2021; the Windsurf editor launched in late 2024 · Status actively developed, but through a turbulent year: key leadership and a technology licence went to Google in mid-2025, after which Cognition acquired the remaining company · Link windsurf.com

Built around the Cascade agent and a "flows" model of AI-assisted work, with strong enterprise and self-hosting options and multi-model support.

Windsurf did not arrive as a startup newcomer. The company behind it, Codeium, had already shipped one of the most widely used free AI coding extensions, also called Codeium, with well over a million developers, before it launched Windsurf as a standalone editor in late 2024. The editor was a second act on top of an existing distribution base.

Its flagship idea is Cascade Flows. Rather than only responding to prompts, the agent maintains live awareness of what you are doing, your terminal output, file changes, and errors as they happen, and acts on that context. The intended feel is a collaborator working alongside you rather than a chatbot you query, and it is the bet that most clearly distinguishes Windsurf from the assist-first forks. The framing throughout is "flow state": the marketing leans hard on keeping developers in flow, with agentic editing, evolving chat, live previews, and codebase-aware assistance built into the editor, not bolted on.

The Cognition acquisition also changed what Windsurf sits next to. It now shares a company with Devin, one of the best-known autonomous AI software-engineering agents; Business Insider framed the deal as a way for Cognition to strengthen Devin with Windsurf's assets. For a buyer, that is double-edged: the editor is backed by a company with a serious agent roadmap, but Windsurf's own direction is now tied to how that broader Devin strategy plays out.

Kiro

Developer AWS · Started public preview in July 2025 · Status actively developed, with a free tier and paid subscription plans; built on Code OSS · Link kiro.dev

Its central idea is spec-driven development: you author requirements, design, and task specifications, and the agent implements against them, rather than prompting freehand. It also offers agent "hooks" that trigger automated actions on repository events.

What makes it distinctive is that Specs are a first-class concept. Instead of jumping straight to code, Kiro has you start from a natural-language spec, which it refines into structured requirements, design documents, and a task breakdown before a single line is written.

The complementary feature is Hooks: event-driven agents that fire automatically on actions like saving a file, pushing a commit, or finishing a function. They let the AI run tests, update documentation, or check for security issues in the background without being asked each time, turning routine follow-up work into something the editor does on its own.

Antigravity

Developer Google · Started launched in November 2025 · Status actively developed; Antigravity 2.0 made it Google's consolidated agentic development platform across desktop, CLI, and SDK · Link antigravity.google

An agent-first platform with an "agent manager" that runs and supervises agents working across the editor, terminal, and browser, built around Google's Gemini models. The 2.0 push brought the CLI and plugin/workflow surface closer to the desktop app rather than leaving agentic coding split across separate Google tools.

Antigravity is organised around projects rather than a single open folder. A project can span one or several folders, a frontend and a backend repo, for example, and each project carries its own isolated agent settings. That suits monorepos and multi-repo systems, where the agent needs to reason across more than one tree at once.

Those projects are also the unit of governance: Google's own codelab shows per-project controls for terminal-command review, file-access review, agent behaviour, allowed paths, allowed URLs, and even which MCP tools are available within a given project. Scoping permissions per project instead of per machine is closer to what an enterprise actually wants from an autonomous agent than most of the field currently offers.

The other key concept is artifacts. Agents produce implementation plans, task lists, walkthroughs, and source files that can be reviewed before and after the work runs. For a tool that delegates this much, those records give reviewers a concrete trail through the agent's work.

Trae

Developer ByteDance · Started international release in early 2025, evolving from ByteDance's earlier MarsCode work · Status actively developed, free and aggressively priced · Link trae.ai

Offers a "Builder" agent mode and multi-model support including frontier models, with a generous free tier used to win default-tool status while the market is still forming.

Trae is also more than a single editor. Alongside the Trae IDE there is Trae SOLO, which the official docs describe as an AI-native workspace, and a broader SOLO/workspace experience spanning web, desktop, and mobile clients. The direction of travel is the same one the agentic-workspaces section below describes: the editor is one surface among several, and the work increasingly lives in a workspace around the agent.

Qoder

Developer Alibaba · Started launched around August 2025 · Status actively developed but less externally proven than the US hyperscaler tools; desktop app, CLI, JetBrains plugin, and GitHub Action are all visible · Link qoder.com

Qoder's public positioning is repository-level understanding, and its footprint is broader than a simple editor: alongside the desktop app there's a CLI and a JetBrains plugin. The ambition is clear, though the public proof is still thinner than Cursor's.

Qoder's proposal is built around Quest Mode. Alibaba Cloud's enterprise page describes it as autonomous multi-file task execution, paired with RepoWiki and deeper codebase understanding: the agent reasons across the repository the wiki has mapped and carries out a task spanning many files instead of editing one at a time. The GitHub Action points in the same direction, adding automated review, issue and pull-request chat, project-specific Agents.md context, subagents, slash commands, and structured CI output. Both halves point at the same gamble: in a large codebase, the unit of work is a multi-file change, and the tool's job is to understand the repository well enough to carry that change across the right files.

Void

Developer the Void (Glass Devtools) team · Started around 2024, open-sourced under the Apache-2.0 licence · Status deprecated and archived on GitHub in June 2026 · Link voideditor.com

Created as an open-source Cursor alternative with bring-your-own-model support, including local models, plus agent features. Void is the warning example referenced earlier: source availability and a permissive licence reduce lock-in, but they do not guarantee an active maintainer base.

Void was built around the idea that people need an open-source alternative with privacy and control, and unlike the proprietary forks it can back that up: the full source code is on GitHub, as the official README states, so you can inspect the claims instead of taking them on trust. The README's framing is that you can "bring any model or host locally," with messages sent directly to the providers and Void retaining none of your data. There is no vendor backend sitting in the middle the way there is with Cursor.

That makes it the natural fit for local-model workflows. Because you can point it at any model and host it yourself, Void suits Ollama or Qwen-style local coding setups where the whole point is that nothing leaves your machine, rather than always routing through a single vendor. The caveat is the one above: the privacy and local-model story is genuine, but it only helps if the project keeps moving.

Important differences between the forks

Their shared foundation can make these tools feel interchangeable with VS Code, but the edges below matter.

The extension marketplace is the big one

Audit extension registry. Before standardising, export the team's real VS Code extension list and check three things: whether each extension exists on Open VSX, whether any Microsoft-only extension is business-critical, and whether your supply-chain controls cover the new registry.

The Visual Studio Marketplace, where official VS Code extensions live, is operated by Microsoft under terms that restrict its use to Microsoft's own products. Forks generally use Open VSX instead, which is good and improving but does not always carry the same extensions. The long tail of niche extensions may lag, and proprietary Microsoft extensions such as C/C++, Pylance, .NET debugging, Remote Development, and Dev Containers are licensed for official VS Code only.

Rebasing onto upstream is a permanent tax

Microsoft ships VS Code on a monthly cadence. Every fork has to continuously merge those upstream changes into its own modifications, or fall behind on editor features, security fixes, and extension-API compatibility. A well-resourced fork keeps the gap small. An under-resourced one drifts, and you eventually notice that you are running an editor that is several months behind on fixes everyone else already has. When you evaluate a fork, the vendor's rebase discipline is a real diligence question.

Telemetry and defaults change

Microsoft's build of VS Code has its own telemetry settings. A fork strips those out and adds its own, and the AI features ship telemetry of their own on top. For a regulated or security-conscious organisation, "what does this editor send, to whom, and can we turn it off" is a fresh question for every fork, not an answer you can carry over from VS Code.

A separate category: agentic workspaces

Not every new AI coding tool brings an editor: some skip that layer entirely to focus on the AI workflow. A distinct category has emerged that sits above the agents rather than wrapping an editor around one: agentic workspaces.

The shared idea is that the unit of work is no longer "a file open in an editor" but "a task handed to an agent," and you want to run several of those at once. So instead of shipping another editor, these tools orchestrate one or more coding agents (Claude Code, Codex, and similar CLIs) in parallel, each isolated in its own git worktree so the agents do not collide, and then give you a single place to watch them run, compare results, and merge the ones that worked. Conductor packages this as a desktop app for running parallel Claude Code sessions; Claude Squad does it from the terminal, managing multiple agent sessions across tmux and worktrees; the others are variations on the same pattern.

For engineering leaders, this category sits differently from the forks on three axes:

• Lighter lock-in, thinner maturity. These tools orchestrate agents and CLIs you already have instead of replacing your editor, so the switching cost is lower and they compose with whatever editor your team uses. They are also younger and thinner than the forks, often a single small team or an open-source side project, so the vendor-stability caution raised earlier applies with even more force.

• Orchestration. Running several autonomous agents in parallel, each with repository access and the ability to execute commands in its own worktree, multiplies the access-scope and audit questions covered in the coding agent evaluation matrix. More concurrent agents means more simultaneous write access and more to log.

• Agentic capabilities first. If delegating work to parallel agents becomes the normal way senior engineers operate, the choice of editor underneath fades in importance, because less of the day is spent typing in it. And many of these tools allow developers to call their favourite IDE if needed.

As full-fledged IDEs build their own agentic layers, these tools can be used alongside them to shape the agentic experience. The short profiles below follow the same format as the editors above.

Conductor

Developer Melty Labs · Started 2025 · Status active · Link conductor.build

A macOS app that runs several Claude Code, Codex, or Cursor agents in parallel, giving each its own branch and worktree, with a UI to watch them work, compare their output, and merge the attempts that succeeded.

Claude Squad

Developer open-source project · Started 2025 · Status open source, active · Link github.com/smtg-ai/claude-squad

A terminal UI that manages multiple agent sessions (Claude Code, Codex, and others) in isolated workspaces using tmux and git worktrees, so several agents can run side by side without colliding.

T3 Code

Developer T3 Tools Inc. · Started 2025 · Status open source (MIT), free, active · Link t3.codes

Bills itself as "the open-source control plane for coding agents." It orchestrates several agents (Claude Code, Codex, OpenCode, and Cursor) from one interface on a bring-your-own-subscription basis, gives each agent thread its own git branch, supports switching models mid-thread, and turns a finished thread into a GitHub pull request in a single click. No telemetry unless you opt in.

Nimbalyst

Developer the Nimbalyst project (open source) · Started 2025 · Status open source (MIT), free, active · Link nimbalyst.com

Describes itself as "the open-source visual workspace for building with Codex, Claude Code, and more." It manages multiple agent sessions on a kanban board with optional git-worktree isolation, adds visual editors for markdown, CSV, diagrams (Excalidraw, Mermaid), mockups, and data models, offers inline diff review of agent changes across file types, and ships a mobile app for monitoring runs remotely.

Superset

Developer Superset Inc. (Y Combinator-backed, founded by three ex-YC CTOs) · Started launched on Product Hunt in late February 2026 · Status active, available on GitHub under Elastic License 2.0 · Link superset.sh

Bills itself as "the code editor for the AI agents era" and is built to orchestrate many CLI-based coding agents in parallel (it advertises 100+), sandboxing each in a separate worktree. It works with Claude Code, Cursor, Codex, Copilot, Amp, Gemini, and OpenCode, lets you open any worktree in VS Code, Cursor, Xcode, JetBrains, or a terminal, and adds PR review, port forwarding, and remote workspaces; a cloud option sits alongside the macOS app.

CodeHydra

Developer Stefan Hoelzl (independent) · Started launched early 2026 · Status early, independent project · Link codehydra.dev

A "multi-workspace IDE for parallel AI agent development" that runs several coding agents at once, each confined to its own worktree, with real-time status monitoring and notifications that flag which sessions need attention. It automates an integrated VS Code so a finished task is ready to review and test the moment you switch to that session.

The realities to price in

• Lock-in moves from the editor to the agent. Be wary that you become dependent on its agent layer: the context engine, the prompt and rules format, the custom skills and workflows your team builds inside it, and the model it is tuned for. Those do not port between forks. Manage the agent configuration as an asset you might have to migrate: prefer rules, skills, and config that are documented and exportable over deeply tool-specific magic, and avoid letting your workflow sprawl into a vendor-locked format.

• Your IDE vendor may be your cloud vendor's competitor, or your cloud vendor. When AWS, Google, and Alibaba ship IDEs, the default model and the smoothest integrations point at their cloud and their models. That is a feature if you are already on that cloud and a quiet gravitational pull towards it if you are not. The IDE is now part of the cloud lock-in conversation, and you don't want to be here.

• Free is a customer-acquisition strategy, and it is changing. Token prices, subscription tiers, and what each tier includes keep shifting, and companies that focused heavily on winning users are moving towards more aggressive monetisation.

A checklist before you standardise

None of this argues against using a fork. The best AI editing experiences today genuinely are forks, and the productivity gains are real. It argues for choosing deliberately.

• Separate the two decisions. "Which agent do we want" and "do we want it inside a forked IDE or as an extension in stock VS Code" are different questions. Several of these capabilities (GitHub Copilot, and increasingly others) are available as extensions in the VS Code you already control. If you do not need the fork-only features, the extension path keeps you on the Microsoft Marketplace and spares you the upstream rebase work.

• Run the extension audit before you commit. Check the list your teams actually depend on against Open VSX and the fork's bundled substitutes, as covered in the marketplace section above — the proprietary Microsoft extensions are the ones that will hurt if your stack relies on them.

• Weight operational diligence — it is heavier for a full IDE. Rolling a fork out org-wide is a bigger commitment than adding a coding-assistant extension to the VS Code your team already runs: it touches device management, the extension-registry question, telemetry review, and your data-handling posture all at once. Look past the product demo and check the boring things that decide whether the tool can survive inside your organisation: rebase cadence, security posture, data handling, auditability, support model, and an exit path.

• Expect a mixed estate, and manage it. In practice teams will not converge on one tool. Some engineers will want Cursor, some will live in Claude Code in the terminal, some will use whatever their cloud vendor ships. That is fine, but it is a governance surface: more registries to vet and more telemetry to review. Knowing what your teams actually run is the precondition for managing any of it sensibly. That is the same visibility problem we wrote about in the coding agent evaluation matrix and in AI coding agents and compliance.

Where it likely converges

The likely end state is the one the browsers reached: a single open engine underneath a number of competing differentiated products.

The catch is that "the editor is commoditised" is true right up until the moment you depend on a lot of specific things from a vendor. Engineering leaders should enjoy the better tools while keeping that dependency shallow enough to change their mind.

If you are deciding which of these tools to standardise on, or trying to get visibility into the mix your teams are already running, book a diagnostic. We will help you structure the evaluation, run the extension and data-handling audit, and keep your AI workflow portable enough to survive the next year of this market.