Why I Started Using Zed

The Zed team's previous product was Atom.

Atom was a fork of Chromium, and building it produced Electron along the way — which later became the foundation VS Code is built on. Put bluntly, the ground VS Code stands on was dug by these same people, and they have now built a house next to it that doesn't use that foundation.

Zed 1.0 only shipped on 29 April 2026. Five years, and over a million lines of Rust.

My reasons for moving off Microsoft Versus Code Microsoft VS Code were less romantic than that. I cooked my server to 96°C one afternoon, and afterwards went and measured what this thing had actually been leaving on my machine.

The bill, first#

On the local side, with one project open in each:

The server side is worse. Remote development leaves its own runtime on the machine you connect to, and VS Code's looks like this:

7.9 GB against 107 MB. Seventy times.

Breaking down VS Code's 7.9 GB: cli 3.2 GB, bin 2.9 GB, extensions 945 MB, data 412 MB. And inside it I found two versions of the rust-analyzer extension sitting side by side, with nobody having cleaned out the old one.

Honestly that number alone was enough to make me try the alternative, and the way it feels in use matches — scrolling, opening files, searching, switching tabs are all immediate, with none of that "give it a moment to think" hitch.

There is an official migration path#

This is something I didn't know until afterwards: Zed has a whole page of official documentation, How to Migrate from VS Code to Zed, and the first-run setup wizard asks whether you want to import your VS Code settings and which AI you want to wire up.

If you skipped the wizard, the command palette has it:

What it brings over, and what it doesn't#

The docs have a full mapping table. A few entries:

It covers tabs, the file explorer, Git, the terminal, fonts and most editor preferences.

But it does not bring extensions, and it does not bring keybindings. Those two are on you.

Keymap: it's already VS Code by default#

base_keymap defaults to VS Code, so there is nothing to do. To confirm it or switch to something else:

{ "base_keymap": "VSCode" }

The options are VS Code, Atom, Emacs (Beta), JetBrains, Sublime Text, TextMate, Cursor, and None. You can also pick it in the settings window, or run zed: toggle base keymap selector from the command palette.

The ones you press constantly are identical: Ctrl + Shift + E for the file list, Ctrl + Shift + G for Git. No retraining required.

The docs list the shortcuts that still differ even with the VS Code keymap selected, but that table is written in macOS notation, and the two columns aren't even on the same platform, so copying it straight will confuse you:

On Windows and Linux, swap Cmd for Ctrl. Zed's keymap syntax has a secondary- modifier that exists precisely to paper over this. If you actually need to check something, the per-platform default keymaps in the repo are more reliable.

Easier still is the built-in Keymap Editor (Ctrl + K then Ctrl + S), which lists every action with its current binding and lets you change them directly. Anything you do there gets written back to keymap.json.

23 extensions, down to 8#

This was the part of the move that surprised me most. I had 23 extensions in VS Code, and after moving to Zed only 8 of them needed installing at all.

Not because I lost functionality — because the categories are drawn differently.

basedpyright   bash-language-server   eslint   json-language-server
package-version-server   ruff   rust-analyzer   tailwindcss-language-server
vscode-css-language-server   vtsls   yaml-language-server

The docs are refreshingly blunt about this, and it lands squarely on what I lost:

Zed does not offer as many extensions as VS Code. You won't find one-to-one replacements for every VS Code extension, especially if you rely on tools for DevOps, containers, or test runners.

Going the other way, they also list what needs an extension in VS Code and is built into Zed: real-time collaboration (no Live Share), AI assistance, the terminal panel, project-wide fuzzy search, a task runner, and LSP diagnostics.

Settings: there is a GUI, and it's more complete than I expected#

I assumed Zed was JSON-only, and found out halfway through writing this that it isn't. Ctrl + , opens a full settings window with a search box, categories, toggles and dropdowns:

Fifteen categories, and every entry has an "Edit in settings.json" button that jumps you to the raw file. The GUI and the JSON are two doors into the same settings, not an either/or.

If you want the file directly: zed: open settings file from the command palette, or Ctrl + Alt + ,.

Project-level settings are far more limited#

This is a real constraint you'll hit in practice. The settings window lets you switch scope, and switching to the project scope drops you from fifteen categories to five:

Project settings live in .zed/settings.json inside the project, and what you can put there is limited to editor behaviour and language tooling — tab_size, formatter, format_on_save and similar.

So "turn off auto_fold_dirs for this project only" or "disable Auto Reveal just here" is currently global-only. That's the first thing a colleague of mine, a heavy VS Code user, walked into.

Panel placement#

Worth noting: you don't need the settings window to move a panel to the other side — right-click the panel icon:

You can also pin every panel's dock in settings.json, which is what I did.

My settings, take them#

If you like the layout and colours, take the whole thing and edit from there. I've stripped my remote connections out and left a commented template:

