If you’ve spent the last few years waiting for VS Code to stop eating 800MB of RAM just to open a config file, you’ve probably already heard of Zed. If you haven’t — it’s a code editor written in Rust, GPU-accelerated, and built from scratch by people who previously built Atom and then watched it die under Electron’s weight. They clearly learned their lesson.
Zed is not trying to be VS Code with a paint job. It’s a ground-up rethink of what a modern editor should be: fast enough that the UI never lags, collaborative enough that a team can edit the same file like a Google Doc, and AI-native in a way that feels like it was always there rather than a $10/month plugin.
Official GitHub: https://github.com/zed-industries/zed
This isn’t a "getting started" fluff piece. This is how you actually set Zed up for real work in 2026 — with AI that uses your own API keys, collaboration that doesn’t require a subscription to a SaaS you’ll regret, and performance that makes you stop apologizing for your editor.
Why Electron editors are genuinely exhausting
The problem isn’t that VSCode is bad software. It’s good software running on a terrible substrate. Electron wraps a full Chromium browser around your editor. Every keypress goes through a JavaScript event loop. Extensions communicate across process boundaries. You get plugin-dependent LSP latency, font rendering that ignores your system’s hinting, and a startup time that makes you feel like it’s 2008.
Zed’s renderer — GPUI — talks to the GPU directly via Metal on macOS and Vulkan/WebGPU on Linux. There’s no browser in the stack. The entire editor is one Rust process. The typing latency is measurably lower, and on a modern machine, the difference between "acceptable" and "feels like a local file" is the difference between 20ms and 2ms.
That’s the boring performance pitch. The interesting part is what you can build on top of a foundation that doesn’t leak memory and doesn’t stutter.
Installing Zed
On Linux, the cleanest path is the official install script:
curl -f https://zed.dev/install.sh | sh
This installs to ~/.local/bin/zed and sets up a .desktop entry. On Ubuntu/Debian you can also grab the .deb from releases.
On Arch, it’s in the AUR:
yay -S zed
For a self-hosted team environment where you don’t want curl-to-bash on production machines, grab the binary from the GitHub releases page and distribute it via your config management of choice (Ansible, Puppet, whatever you’re using). The binary is self-contained — no runtime dependencies beyond glibc and a Vulkan-capable GPU driver.
Gotcha: On headless or minimal Linux installs (CI machines, WSL2 without GPU passthrough), GPUI falls back to software rendering. It still works, but you lose the performance argument. Don’t benchmark Zed on WSL2 without --gpu passthrough and then complain it’s slow.
First-run configuration
Zed uses a single JSON config file. Open it with Ctrl+, or Cmd+,, or navigate manually:
~/.config/zed/settings.json
Here’s a solid baseline for a developer who cares about performance and ergonomics:
{
// Theme and font — use something designed for code
"theme": "One Dark",
"buffer_font_family": "Zed Mono",
"buffer_font_size": 14,
"buffer_line_height": "comfortable",
// Hard tabs or spaces — be consistent with your team
"tab_size": 2,
"hard_tabs": false,
// Autosave after focus loss — stops the "did I save that?" anxiety
"autosave": "on_focus_change",
// Format on save using the project's formatter
"format_on_save": "on",
"formatter": "language_server",
// Git gutter — shows diffs inline, much faster than a plugin
"git": {
"git_gutter": "tracked_files"
},
// Inline diagnostics instead of status bar noise
"show_inline_completions": true,
// Terminal inside the editor — no more Alt+Tab
"terminal": {
"shell": "system",
"font_size": 13
},
// Vim mode — optional but worth trying if you've avoided it
// "vim_mode": true
}
No bloat. No 40-line theme override. Zed ships sensible defaults; this file is your deltas from those defaults.
AI setup: your keys, your models
This is where Zed in 2026 actually earns its reputation over GitHub Copilot or the AI tab bolted onto VSCode.
Zed has a first-class AI assistant panel built into the editor, not a sidebar extension written by a third party. More importantly, it works with any provider via a standard configuration — Anthropic, OpenAI, Ollama running locally, or any OpenAI-compatible endpoint.
Open your settings and add an assistant block:
{
"assistant": {
// Choose your default provider
"default_model": {
"provider": "anthropic",
"model": "claude-opus-4-7"
},
"version": "2"
}
}
Then set your API key. Zed reads it from the environment, so add it to your shell profile:
# ~/.bashrc or ~/.zshrc
export ANTHROPIC_API_KEY="sk-ant-..."
Alternatively, you can use Zed’s built-in secret store via Zed: Sign In — it stores credentials in the system keychain. For a single developer machine this is more convenient. For a shared team setup or CI, environment variables win every time.
For local-first AI with Ollama:
{
"assistant": {
"default_model": {
"provider": "ollama",
"model": "qwen2.5-coder:32b"
},
"version": "2"
}
}
Make sure Ollama is running (ollama serve), and Zed will hit https://cd-linux.club:11434 automatically. No data leaves your machine. For a team that handles sensitive code, this is not optional — it’s the correct default.
Gotcha: Ollama’s streaming is noticeably slower than a hosted API, especially for large context windows. If your codebase context is >100K tokens and you’re on a machine without a beefy GPU, you’ll wait. Size your model to your hardware honestly. A fast qwen2.5-coder:7b often beats a crawling qwen2.5-coder:32b for short completions.
Using AI inline — not in a chat panel
The chat panel is useful for long-form questions. But the real productivity gain is inline AI editing, triggered with Ctrl+Enter (or Cmd+Enter) while you have a selection or are in a buffer.
Select a block of code, hit the shortcut, type a transformation in plain English — "extract this into a function", "add error handling for the case where the list is empty", "rewrite this to use async/await" — and the replacement streams directly into the buffer. You can accept or reject the diff.
This is conceptually similar to Cursor’s inline edit, but without Cursor’s overhead, and without sending your code to a service you didn’t explicitly choose.
The second pattern worth building into your workflow: open a new buffer with Ctrl+N, switch it to "Assistant" mode (Ctrl+Shift+A), and use it as a persistent context window. You can drag files from the file tree directly into the assistant panel to add them as context. For architectural questions, this beats asking a disconnected chat tool because Zed knows exactly what’s in scope.
Real-time collaboration
This is the feature that gets dismissed as a gimmick until you actually use it on a production incident at 2am.
Zed’s collaboration model works like this: one person hosts a "channel" or shares a project, others join by Zed username or invite link. Everyone sees cursors and edits in real-time. There’s no separate session server to configure — Zed handles the relay.
To start a collaboration session:
- Sign in to Zed (
zed: sign infrom the command palette) - Click your avatar in the top-right corner
- Select "Share Project" — you get an invite link
- Anyone who clicks the link and has Zed installed joins your session
For team use, channels are the right primitive. Channels work like persistent rooms — team members can join and leave without the session dying when the host closes their laptop.
# From the command palette
> join channel: your-team-channel
Channels can be created at zed.dev under your organization. The free tier is generous for small teams.
Gotcha: Collaboration works peer-to-peer when possible and falls back to Zed’s relay servers when NAT prevents direct connection. If your team is behind a restrictive firewall, direct P2P will fail silently and you’ll route through the relay — which adds latency. There’s no self-hosted relay option yet as of mid-2026. If this is a blocker for your compliance requirements, track the GitHub issue; it’s an active request.
Gotcha #2: Collaborative editing uses CRDTs (Conflict-free Replicated Data Types) under the hood, which means it handles concurrent edits correctly. However, formatters and LSP operations are host-relative. If you and a collaborator both trigger format on save at the same moment, you may get a double-format or a conflict. Agree on "host formats, guests don’t" when pairing on a file.
LSP, extensions, and what you’ll miss from VSCode
Zed’s extension ecosystem is smaller than VSCode’s. That’s just true. If you rely on a niche language extension, check the Zed extensions registry before migrating your daily driver.
For the mainstream languages — TypeScript, Rust, Python, Go, C/C++, Ruby, Java — the built-in LSP support is excellent, often better-tuned than the equivalent VSCode extension because it ships with the editor rather than being installed separately.
Extensions are written in WebAssembly and Rust. They’re isolated by design, which is why you don’t see the extension-vs-extension conflicts that VSCode developers have learned to live with. The tradeoff: porting a complex VSCode extension is non-trivial work.
What you’ll miss and workarounds:
- Database clients (like SQLTools): Use a standalone client like TablePlus or DBeaver alongside Zed. This is a clean separation of concerns anyway.
- Jupyter notebooks: Not supported natively. Use a browser-based Jupyter instance and a terminal in Zed to manage it.
- Remote SSH editing:
zed --remote ssh://user@host/path/to/project— this is available and works reasonably well, though not as polished as VSCode Remote SSH. File system operations go through an SSH connection, so latency matters.
Performance: what actually changes day-to-day
Benchmarks are fun but here’s the realistic list of things you’ll notice:
File switching is instant. In a project with 50,000 files, Ctrl+P fuzzy-finds and opens the target file in under 100ms consistently. VSCode on the same project takes 300-600ms and that gap compounds.
Syntax highlighting never drops frames. On very large files (think a 10,000-line generated SQL migration), VSCode will lag when scrolling. Zed doesn’t, because highlighting runs on the GPU.
Git operations in the editor are fast. The integrated blame, diff gutters, and conflict resolution views don’t spawn subprocess trees the way VSCode’s GitLens does. They’re built into the editor’s data model.
Startup time is under a second on any modern machine. Cold start with a large project open still beats VSCode’s warm start.
The real-world productivity gain isn’t any single operation — it’s the absence of micro-pauses. You stop working around your editor.
Hardening for a team rollout
If you’re deploying Zed as the standard editor across a team, a few practices save headaches later.
Commit a .zed/settings.json to your repo. This file is project-local and overrides user settings where it exists. Use it to enforce formatter settings, LSP configuration, and tab size so that "it formats differently on my machine" stops being a sentence anyone says.
// .zed/settings.json — committed to the repo
{
"tab_size": 4,
"format_on_save": "on",
"formatter": "language_server",
"languages": {
"Python": {
"language_servers": ["pyright", "ruff"]
},
"TypeScript": {
"language_servers": ["typescript-language-server"]
}
}
}
Pin the Zed version in your onboarding docs. Zed releases frequently. Extensions are versioned separately from the editor. A version mismatch between team members occasionally causes collaboration weirdness. Agree on a release channel (stable vs. preview) and document it.
Use channels for code review, not just incident response. The ability to join a colleague’s editor session and literally point at lines beats describing file paths in a Slack thread. Make it a habit in PR review, not just a break-glass tool.
Don’t give the AI assistant production credentials. Obvious in retrospect, but when you’re debugging a production issue and drag a .env file into the context window, that file goes to whatever AI provider you’ve configured. Use secrets management. The local Ollama setup is specifically valuable here — your .env contents never leave the host.
Where Zed still falls short
Honesty matters more than a sales pitch.
The extension ecosystem gap is real. If you maintain a legacy codebase in a niche language with only a VSCode extension maintained by one person on GitHub, you’re not switching yet.
The Windows experience is second-class. Zed on Windows only recently stabilized, and the GPU rendering story on Windows is more varied than on Linux or macOS. If your team is Windows-heavy, do a real pilot before committing.
The collaboration relay dependency bothers me. For open-source and privacy-sensitive teams, not being able to run your own relay server is a genuine problem. The code is open; someone will build this. It’s just not there yet.
Remote development over high-latency SSH connections (>100ms RTT) is noticeably worse than VSCode Remote. If you routinely edit code on servers in another continent, that matters.
None of these are showstoppers for a standard web or systems development team on Linux or macOS. They’re honest caveats.
The actual bottom line
Zed in 2026 is production-ready as a daily driver for most developers. The performance improvements are not marginal — they’re structural, because the architecture is right. The AI integration is the best in any standalone editor right now, specifically because it’s configurable down to the model and provider without installing anything.
The collaboration features alone justify the switch for distributed teams. Not because of the feature list, but because of the latency. When editing together feels like sitting next to someone, you use it differently — more often, for shorter sessions, which is how good pairing actually works.
Give it a week as your primary editor. The muscle memory cost is low if you come from VSCode (the keybindings overlap substantially). The performance floor is higher. You’ll stop noticing your editor, which is exactly what you want.