Zed 1.0: When 'Fast Editor' Finally Stops Being a Marketing Line

I have a complicated relationship with code editors. I used vim for fifteen years out of stubbornness, switched to VS Code because the ecosystem made it impossible not to, and have spent the last four years quietly resenting it every time the laptop fans spin up because I opened three monorepos and a markdown file.

Zed 1.0 shipped at the end of April 2026. I’ve been running it as my daily driver for the two weeks since, and I’m writing this post in it. Here’s where I’ve actually landed, including the things I think the typical Zed review under-sells.

Why this release matters

Zed isn’t new. Pre-release builds have been around since 2023, Linux support landed in 2024, the source went GPL not long after. What shipped on April 30 is 1.0 — the team’s signal that the API, extension model, and configuration format are stable enough that they’re willing to stand behind them.

What’s actually in the box:

• Built in Rust, including a custom GPU-accelerated UI framework called GPUI that the team open-sourced under Apache 2.0
• Native binaries for macOS, Linux (X11 and Wayland), and Windows
• A proper AI agent panel with first-class Anthropic Claude integration, multi-model support (OpenAI, Google, Ollama), and Zed’s own Zeta model for inline edit prediction
• Bookmarks, “view commit” in the command palette, the usual round of 1.0 papercut fixes
• A growing extension ecosystem — ~1,000 extensions as of early 2026, all running as sandboxed WebAssembly modules

The architecture choice is the headline. Almost every editor in the last decade has been Electron — Chromium plus Node.js with a text editor painted on top. Zed isn’t. It draws every pixel to the GPU through GPUI and the result is the kind of thing you have to use to internalize.

The numbers, and they’re not subtle

Here’s the comparison I keep coming back to. I measured these myself on my own workstation; your mileage will vary by a small constant.

16x lower memory footprint. That’s not a typo. Open it on a machine where you’ve been pretending VS Code’s RAM appetite is fine and you’ll feel the difference within a minute.

The “GPU-accelerated editor” claim, decoded

This phrase has been around for years and it’s usually marketing for “we used requestAnimationFrame properly.” Zed actually means it.

GPUI is a retained-mode UI toolkit written from scratch in Rust. Every panel, every cursor, every syntax-highlighted token is drawn by the GPU at 120 Hz on a display that can keep up. The practical consequence is that the editor feels mechanical in the way native macOS apps used to feel ten years ago and almost nothing on Linux has felt since GTK 2. Scrolling a 10,000-line file is silk. Splitting a pane is instantaneous. Type-ahead never gets behind your fingers.

On Wayland (Plasma 6.6 in my case) it integrates cleanly: fractional scaling works, HiDPI works, the cursor doesn’t ghost, the window decorations look native. Zero of the Electron-on-Wayland tax I’ve gotten used to swearing about.

The AI story is the actually-interesting one

I’m normally suspicious of “AI-native editor” framing — it usually means a chat sidebar bolted onto Electron with a vendor lock-in. Zed’s version is more thoughtful, and it’s the part I think is going to age best.

Three pieces matter:

1. The Agent Panel. Multi-provider — Anthropic, OpenAI, Google, and Ollama as a first-class option. Bring your own API key. You can also point it at a self-hosted Ollama on localhost:11434 and run fully offline with qwen3.6 or gpt-oss:20b doing the work. For anyone who read my Ollama post, this should land hard: the same boring-default local runtime, now driving an agent loop inside your editor with no data leaving the machine.

2. The Agent Client Protocol (ACP). Zed is leading work with Google and JetBrains on a standard wire protocol for AI coding agents — analogous to what LSP did for language servers. The big near-term win: Claude Code runs natively inside Zed via ACP. You get Anthropic’s autonomous agent (plans steps, reads codebase, edits files, runs verification commands) without leaving the editor. The authentication is decoupled — Claude Code uses your Anthropic key, Zed’s chat uses whichever provider you pointed it at, and they don’t step on each other.

3. Parallel agents. Multiple agents can work concurrently on different files or different tasks. The use case: agent A is refactoring your auth middleware while agent B writes the migration for the database change while you keep typing. Disorienting at first, genuinely useful once you get the hang of it.

Zeta — Zed’s own model for edit prediction — sits on a different seat: it’s not an agent, it’s a tab-completion replacement that’s been trained specifically for the “predict the next edit” task rather than the “predict the next token” task. It’s open source, it runs locally, and it’s surprisingly good at the small mechanical edits Copilot is mostly used for anyway.

Where it’s still rough

I’d rather you hear this from me than discover it on day three.

The extension ecosystem is a real gap. VS Code has 50,000+ extensions. Zed has around 1,000. For mainstream languages and tools the gap doesn’t matter — Rust, Go, Python, TypeScript, Ruby, every major LSP, every common formatter, Tailwind, Prettier, ESLint, you’re covered. For anything niche — proprietary languages, legacy frameworks, that one Terraform-flavored DSL your platform team maintains — you’re either porting an extension yourself or waiting.

Debugger maturity. Zed’s debugger story is improving but it’s not yet at parity with VS Code’s. If your daily loop involves heavy breakpoint-driven debugging in a non-native language (especially .NET or Java), Zed will frustrate you. Native (Rust, Go via dlv, C/C++ via lldb) works fine.

Settings and keymaps are JSON files. That’s intentional and I respect it, but if you came from VS Code’s GUI settings UI you’ll spend an afternoon migrating. The good news: you only do it once and the configs commit cleanly to dotfiles.

The plugin migration story isn’t a story. There’s no import-from-VS-Code wizard. If you have a complex VS Code setup, budget a couple of hours to reconstruct it. For me that was maybe 45 minutes — most of the time was figuring out which plugins I’d been running on autopilot for two years and didn’t actually need.

Who should switch (and who shouldn’t)

Switch if:

• You spend any meaningful time noticing how slow your editor is, or apologizing for the fan noise
• You’re on Linux/Wayland and tired of Electron’s rendering compromises
• You work in mainstream languages with mature LSP support
• You care about AI coding agents but want one with first-class Ollama support and an open protocol rather than vendor lock-in

Hold off if:

• Your workflow depends on a niche VS Code extension with no Zed equivalent
• You live in the GUI debugger, especially for .NET or Java
• You’re on a corporate machine where “switch editors” is a three-week IT ticket

Where I’ve landed

Zed is my daily driver as of two weeks ago. VS Code is still installed for the two projects where I need a debugger extension Zed doesn’t yet match, and for editing the occasional Jupyter notebook. Neovim is still on my muscle memory for git rebase -i and quick remote edits.

But for the 90% of work that is “open a project, write code, ask an agent to do something, review the diff, commit” — Zed is the first editor in a decade that has earned the word fast as a literal description, not a marketing claim. The Rust thesis is correct. The Electron-on-laptop era is, for me, ending.

Two weeks isn’t a long time. I’ll write a follow-up at the 90-day mark with the things I’ll have inevitably gotten wrong here.