Zed launches Delta, a multiplayer workspace for coding agents

Zed shipped Delta today, a standalone application for coding with AI agents and reviewing what they build, with the first private beta invites going out on August 12. It is not a Zed update. It is a second product from the same team, built on DeltaDB, the version control layer Zed opened a waitlist for in June.

The argument behind it is narrow and worth stating plainly. When an agent writes the code, the conversation that produced it is the most valuable artifact in the whole exchange, and every review tool we currently use throws that artifact away. Delta keeps the conversation and the worktree in one replicated store, so a comment can attach to a line of a diff, a step in a plan, or a thinking block, and stay attached as the code moves underneath it.

RelatedGitHub Moved Copilot Out of the Editor, and That Tells You a Lot

• Delta is a new desktop app, not a feature inside the Zed editor. Zed says DeltaDB will reach Zed eventually, but Delta is where it ships first.
• DeltaDB records a stream of fine-grained edits with stable identities instead of commit snapshots, and it works on top of an ordinary Git repo. Teammates who never install Delta still see a normal repository.
• Threads are multiplayer in real time. Every participant gets a synchronized local copy of the worktree, and any thread opens in a browser through the same Rust application compiled to WebAssembly and drawn with WebGL.
• Third-party agent harnesses connect as well, starting with Claude Code. A terminal session syncs live into a Delta thread that teammates can watch and comment on.

What did Zed actually ship?

A desktop client, a browser client, and the sync layer underneath both. Delta organizes work into threads. A thread holds the conversation with an agent and the worktree that conversation is editing, and both replicate to everyone invited. Threads stay private until you share them, and sharing is an invite, not a public link.

The cloud piece matters more than it sounds. You can push a running thread to a cloud runner, close the laptop, and the agent keeps working while its conversation and its code stay in sync with everyone else in the thread. Open the same thread on someone else's machine in a browser and you get the real client, not a stripped web viewer. Zed's own framing on that point is blunt: Delta.dev is the same Rust application compiled to WebAssembly, rendered through WebGL, rather than a JavaScript reimplementation.

Why build a new app instead of putting this in Zed?

Zed addressed this directly, and the reasoning is more interesting than the usual product-strategy boilerplate. Two things pushed them out of the editor. DeltaDB needed to develop without constraints so the database and its first client could shape each other, instead of forcing new primitives into an editor built around different assumptions. And retrofitting those foundations under hundreds of thousands of daily Zed users would have broken workflows those users depend on.

Underneath that is a bet about where the center of gravity sits. In Delta the conversation, not the file tree, is the primary document. Your cursor moves through the thread with the same keyboard motions you use on code, and you can respond anywhere in it rather than queueing serial messages into a box at the bottom. That is a different application shape than an editor with a chat panel bolted on, which is roughly what every competitor currently ships.

What does DeltaDB change about version control?

Git takes a snapshot at each commit. DeltaDB captures the operations in between and gives every one of them a stable identity. That sounds academic until you look at what it buys, which is anchoring.

Comments on a commit-based platform attach to a snapshot, so they go stale the moment the code changes. Anyone who has reopened a pull request after a force-push and found a thread of review comments pointing at lines that no longer exist knows this failure exactly. DeltaDB anchors a reference to a delta rather than a line number, so the reference survives the edit. You can comment on any line in the worktree, whether an agent touched it yesterday or a human wrote it three years ago, and the comment stays where it belongs.

The second piece is conflict-free replicated worktrees. Multiple people and multiple agents can edit the same files on different machines at once without a coordination step. That is what makes the multiplayer claim more than a shared screen: everyone holds a real local copy that converges.

Who is this actually for?

Teams whose review process has become the bottleneck, which is most teams running agents seriously. Agents produce more text and larger diffs than any human, and the standard coping mechanism is to hide things: collapse the diff, truncate the transcript, summarize what you were supposed to read. Zed is arguing that a company that spent a decade building text editors can just render all of it fast instead, and that the hiding was a rendering problem masquerading as an information problem.

RelatedRocky Linux's Founder Wants an Open AI Data Commons

The Claude Code integration is the pragmatic on-ramp here, and it is a smart one. You do not have to move your agent workflow into a new tool to try this. Keep the terminal you already use, let the session sync into a thread, and the collaboration layer wraps around what you were doing anyway. That lowers the adoption cost from "switch your whole team" to "one person shares a link."

1. Fall 2025Zed first floats the idea publicly no product attached to it yet
2. Jun 11, 2026DeltaDB announced, waitlist opens described as a version control system built on CRDTs, beta promised within weeks
3. Aug 12, 2026Delta announced, first private beta invites sent a separate app rather than a Zed feature
4. ComingMore beta invites, then DeltaDB inside Zed Zed says the editor keeps shipping and gets DeltaDB later

What are the open questions?

Several, and they are the kind that only a beta answers. There is no pricing. There is no stated position on self-hosting, which matters a great deal for anyone whose code cannot live in someone else's sync service, and a system that replicates every keystroke-level operation to a server is a bigger ask than pushing commits. Storage growth is an obvious question for a store that keeps every operation forever, and Zed has not published numbers on it.

Then there is the network effect problem in reverse. Delta's value comes from the thread being shared, so a single enthusiastic developer on a team gets a fraction of the benefit. Git interop softens this, since teammates who never open Delta still see a normal repo, but the review experience that justifies the product needs more than one participant. Claude Code is the only third-party harness named so far.

Our take

The insight is correct and slightly uncomfortable: pull requests were designed for a world where a human wrote every line and the reasoning lived in that human's head, retrievable by asking them. Agents broke both halves of that assumption. The diff got bigger and the author got harder to interrogate, and we responded by reviewing more code with less context than ever. Attaching the conversation to the code is the obvious fix, and it is genuinely surprising that a small editor company got there before the incumbents.

The risk is not the idea, it is the surface area. Zed is now maintaining an editor, a novel replicated database, a desktop client, and a WebAssembly browser client, and asking teams to route their review process through infrastructure that is eight weeks past its first public mention. Delta will get judged on whether it stays up and stays fast, not on whether the abstraction is elegant. Given that Zed's entire reputation was built on performance obsession, that is probably the fight they want.

Original analysis by GenZTech, based on Zed's Delta announcement.