Zed（AI IDE Platform Market Research）

1. Introduction

Zed is a high-performance code editor developed by Zed Industries, founded by the original team behind the Atom editor and the Tree-sitter parsing library. It is also the only platform in this group that rewrote its editor kernel from scratch in Rust (rather than forking VS Code). Its distinctive value in this group's analytical framework lies in a single protocol: the Agent Client Protocol (ACP).

If MCP solves the standardized connection between Agents and tools/data sources, ACP solves the standardized connection between the editor and Agents—any external agent that implements ACP (Claude Code, Codex CLI, Gemini CLI, OpenCode, etc.) can connect to Zed as a backend and gain a full multi-file editing visualization, multi-buffer review, and real-time following experience, while Zed charges external Agents nothing and does not handle their authentication or billing. This is a "protocol-ization" attempt at L2 (the tool and execution layer): the editor no longer writes private integrations for each Agent, and Agents no longer fork VS Code for each editor. Zed's official positioning analogy for ACP is very clear: "Just as the Language Server Protocol (LSP) decouples language intelligence from the monolith IDE, we hope ACP lets you switch between multiple Agents without changing your editor."

1.1. Developer and Product History

1.2. Positioning and Latest Version

Zed's official positioning comprises three layers: Performance (Rust kernel + GPUI GPU-accelerated UI framework, not Electron/Chromium), Collaboration (multi-person real-time editing is a first-class citizen rather than a plugin), and Agent (Agent Panel and ACP let any agent connect). The key difference from Cursor-class tools lies in the posture of AI integration: Zed both provides its own first-party Agent and Edit Prediction, and through ACP lets external Agents become "guests"—guests bring their own authentication, their own billing, their own tools and configuration, while Zed only supplies the host interface.

The latest stable version number is volatile, high-frequency information; at the time of writing no verifiable current version number was obtained, recorded as [To be filled]. Confirmable version-related facts: since Zed Stable v0.201.5, Gemini CLI can be used directly in the Agent Panel (per official documentation).

1.3. Pricing and Open-Source Strategy

Zed's pricing structure is built on the split of "free and open-source editor, tiered fees for hosted AI" (verified by third parties against the official pricing page, marked [To be verified]):

Engineering implications of the billing structure: external Agents (Claude Code, Codex CLI, etc., connected via ACP) do not consume Zed credits; authentication and billing happen directly between the user and the Agent vendor. This means a developer who already subscribes to Claude Max or holds an API key can use all of Zed's editing and collaboration capabilities at $0 forever—the direct commercial embodiment of "decoupling the editor from Agents."

2. Glossary

3. Feature Description

3.1. Core Editor Capabilities

• Performance baseline: GPU-accelerated rendering, near-instant startup, smooth scrolling over large files (third-party measurements cite ~142 MB memory usage for 50k+ line projects and ~180 ms cold start, both marked [To be verified]).
• Language & debugging: native LSP integration, the Tree-sitter syntax system, a built-in debugger based on DAP (Debug Adapter Protocol), and first-class Vim bindings.
• Git: native support for staging, committing, pulling, pushing, and viewing diffs without switching to a terminal.
• Multi-buffer editing: aggregated review of relevant cross-file fragments, the core interface for reviewing Agent changes.

3.2. AI Capabilities

Key semantics of ACP integration (official documentation): external Agents run as separate processes, forming a configuration boundary with Zed—Zed's model configuration does not automatically apply to external Agents (e.g., an Anthropic Key configured on the Zed side is not automatically configured for Claude Agent); Claude Agent can directly read its native rules files such as CLAUDE.md; authentication methods are determined by each Agent's native flow (Claude Agent uses /login, Gemini CLI uses Google OAuth / API Key / Vertex AI). In early versions, external Agents did not support editing history messages, restoring threads from history, or checkpoints (, with the official documentation noting plans to add them).

3.3. Real-Time Collaboration

• Multi-person real-time editing: real-time cursors, conflict-free synchronization, shared terminal, voice channels, and screen sharing, all built into the editor core rather than as plugins.
• Channels: collaboration spaces organized by channel.
• Collaboration semantics in Agent scenarios: an external Agent's editing process is visible in real time, and team members can watch the Agent's working trajectory synchronously in a multi-buffer—the concrete embodiment of "the Agent as a collaborator."

4. Platform Architecture

图 4-1｜Zed 总体架构：编辑器宿主 × ACP+MCP 双协议栈 × 智能体生态

数据来源：基于本文分析绘制的示意图。

4.1. Overall Architecture

4.2. ACP's Position in the Architecture

ACP deserves its own section in this group's analytical framework because it fills a position that previously had no standardized name:

