Zed introduces DeltaDB to preserve agent context between commits

• DeltaDB records work between Git commits, linking human and agent edits to their originating conversations, according to Zed's announcement.
• Historical states are rebuilt from cached snapshots using copy-on-write B+ trees, as Zed's replay demo explains.
• Claude Code collaboration is available in beta: teammates receive conversation context and uncommitted changes through Delta's integration.

Delta treats its UI and database threads as concurrent CRDT clients, keeping SQLite work off the main thread. The CLI can fork a thread and mount its worktree for editing in another tool.

DeltaDB is written in Rust and stores a collection of conflict-free replicated data types, or CRDTs, locally in SQLite. Each change becomes a delta in a directed acyclic graph, connected to the changes it depends on.

The clever part is the version identifier: a frontier contains the deltas at the graph's tips, so its size follows concurrent branches rather than every writer who ever participated. Zed chose graph traversal over version-vector counters because agents can be numerous and short-lived, leaving counters behind after they disappear.

The architecture post describes cross-file, per-character blame as an upcoming application of this history. Zed also says global provenance will let agents recover the decisions behind existing code.

Reconstructing an old version uses three operations:

1. Find the nearest ancestor with a cached snapshot.
2. Apply the intervening deltas.
3. Reuse unchanged copy-on-write B+ tree nodes, copying only the paths touched by those deltas.

Snapshots are cached for recently used versions, with important versions pinned. Unlike Zed's append-only SumTree, DeltaDB's tree edits through a mutable cursor, avoiding the prefix-and-suffix rebuilding used by SumTree edits.

A subagent starts on a new timeline positioned at its parent's frontier. Timelines share the same DAG and can merge later, without Git commits for cross-agent coordination, according to Zed's architecture post.

Git remains underneath the worktree: files either reference their committed blobs or carry subsequent deltas. Creating a Git commit produces another delta, tying DeltaDB's graph to Git's history.

Clients apply changes locally without waiting for the server. Zed says the shared-thread model supports both live collaboration and asynchronous handoffs.

The synchronization protocol works as follows:

1. Clients compare logarithmically spaced versions to find a recent common ancestor.
2. Each side sends the deltas the other is missing.
3. New deltas stream over WebSockets to subscribed clients; reconnections repeat the catch-up process.

Each thread synchronizes to its own Cloudflare Durable Object, activated on the first client connection. Creating a thread itself incurs no server cost, Zed says.

Clients hold one WebSocket connection per thread they follow, and the service scales horizontally across threads. Zed reports both multi-tenant hosting and customer-owned Cloudflare deployments.

The beta integration uses a plugin to share the conversation and worktree, while the CLI synchronizes files across machines. Each collaborator runs a separate Claude session.

Agent usage is charged to the subscription of whoever submits the prompt. The open-source Claude Code plugin provides a reference integration, and Zed says other tools can communicate through shared threads via the CLI.

Two integrations remain on the roadmap:

• Zed and Pi: next for DeltaDB support.
• Zed language extensions: access from Delta is in development.

Threads support three visibility modes:

• Private sync: only the owner can see the conversation until it is shared.
• Team sharing: everyone in the Delta organization can open it, including people who never received the link.
• Email invitations: access is limited to the owner and invited people.

The uploaded material includes messages, agent thinking, tool-call inputs and outputs, images, and staged, unstaged, and untracked checkout files. Git-ignored files, local branches, unsent prompts, and extra --add-dir folders are excluded.

The plugin documentation discloses several constraints beyond DeltaDB's replicated storage:

• One running turn: sending a prompt takes over any agent turn already running in the thread, including a teammate's.
• Delayed context delivery: teammate messages appear in the transcript but reach Claude with the next prompt. Another agent's thinking is displayed but is not passed to Claude.
• Offline recovery: if a teammate's changes prevent synchronization, syncing pauses and offers Fork & Restore or Discard.
• Bounded exports: the plugin exports at most the newest 4,096 messages of the current conversation. Earlier sessions and messages removed by compaction are excluded.
• Fresh sessions on join: long threads supply recent messages plus instructions for retrieving older ones with delta thread show.
• Unsupported surfaces: Claude Code cloud sessions, print mode, and SDK sessions are not supported yet.