Getting started with Zed's AI features: a first-week walkthrough
Published 2026-05-09 by Owner
Zed is the only mainstream AI editor that isn’t built on a VS Code fork. It’s written from scratch in Rust, and the AI features were grafted on after the editor existed — not the other way around. That shows up in two ways: the editor is fast in a way Cursor and Windsurf are not, and the AI surface area is noticeably smaller than what those tools offer.
This guide is for someone who has used Cursor or Copilot and is curious about whether Zed is worth a real try. I’ll cover what’s there, what’s missing, and the configuration steps to get a working setup.
Install and first run
brew install --cask zed
# or download from zed.devOpen a project. The first thing you’ll notice is the editor opens in well under a second on a 50k-line repo, and scrolling is buttery in a way that VS Code-derived editors are not. This isn’t a feature-by-feature comparison point but it does change how the editor feels to use.
The AI features are gated behind a free Zed account or a bring-your-own-key configuration. Sign in via the assistant panel (Cmd+?) on first invocation, or skip the account and configure your own API keys.
Configuration is a JSON file
Zed has no settings UI. Every preference lives in ~/.config/zed/settings.json — open it with Cmd+,. This will feel either liberating or annoying depending on your background.
The minimal AI configuration:
{
"assistant": {
"default_model": {
"provider": "anthropic",
"model": "claude-3-5-sonnet-latest"
},
"version": "2"
},
"language_models": {
"anthropic": {
"api_url": "https://api.anthropic.com",
"available_models": [
{ "name": "claude-3-5-sonnet-latest", "max_tokens": 200000 }
]
}
}
}Set ANTHROPIC_API_KEY in your shell, restart Zed, and the assistant panel now uses your own key.
If you’d rather not manage keys, the Zed account gives you a small monthly quota of Claude and GPT requests included. Heavy users will exhaust this in a week.
The agent panel
Cmd+? opens the assistant. It’s a side panel, not a popup, which means you can keep it open while you edit and refer back to the conversation.
Three things to know about the panel:
It’s a thread, not a session. Every conversation is saved as a .zed-thread file. You can save it to your repo, share it with a teammate, or fork it as a starting point for a new conversation. This is closer to a Jupyter notebook model than a Cursor chat.
Slash commands are how you load context. /file path/to/x.ts adds a file to the context. /tab adds the current tab. /diagnostics adds the current LSP errors. /fetch <url> pulls a webpage into context. There’s no implicit codebase indexing — you tell the model what to read.
Edits are proposed as patches. When you ask the assistant to change code, it produces a patch view inline in the conversation. You apply it with a button. This is a different model from Cursor’s composer (which writes directly to files and shows you a multi-file diff). Zed’s approach is slower for big changes and clearer for small ones.
Inline edit predictions
Zed has its own autocomplete model called Zeta, which produces multi-line predictions in the editor. It’s free with a Zed account.
Zeta is good at:
- Continuing the obvious next line of code (loops, repetitive structures, test cases)
- Filling in idiomatic patterns it has seen before (Rust borrow patterns, async/await scaffolding)
- Finishing a function whose signature you just wrote
It is less good than Copilot or Cursor’s tab completion at:
- Pulling in context from other files in the project
- Inferring intent across function boundaries
- Long, business-logic-heavy completions
For a personal codebase or a Rust project where Zed’s training shows, Zeta is sufficient. For a complex TypeScript application with lots of cross-file types, you’ll likely want a model with better project context — which means using the assistant panel for those cases.
Slash commands worth memorizing
After a week, these are the ones I actually use:
/file <path>— load a file into the conversation context/tab— load whatever’s in the current tab/diagnostics— load all current LSP errors and warnings/symbols <pattern>— load matching symbols across the project/terminal— load recent terminal output/fetch <url>— load a web page (great for “fix this based on the linked error explanation”)
The discipline of explicit context is unfamiliar coming from Cursor, where the editor decides what to load. After a few days, I found I produced better results in Zed because I was forced to think about what the model needed to see. After two weeks, that discipline started to leak back into how I prompt other tools.
What’s missing
If you’re coming from Cursor, the gaps that will show up in week one:
No background agents. Zed’s AI is request-response. There’s no equivalent of Cursor’s background agent that runs in a separate session.
No multi-file composer. Zed will edit multiple files in one assistant turn, but the UX is patch-based, not project-wide. For a 10-file refactor, the experience is closer to Aider’s “one step at a time” than Cursor’s composer.
No web preview integration. If you’re doing UI work, you’ll be alt-tabbing between Zed and your browser. Cursor’s preview pane is genuinely useful for frontend work and has no Zed equivalent.
Smaller extension ecosystem. Zed has extensions, but the catalog is a fraction of VS Code’s. If you depend on a specific niche extension, check before you switch.
The verdict after one week
Zed is a real option for backend, systems, and Rust work. The editor performance and the explicit-context AI model are genuine advantages.
For frontend-heavy work or for teams whose workflow assumes Cursor-style background agents, Zed is missing too much. The trade-off is real, not just a question of preference.
The one-line summary: try Zed if your AI usage is “I want a fast editor with a competent assistant when I ask for one.” Stay on Cursor if your usage is “I want the editor to do work for me while I work on something else.” Both are legitimate, and they describe different workflows.