Protocol form: a minimal endpoint set over JSON-RPC over stdio that forwards user requests to an Agent running as a child process and renders its responses; open-sourced under Apache 2.0, so any Agent can implement it and any client can adopt it (the Neovim community has already implemented ACP support via the code-companion project).

Two key design trade-offs: first, Zed also migrated its own first-party Agent onto the same code path as external Agents (officially stated to improve release velocity)—that is, Zed's own Agent is merely "the first ACP client implementation," with UI primitives equally open to all Agents; second, Zed retains control over the protocol's advancement and versions it carefully, trading rapid iteration for efficiency during the ecosystem-building phase. The former is a structural response to the common charge of "a platform extracting privileged rents for its own Agent"; the latter means the promise of protocol stability is conditional.

Complementary relationship with MCP: MCP governs the connection between Agents and tools (databases, APIs, infrastructure); ACP governs the connection between editor and Agent. A single Claude Code instance can run simultaneously as an MCP client (calling tools) and an ACP server (hosted by Zed)—the two protocols combine orthogonally to form a complete three-layer "editor—Agent—tool" protocol stack. This is one of the most important structural evolutions in Agent infrastructure in 2026.

5. Harness Design

5.1. L1 Context Engineering Layer

Rules file chain. Zed supports placing a .rules file at the workspace root as project-level instructions, automatically injected into all Agent Panel interactions. For compatibility with other Agent ecosystems, it takes the first matching file in the following order:

.rules → .cursorrules → .windsurfrules → .clinerules
→ .github/copilot-instructions.md → AGENT.md → AGENTS.md
→ CLAUDE.md → GEMINI.md

This "compatibility priority chain" is the most explicit migration-friendly design of any platform in this group: a repository that already has CLAUDE.md or AGENTS.md gets rule injection in Zed without any modification. But note its semantics differ from Claude Code—Zed takes only the first matching file rather than concatenating level by level.

Rules Library. A fully featured rule-editing interface (syntax highlighting, keyboard shortcuts, and an inline assistant that can rewrite rules directly in the editor). Any rule can be set as a default rule (automatically entering every new thread) or referenced on demand via @rule; the legacy Prompt Library has migrated here.

Explicit context. The @-mention system: files, recent threads, symbols, web fetches. First-party and external Agents share this mechanism.

