Zed, reviewed: the editor that puts the agent in the window

Zed is a code editor written in Rust that ships its AI surfaces, an inline edit prediction model and an agent panel, inside the core application instead of as extensions. The position taken here is that it is currently the strongest editor for work where an agent writes most of the code, and that the same decision makes it a poor fit for teams whose tooling depends on a large extension marketplace. Both halves of that judgement follow from one choice: Zed owns the whole stack, from the renderer to the agent loop.

It competes with VS Code and its fork Cursor, with JetBrains IDEs, and with running agents in a terminal beside the editor. What it replaces is the split workflow, editor on one side and agent command line on the other, by putting threads, diffs and terminals into the same window. The source is GPL-3.0-or-later with Apache-2.0 components where marked, developed by Zed Industries, a for-profit company, and the repository showed 91,400 stars and 10,900 forks when checked.

What it is

The stable channel is 1.22.0, published on 30 September 2026, and releases ship weekly rather than quarterly. The project grew out of Atom and Tree-sitter, the company publishes a roadmap next to the release notes, and it runs on macOS, Linux and Windows with no browser build; the README points at an open discussion for a web target. Collaboration, Git panels, language servers, tasks and a terminal are part of the editor rather than add-ons.

• Licence: GPL-3.0-or-later for the source, with Apache-2.0 components where marked. The company is for-profit and funded by subscriptions, not by selling the editor.
• Platforms: macOS, Linux and Windows, no web version. Remote work goes through SSH remotes and remote folders rather than a hosted IDE.
• Built in: multiplayer editing, Git panels, language servers, tasks and a terminal, none of which need an extension.
• Edit predictions: a hosted model with a provider switch (zed, copilot, none), 2,000 accepted predictions a month on the free plan and unlimited on Pro.
• Agent panel: Zed's own agent, external agents attached over the Agent Client Protocol, and terminal threads that run a command-line agent with its own login.
• Configuration: one JSON settings file with documented keys such as base_keymap, vim_mode, autosave and disable_ai, plus per-project .zed/settings.json.

How it works

Two request paths leave the buffer, and they behave nothing alike. The first is an edit prediction: once the cursor idles, the editor asks the model for a single ghost suggestion at the caret, which is accepted with tab or dismissed by typing on, and requests are debounced per provider. The second is an agent thread: a conversation with its own context window that reads the worktree, runs tools and terminals, and proposes a diff you review before anything is written. Predictions are off by default in files matching globs such as .env, .pem and .key.

What separates the two paths is review. A prediction lands as text you were already looking at; an agent's work lands as a diff with an accept-or-reject step, and threads that might touch the same files are meant to start in separate Git worktrees so two checkouts never collide. External agents attach over the Agent Client Protocol and keep their own configuration and authentication: the registry that Zed and JetBrains IDEs both read lists Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode and Gemini CLI, so an agent paid for elsewhere can run inside the editor without a second account.

Getting started

Almost everything user-facing lives in one JSON file, and the settings reference documents each key with its type and default. The snippet below is the shape of a considered setup rather than an install guide: a keymap for muscle memory from another editor, predictions kept out of build output, the threads sidebar moved where it does not fight the file tree, and AI left on.

{
  "base_keymap": "VSCode",
  "vim_mode": false,
  "autosave": "on_focus_change",
  "edit_predictions": {
    "provider": "zed",
    "disabled_globs": ["**/build/**", "**/dist/**", "..."]
  },
  "agent": {
    "threads_sidebar": {
      "position": "right",
      "default_width": 360
    }
  },
  "disable_ai": false
}

Four choices there are worth naming. base_keymap offers nine schemes, including VS Code, JetBrains, Sublime Text, Emacs and Cursor, so the decision to switch editors is not a decision to relearn shortcuts. edit_predictions.disabled_globs extends the inherited list with "..." instead of replacing it, and the defaults already exclude .env, .pem, .key, .cert and Zed's own settings files. agent.threads_sidebar.default_width accepts 200 to 800 pixels. And autosave takes off, on_focus_change, on_window_change or a delay, which matters more in a tool where an agent writes to the same buffers you do.

The agent surface

The panel holds three thread types, and the distinction matters more than the branding. A Zed agent thread uses Zed's settings, profiles, tools, skills and MCP servers; an external agent thread runs an ACP-integrated agent with its native configuration; a terminal thread runs a command-line agent or TUI that owns its own authentication. Everything else in the sidebar is bookkeeping around those three: threads are grouped by project, each keeps its own context window, and archive and history are one shortcut away.

• Threads Sidebar (cmd-alt-j): threads grouped by project with a status indicator and the agent that runs each one; terminal threads sit in the same list, and Thread History with cmd-g) holds archived and deleted-on-demand threads.
• Parallel threads: one prompt can keep running while a second thread takes a different task, and each thread may use a different agent, the built-in one here and Claude Code there.
• Worktree isolation: a thread started in a new Git worktree gets a detached HEAD checkout, so two agents writing at once cannot share a branch; you review the diff and merge through the normal Git workflow.
• External agents come from the ACP registry, which Zed and JetBrains IDEs both read, and installation happens inside the editor rather than through a config file.
• Layout: an agentic panel layout moves the agent surface to the left, agent.threads_sidebar.position puts the sidebar on either side, and agent.threads_sidebar.auto_open decides whether opening a folder opens the sidebar too.