{
  // base_keymap already defaults to VSCode; this line is just explicit
  "base_keymap": "VSCode",

  // When the CLI opens a file, use the existing window instead of a new one
  "cli_default_open_behavior": "existing_window",

  // Remote connections (host is an alias from your ~/.ssh/config)
  // "ssh_connections": [
  //   {
  //     "host": "my-server",
  //     "args": [],
  //     "projects": [
  //       { "paths": ["/home/you/projectA"] },
  //       { "paths": ["/home/you/projectB"] }
  //     ]
  //   }
  // ],

  // Panel placement
  "project_panel": { "dock": "left" },
  "git_panel": { "tree_view": true, "dock": "left" },
  "collaboration_panel": { "dock": "left" },
  "outline_panel": { "dock": "right" },
  "agent": { "sidebar_side": "right", "dock": "right" },

  // External agent (explained in the next section)
  "agent_servers": {
    "claude-acp": {
      "type": "registry",
      "default_config_options": { "fast": false }
    }
  },

  // Appearance
  "theme": {
    "mode": "dark",
    "light": "Gruvbox Light",
    "dark": "Catppuccin Macchiato - No Italics"
  },
  "icon_theme": {
    "mode": "dark",
    "light": "Zed (Default)",
    "dark": "Material Icon Theme"
  },
  "ui_font_size": 16,
  "buffer_font_size": 15,
  "minimap": { "show": "always" },

  "telemetry": {
    "diagnostics": true,
    "metrics": false,
    "anthropic_retention": false
  },

  // Confirming trust on every remote project gets old, but this trusts every
  // worktree unconditionally — decide for yourself
  "session": { "trust_all_worktrees": true }
}

Two things worth calling out: I've turned telemetry.metrics off, and session.trust_all_worktrees is convenient but amounts to giving up that confirmation step, so weigh it yourself.

The interface difference#

VS Code puts buttons everywhere — for instance the new file, new folder, refresh and collapse-all row in the explorer header:

Zed goes the other way: most operations live in the command palette and the right-click menu. At first it feels like something is missing; once you adjust, your hands stop leaving the keyboard.

Honestly that's the largest cost of the whole move — not features, habits. The actual feature gaps are a small list (below), and almost all of the friction in the first couple of days was muscle memory that hadn't caught up.

Remote development#

This is where the whole thing started for me, so here's more detail.

Remote projects go straight into ssh_connections in the settings file. host is an alias from your ~/.ssh/config, so keys, jump hosts and ports are all SSH's problem — Zed doesn't maintain a parallel system for it.

Cold start to writing code:

On the first connection it pushes the remote server up (that's the 107 MB from earlier), and after that the process is persistent, so reconnecting is fast. The remote server process on my box has been up for seven days straight.

Reconnection is far more reliable than VS Code#

This was an unexpected benefit. On a poor connection, VS Code Remote-SSH regularly has to reconnect and reload the window, and sometimes just sits on "Reconnecting..." indefinitely. On the same network, Zed fails to reconnect noticeably less often, and most of the time it just picks up without me noticing.

Switching remote projects in one window#

VS Code doesn't have this. Opening a second remote project in VS Code means a second window, and the windows and tabs pile up. Zed swaps within one window, which is visually much cleaner. I like it more than I expected to.

The built-in Git is more complete than I expected#

I assumed I'd be hunting for a GitLens replacement. I wasn't. The Git panel switches to a tree view, and commit history and diffs are right there in the editor:

Inline blame is built in too — hover and you get a card:

Markdown preview renders mermaid#

I worried about this one early, since I use mermaid heavily when writing, and in VS Code that was propped up by an extension. Zed's built-in preview just draws it:

ACP: pulling the agent out of the editor#

This is something I only ran into after switching, and it's the part I most wanted to write about.

ACP states its purpose plainly:

LSP pulled "language intelligence" out of the IDE. ACP wants to do the same thing for agents.

Before LSP, every editor had to implement completion and go-to-definition for every language itself. After LSP, a language writes one server and every editor can use it. ACP targets a problem of exactly the same shape: right now every AI agent has to write a plugin for every editor, and ACP lets the agent write it once.

JetBrains, Google and GitHub have all signed on, and the registry lists more than twenty-five agents. Zed's first-run wizard asks which one you want to wire up.

What it looks like#

Once you add an agent server to your settings, it appears in the sidebar:

Note the row at the bottom right: Opus (1M context), High, Fast mode.

That row is the point, because it explains ACP's division of labour. The docs put it this way:

Zed hosts the thread in the Agent Panel, while the External Agent usually owns its own runtime, auth, model selection, tools, and native configuration.

So model selection, authentication, tools and configuration all belong to the agent. Zed only lends the interface: thread display, multi-file editing, project context, diff review.

My original question was "does going through the agent panel use a different model than the CLI?" I couldn't find an answer anywhere, and eventually realised the question itself is wrong. ACP doesn't touch models at all. Both routes run the same thing.

Old conversations can be imported#

This one is buried, but it's useful. Ctrl + Alt + J opens the Threads Sidebar, then Ctrl + G (or the clock icon at the bottom left) opens Thread History:

There's an Import Threads button in there.

Pick which agents to import from, and Zed reaches out over ACP to collect the sessions that agent left on the local machine, folding them into your history. They arrive archived; open one to resume it. Re-importing is safe, since anything already in your history gets skipped.

Terminal Threads: you don't actually have to choose#

I assumed "use the native agent panel" and "run the CLI in a terminal" were mutually exclusive. Zed has already solved that.

Terminal Threads let you pick Terminal from the + menu in the Agent Panel, and the terminal that opens becomes a thread in the Threads Sidebar. Run claude, amp, codex or anything else in it; the sidebar title updates to match whatever is running.

You can mix them freely with Zed's own agent threads and ACP threads, and keyboard navigation and notifications behave identically. Which means you keep the CLI's own environment and quota while getting Zed's interface.

And yet my CLI still lives in a plain terminal#

For exactly one reason:

/rc (remote control) only exists in the CLI.

The difference isn't capability, it's who owns the session:

My setup runs /rc automatically whenever a session starts. Wherever I am, opening a tab in Claude Desktop attaches to the same session — no need for that other machine to have Zed running at all.

That Resume session (2 of 27) picker in the video is this mechanism: the session exists independently of the editor, and the editor is just one way in.

Put differently: I gave up the more integrated UI in exchange for not being tied to any one machine. If you don't have a cross-machine requirement, the agent panel or Terminal Threads are both smoother, and I wouldn't talk you out of them.

What's missing#

This section is for anyone deciding whether to switch. What I hit myself, plus what I found looking around:

On the other hand, Dev Container support landed in January 2026. Earlier Zed reviews routinely list it as a gap, and that one can now be crossed off — which is the subject of the next section.

The community route to Traditional Chinese#

Nothing official seems to be in progress, but the community has zed-i18n.

It isn't painless: you lose some functionality, and it needs extra configuration. A colleague of mine wrote up the Windows 11 context-menu problems involved, which is worth reading before you install it:

But this list has a short shelf life#

I'm not especially worried about the gaps above, and the reason is the timeline.

Zed has only been open source for a few years, and 1.0 shipped on 29 April 2026 — five years of development, over a million lines of Rust. It ships new versions nearly every week, and twice while writing this piece I hit "the research says it doesn't exist, and then I opened it and it did": the settings GUI once, Terminal Threads the other. Dev Container was added this January.

The reason it can move that fast has to do with what's underneath. The team spelled out the history in the 1.0 announcement:

Atom was a fork of Chromium, spawning the Electron framework in the process, and Electron eventually became the foundation of VS Code. Web technology offered an easy path to shipping flexible software, but it also imposed a ceiling — no matter how hard we worked, we couldn't make Atom better than the platform it was built on.

So they started over and wrote the editor like a video game: feed the data to shaders on the GPU, with a UI framework, GPUI, built from nothing. That "4 GB against 200 MB" from earlier isn't the result of optimisation work — it's never having carried that weight in the first place.

Particularly good for Rust developers#

I'm including this because I write Rust myself.

Zed is itself written in Rust, which makes the team heavy users of their own product. But to be clear: none of what follows is Rust-specific — it's engineering across the whole LSP path. It just happens that rust-analyzer is famously heavy, so it benefits most.

So the accurate way to put the conclusion is: rust-analyzer didn't get faster, and it still eats memory. What changed is that the editor next to it stopped being an additional burden — which, for remote development, is the entire difference.

Everything can be Rust. I have no objection this time.

I did not delete VS Code#

By this point this reads like a sales pitch, so let me say it directly: this post does lean toward recommending Zed, because that set of resource numbers is very persuasive and it genuinely does feel much smoother.

But I kept both, split by situation:

• At home, over the LAN — VS Code Remote-SSH. Low latency on the same subnet, all my extensions and the interface I know, and I'm sitting next to the machine so I can see and kill anything that catches fire.
• Connecting from elsewhere for hours — Zed with the Claude CLI. Remote latency makes VS Code painful, and all three of the things that cooked my server to 96°C in the previous post are the kind that build up quietly while you're connected. Not being in the room is the worst case.

The split exists because the two tools have different cost structures, and I happen to have two very different usage patterns.

As for whether you should switch, my view is: if you aren't deeply tied to VS Code, the obstacle is habit rather than capability. I'm not a power user; I don't have workflows that depend on a specific extension, so moving cost me almost nothing. But if you use File Nesting daily, need to open databases, or tune a pile of per-project settings, Zed can't catch you yet.

If I had to name the biggest gain from the move, it isn't the gigabytes. It's being forced to review all 23 extensions. Five of them were overlapping layers of the Python ecosystem, two were different versions of the same extension left uncleaned, and several I couldn't remember installing at all. That audit doesn't happen on its own — only changing tools forces it.