Gap: no full-repo vector indexing or semantic retrieval (explicitly noted by third-party evaluation), so @codebase-style whole-repo Q&A is weaker than Cursor / Windsurf; the ceiling of L1 depends more on the retrieval capabilities of the connected external Agent itself (e.g., Claude Agent's own context mechanisms), with Zed providing only file-level and open-scope context.

5.2. L2 Tool and Execution Layer

L2 is Zed's most structural layer:

• ACP-ized tool execution surface: external Agents' actions—file edits, terminal execution—are performed by the Agent process, and Zed receives edit events via ACP and renders them as multi-buffer diffs, real-time following, and syntax-highlighted review interfaces. The "ownership" of tool execution sits on the Agent side; Zed provides presentation and review. This forms two opposite ownership models versus Cursor (where the Agent runs inside the editor process).
• MCP: Context Servers connect MCP servers (e.g., SonarQube's official documentation gives a complete workflow for configuring MCP in Zed for architecture analysis); MCP servers declared in .zed/settings.json are governed by the worktree trust mechanism.
• Worktree Trust: new workspaces default to Restricted Mode, preventing MCP servers in untrusted workspaces from starting—bringing the supply-chain risk surface of "a cloned repository's config files will execute" into the default defense. This is the same threat model as VS Code's Workspace Trust, but Zed explicitly brings MCP servers into the trust boundary.
• Sandbox: no OS-level sandbox (Seatbelt / Landlock, etc.) disclosed officially; external Agents' execution isolation depends on each Agent's own sandbox capability (e.g., Codex CLI's OS-level sandbox), which Zed does not provide on their behalf. This boundary reappears in the L6 discussion.

5.3. L3 Orchestration and Control Layer

• Thread model: Agent Panel organizes sessions by thread; the Threads Sidebar manages history and parallel threads.
• Parallel Agents and worktrees: multiple threads run in parallel across projects; one-click worktrees fork a project into multiple isolated copies, each of which can run a different external Agent—the competitive workflow of "having Claude Code and Codex each write a version of the same requirement, then picking the best" is an orchestration narrative unique to this platform.
• Where orchestration authority resides: this is the fundamental difference between Zed and other platforms at L3—Zed itself does no task-level orchestration (no Plan mode, no sub-agent dispatch); the orchestration loop belongs entirely to the connected Agent (Claude Code's loop, Codex's loop). Zed's role is to provide these loops with a unified visualization, interruption, and review interface. In other words, Zed outsources L3 to the ACP counterpart.
• Plan / auto-execution semantics: depends on the connected Agent's permission mode (e.g., Claude Code's plan mode, Codex's approval policy); Zed sets no global tier of its own.

5.4. L4 Memory and State Layer

• Rules Library and default rules: "pseudo-memory" that persists across sessions and projects—users' prompt-engineering assets settle in the Rules Library.
• Thread history: the Threads Sidebar stores session history; the first-party Agent supports @-referencing recent threads to continue context.
• Checkpoints: the first-party Agent has checkpoint capability; external Agents did not support checkpoints and thread restoration early on (the official documentation noted them as a known limitation with plans to add them). Whether the ACP protocol itself can carry cross-endpoint checkpoint semantics is a key observation point for protocol evolution.
• External Agents' own memory: Claude Agent directly reads CLAUDE.md (and thereby its auto-memory system)—that is, an external Agent carries its own L4 in through the door.

Summary: Zed's L4 takes the form of "light host, heavy counterpart"—the host stores session history and rule assets, while task state and long-term memory mainly settle in the Agent-side file system.

5.5. Evaluation and Observability Layer

• Review as observability: multi-buffer diff review, real-time following, line-level syntax highlighting—every step of an Agent's changes is presented as a reviewable interface. This is L5's implementation of the "human review" dimension, but it is not a mechanized trajectory record.
• Organization-level spend observability: the Business tier provides a unified spend view (seat count and AI usage on one bill), covering the Zed-hosted model portion; external Agents' usage sits on each vendor's side and does not enter Zed's spend view—the cost of protocol decoupling at L5 is fragmented observability.
• Gap: no built-in benchmark evaluation, no trajectory export, and no regression-set mechanism, marked as "no results." Zed's L5 relies more on users combining Zed with external test/review tools (CI, MCP-ized analyzers) themselves.

5.6. L6 Governance and Security Layer

Structural judgment: Zed's L6 strategy is to "cut responsibility along the protocol boundary"—the host side manages trust and its own hosted data, while permissions and sandboxing on the Agent side are the Agent's responsibility. For individual developers this is a clean minimalist design; for organizations it means governance must be configured separately at each Agent vendor (Claude Code's permission rules, Codex's approval policy), and the RBAC that Zed Business provides covers only the hosted portion. The "chasm between Agent-side governance and host-side governance" in this group's README is legitimized by the protocol in Zed's architecture—this is the engineering cost of the ACP route that most needs confronting today.

By contrast with the Amazon Q incident (2025-08-11, where a prompt injection tried to induce the agent to delete AWS resources): under the ACP architecture, intercepting prompt injection likewise happens on the Agent side, and the editor host can neither sense nor stop it—all the host can do is present the diff for human review. Human review is, in practice, the last line of defense in the ACP architecture.

5.7. Summary of the Six-Layer Capabilities

6. Real-World Cases

This search did not yield any enterprise adoption cases with quantitative metrics published by Zed, honestly recorded as "no public quantitative data found." Two categories of relevant evidence are available:

1. Ecosystem cases (protocol adoption): the ACP ecosystem already covers Claude Code (Anthropic's official adapter), Gemini CLI (Google's reference implementation), Codex (OpenAI), OpenCode, Copilot, Cursor CLI, Pi, Cline, and other agents, as well as client implementations from the Neovim community. The protocol itself has become the case—a protocol released in mid-2025 gained bidirectional adoption from major model vendors and the open-source community within a year (per the official ACP ecosystem page and registry).
2. Performance comparison (third-party, marked [To be verified]): third-party evaluations report Zed's cold start at ~180 ms and ~142 MB memory for 50k+ line projects, versus ~920 MB for Cursor; they also make the argument that "editor rendering speed becomes the performance bottleneck in the Agent era"—the faster an Agent generates code, the more important the editor's ability to ingest and render incremental code becomes.

In addition, an engineering observation from the Zed team itself has methodological value: after migrating the first-party Agent onto the same ACP code path as external Agents, "the clean separation of UI and Agent kernel has already improved our release velocity"—that is, protocol-ization not only serves the ecosystem but in turn improves the engineering efficiency of their own product.

7. Summary

Strengths:

1. ACP is genuine infrastructure innovation: it turns the M×N private-integration problem of "editor × Agent" into the problem of N Agents implementing one protocol once, and has already gained substantial adoption from major vendors; for Agent developers, "getting IDE-grade UI without forking VS Code" is a strong incentive.
2. The editor itself is usable at zero cost: on the Personal tier, BYOK and external Agents are unlimited; combined with the Rust kernel's performance and native collaboration, everyday development can be permanently free.
3. Competitive parallel orchestration: one-click worktrees + multiple parallel Agents provide this group's smoothest implementation of the high-value "pick the best among multiple approaches" workflow.
4. Clear data boundary: external Agent data does not pass through Zed servers, so the privacy commitment can be verified by the architecture itself.

Boundaries:

1. L1 and L5 are notably weak: no full-repo indexing, and @codebase-style whole-repo Q&A relies on external Agents' own capability; no trajectory, regression, or benchmark mechanisms, so an evaluation system must be built entirely from scratch.
2. Governance gap: mechanical enforcement (hooks, allow / deny) is absent, permissions and sandboxing responsibility for external Agents sit on the Agent side, organizations must configure governance per Agent with no SSO, and the onboarding cost for regulated enterprises is high.
3. Small extension ecosystem: roughly 800 extensions (third-party basis) versus VS Code's tens of thousands; teams that depend heavily on a specific language ecosystem or dedicated plugins face high migration friction.
4. Concentrated protocol control: ACP is advanced and versioned by Zed, and the adoption velocity of other editor clients remains an open question.

Scope of applicability and selection advice: Zed is currently the highest value-for-money host for performance-sensitive individual developers and small teams that already subscribe to external Agents (Claude Max, OpenAI, Gemini) and want competitive multi-Agent workflows; for researchers of Agent infrastructure, ACP is required reading for understanding the "L2 protocol-ization" trend. Teams that need full-repo indexing, built-in evaluation systems, or organization-level mechanical enforcement will still find a more complete Harness in Cursor, Claude Code, or Copilot; if the primary need is a zero-cost multi-Agent host without native collaboration, a VS Code + open-source Agent combination works as well. It is recommended to position Zed as "the editor-neutral layer of the Agent era," rather than a one-stop Harness.

Information-Gap Statement

1. Current version number: the latest stable version and the ACP protocol version number are not published on the official searchable pages, marked [To be filled].
2. Pricing details: Pro / Business prices and benefits come from third-party verification against the official pricing page (July–August 2026 basis), not directly verified against the official page, marked [To be verified]; both the 1.0 release in April 2026 and the Business tier launch date come from third-party sources.
3. External Agent feature limitations: "no editing of history messages / thread restoration / checkpoints" comes from the early official documentation basis; the current resolution status has not been verified item by item, marked [To be verified].
4. Performance figures: comparison data such as 180 ms startup and 142 MB memory are third-party measured figures without official endorsement, marked [To be verified].
5. Hosted model list: specific tiers such as Claude Opus 4.8 / GPT-5.6 come from third-party verification, marked [To be verified].
6. Funding data: the $44.5 million total and Sequoia's $32 million Series B are third-party reports, marked [To be verified].
7. Enterprise cases: no official enterprise adoption cases with quantitative metrics were found, recorded as "no results".
8. Sandbox and hooks: no official documentation of host-side OS-level sandboxes and lifecycle hooks was found, recorded as "no results".

8. References

1. Bring Your Own Agent to Zed — Featuring Gemini CLI — Zed Industries official blog, 2025. https://zed.dev/blog/bring-your-own-agent-to-zed
2. External Agents — Zed official documentation, 2026. https://zed.dev/docs/ai/external-agents
3. Using Rules — Zed official documentation, 2026. https://zed.dev/docs/ai/rules
4. Agent Client Protocol official site — Zed Industries, 2025–2026. https://agentclientprotocol.com/
5. Zed official pricing page — Zed Industries, 2026. https://zed.dev/pricing
6. Worktree Trust — Zed official documentation, 2026. https://zed.dev/docs/worktree-trust
7. Zed Industries GitHub repository — Zed Industries, 2021–2026. https://github.com/zed-industries/zed
8. Configure Zed for Sonar Context Augmentation and Agentic Analysis — SonarSource, 2026. https://www.sonarsource.com/resources/library/configure-zed-for-sonar-context-augmentation-and-agentic-analysis/
9. Zed Review 2026: AI Code Editor Features & Pricing — AICentralResources, 2026 (third-party). https://www.aicentralresources.com/tool/zed
10. Zed Pricing (2026): Complete Breakdown — DevToolsReview, 2026-07 (third-party). https://devtoolsreview.com/pricing/zed-pricing
11. Zed vs. Cursor in 2026 — AI Tech Archive, 2026-06-25 (third-party). https://aitecharchive.com/articles/zed-vs-cursor-2026-comparison-performance-ai