The opinionated part: worktree isolation is the feature that justifies the rest. Agents that write into a shared checkout are how teams lose an afternoon to a branch two prompts wide, and Zed puts the guardrail in the product instead of in a convention document. The parallel sidebar then makes it cheap to run a migration thread next to a bug thread, which is where the design stops being a demo and starts being a workflow.

Pricing

The pricing page lists three tiers and the plans documentation adds a student plan. The editor costs nothing and needs no login; everything below is about hosted AI and the admin layer, which is the honest way to price an open-source editor whose value is the service around it.

• Personal: $0, forever. 2,000 accepted edit predictions, and unlimited use with your own API keys or external agents such as Claude Code and Codex CLI.
• Pro: $10 per month, unlimited predictions and $5 of tokens included, then usage-based billing at list price plus 10%; with the default spend limit that is $20 a month in total.
• Business: $30 per seat per month, org-wide AI policies, data-sharing controls, unified spend visibility and role-based access; no bundled token credit, and SSO, SAML and SCIM are listed as planned but not yet available.
• Student: free for one year with $10 a month in token credits and unlimited predictions, excluding the most expensive hosted models.

This is a defensible structure. The free plan is a real editor rather than a trial, because own keys and external agents are not held back; Pro is cheap as editors go, and the spend limit turns an open-ended token meter into a bill you can predict before the month starts. The catch is the one on every hosted model platform: list price plus 10% means Zed takes a margin on your Anthropic and OpenAI usage, which is reasonable for the convenience and worth checking if agent threads run all day.

Where it falls short

The weaknesses are the mirror image of the strengths. A curated plugin selection is the vendor's own phrase for its extension surface, and its comparison page puts VS Code at more than 10,000 extensions; anyone whose workflow rests on one specific extension should check for it before migrating. The performance figures, under one second startup, under ten milliseconds typing latency and about 600MB of memory, come from that same page and were not independently verified here. Hosted models cost list price plus a 10% margin, the Business admin layer has no SSO, SAML or SCIM yet, and there is no browser target at all.

• Extension ecosystem: the marketplace is deliberately small, and the migration guide's premise is that most VS Code extensions are built into Zed. That is true for Git, LSP and tasks, and false for anything specialised.
• Enterprise readiness: SSO, SAML and SCIM are planned rather than shipped, and order-form contracts only start at 25 seats.
• Evidence: the speed and memory numbers are self-reported by the vendor on a comparison page last updated on 1 May 2026; no third-party benchmark was found for this review.
• Reach: macOS, Linux and Windows only. No web build, so browser-based workstations and code-server style setups are not an option.

The honest boundary: Zed wins when the agent is the primary author and review happens in the window, and starts losing when the requirement is one specific extension or a fleet standardised on VS Code. The opinion worth disagreeing with is this: for a small team writing mostly with agents, Zed plus a registry agent is a better default than VS Code plus an extension, because the diff review and the worktree isolation are in the product rather than in a wiki. A team with a decade of VS Code muscle memory and a marketplace dependency should take the other side of that argument deliberately.

Verdict

Zed is the editor to take seriously if the agent does most of the writing, and the argument for it is ergonomic rather than ideological: one window, diffs you can reject, threads that cannot trample each other, and a bill capped by default. It should be rejected for reasons that are equally concrete, a missing extension, a browser requirement, a security review that needs SSO today. What it is not is a neutral choice, and pretending otherwise wastes a migration.

1. Take Zed when an agent writes most of the code and you want diff review and worktree isolation inside the editor instead of beside it.
2. Take it when a predictable bill matters: $10 of Pro plus a default $10 spend limit is $20 a month, and the free plan still runs own keys and external agents.
3. Take it when the machine has to feel fast: native rendering is the whole pitch, and the vendor's own figures are under one second startup and under ten milliseconds of typing latency.
4. Do not take it when a specific VS Code extension is load-bearing, or when the organisation standardises on an editor with a marketplace of 10,000+ extensions.
5. Do not take it when a browser-based editor, or SSO, SAML and SCIM today rather than on a roadmap, is a hard requirement.

VS Code won by being good enough for everyone. Zed wins by being excellent for developers who refuse to compromise on speed. — Zed editor comparison page, updated 1 May 2026

Sources

1. Zed pricing: Personal, Pro and Business tiers and the trial
2. Plans and pricing: spend limits, student plan and usage rates
3. All settings: base_keymap, vim_mode, edit_predictions, autosave, disable_ai
4. Parallel agents: threads sidebar, thread types and worktree isolation
5. Zed vs. VS Code comparison, updated 1 May 2026
6. The ACP Registry is Live, 28 January 2026
7. JetBrains: ACP Agent Registry is live in the IDEs
8. Zed on GitHub: licence, platforms and repository size
9. Stable releases: 1.22.0, 30 September 2026