Zed DeltaDB Review 2026 — Version Control for the Agent Era, or Local History With Extra Steps?
✅ Pros
- • Every operation between commits gets a stable identity, so you can rewind to any moment in a file's evolution — not just the last commit — and branch from mid-run states
- • Conversation-code linkage is the real differentiator: each delta is recorded side by side with the agent message that produced it, and references anchor to deltas rather than line numbers, so they survive code movement
- • Conflict-free replicated worktrees (CRDT-based) mean multiple people and agents can edit the same files simultaneously across machines, and the worktree is real — agents work in it through a terminal and you can mount it to disk
- • Branching is effectively free thanks to the virtualized worktree, and any point in history is a valid branch point, including the middle of an agent run
- • ACP support means it works with Codex and Claude Code via Custom Agent, not just Zed's own Zen Agent — omp.sh users can wire it in today
⚠️ Cons
- • Early access only: beta lands 'in a few weeks' and access is via waitlist — no pricing, no self-host docs, no way to evaluate it hands-on right now
- • The problem it solves is contested: HN split between 'big unsolved dev tooling problem' and 'a non-existent problem that nobody asked to solve' (pknopf), with several users pointing at JetBrains Local History and jj as existing answers
- • Micromanagement fear is real: 'it invites people to scrutinize the process, instead of the results' (drdexebtjl) — conversation logs as performance review material is a genuine governance risk
- • It arrives amid a wave of core-editor complaints — stale file trees on WSL (NoDodgeQuestion), copy/paste issues on Linux Wayland (yza), and a GitHub issue where Zed shows file contents that don't match reality (JaggedJax) — and many users wish the team would fix those first
- • The landing page is confusing: quacker counted out-of-context jargon ('virtualize the worktree', 'branch mid-run') and had to read two blog posts to learn it's a CRDT collaboration layer on top of git
Agent-heavy teams that want to review, branch, and collaborate on the work happening between commits — especially remote or multi-agent workflows where conversation context is the actual source of truth
Zed editor: Personal plan free (no AI), Pro includes Zed-hosted models and unlimited Edit Predictions, Business adds org-level admin controls; DeltaDB itself is early access via waitlist with pricing not yet announced
Quick Verdict
Zed DeltaDB is the most philosophically interesting dev-tool announcement of the week — and one of the most divisive on Hacker News (247 points). The thesis, from Zed’s blog: “Software is made between commits.” Git was designed around discrete snapshots; agent-driven development produces a continuous conversation that generates code, and that conversation is becoming the true source of software. DeltaDB records every operation in between, gives each one a stable identity, and links every change to the conversation that produced it.
As a technical direction, it’s compelling and genuinely different from both Git and the JetBrains Local History feature HN kept comparing it to. As a shippable product today, it’s a waitlist landing page with a beta promised “in a few weeks.” That gap — ambitious thesis, not-yet-available product — is exactly why the community split so hard. 6.8 feels right: high on vision and architecture, low on availability and on evidence that people actually need it.
What DeltaDB Actually Is
DeltaDB is a layer on top of git, not a git replacement. Where Git captures a snapshot at each commit, DeltaDB captures a stream of fine-grained deltas — every operation in between — and gives each one a stable identity you can address. Four capabilities follow from that core choice:
- Rewind to any edit. Because every delta is addressable, you can point to the code at any moment in its evolution, even while it keeps changing.
- Trace code to conversation. A message and the edit it produced are recorded side by side. From any line of code, find the conversation that produced it — and every conversation that has touched it since. From any message, jump to the code it touched, either as it stands now or as it stood when the agent wrote it.
- Branch at any moment. The worktree is virtualized, so spinning up a new agent branch is effectively free. Any point in history is a valid branch point, including mid-run. Agents can also draw on history: they can pick up the context behind code they’re touching, or convene the prior agents that worked on it and ask why it’s written the way it is.
- Collaborate without committing. A teammate can join while work is still happening, talk to the agent that did the work, and annotate as they go — no commit-and-push ceremony first.
Under the hood, DeltaDB embeds conflict-free replicated worktrees, continuing the CRDT work Zed has been publishing for years. Multiple people and agents can edit the same files at once across machines. The files are real: agents edit them through a terminal, and you can mount the whole worktree to disk to use your own tools on it.
Zed’s stated intent for the ceremony around it: “Pull requests, review threads, and inline comments exist to reattach a discussion to code after the fact because the discussion and the code lived in separate places. Put them in the same place, and the ceremony disappears. Git and CI stay for what they’re good at.”
The ‘Isn’t This Just Local History?’ Debate
The most common HN objection was JetBrains Local History — the IDE feature that records every change and has been saving developers’ bacon for a decade-plus. esafak and usef- both cited it as the reference implementation, with usef- describing the exact rescue scenario: “I once accidentally wiped uncommitted work in the terminal, and brought up Local History to restore it in a click.”
alfalfasprout’s reply is the key distinction: “The idea is to tie conversations to code. This is a more sophisticated version of something like dolt, not a git replacement.” Local History records what changed; DeltaDB records why — the agent message, the reasoning, the conversation. And because references anchor to deltas instead of line numbers, they survive as the code moves underneath them.
The Jujutsu counterargument came from xlii: “Jujutsu already does this. I had agent screwing up changeset over a couple hour long session and it took one shell command to split on pieces with longer pause.” ibejoeb pushed back: “Jujutsu is great, but it does not do this. It has no knowledge of agent sessions.” That’s the crux — jj can split changesets, but it can’t tell you which conversation produced which change, and it can’t let a teammate join a live agent session mid-run.
The Micromanagement Fear
The most serious objection wasn’t technical. drdexebtjl: “Maybe I’m pessimistic, but I think this just gives micro-managers the data they need to micro-manage you. It invites people to scrutinize the process, instead of the results. Not once have I wished to review a colleague’s conversation with an AI. I want to review finished work. I can only imagine layoffs being justified with ‘bad prompt quality.’”
sanex was blunter: “I really don’t want management critiquing when I swear at Claude, thanks.” hollowturtle agreed: “A total nightmare and imo every dev should push back using this stuff.”
The counterargument came from mcintyre1994: “The sort of company that would do those things is going to be mandating you to use their enterprise AI plan anyway, which already lets them read all your conversations if they want to.” And giancarlostoro: “These sorts of paper trails are for developers not management — does your manager open all your commits and start commenting on them? If so, maybe apply somewhere else.” The governance question is real, but DeltaDB doesn’t create the surveillance capability; the enterprise AI plans already did.
The Availability Problem
Right now, DeltaDB is: an early-access landing page, a waitlist, and a beta “ready in a few weeks.” lrae noted there was a prior discussion in June (225 comments) and asked “Is it available now? Still seems to be a waitlist?” — yes, still a waitlist.
That’s the biggest practical gap between the thesis and the product. ralusek’s skeptical take captures the mood: “Can maybe think of one time in the last 10 years that I would have wanted this. Its only purpose is for training LLMs.” And visiondude prefers file-based artifacts: “The agent convo itself doesn’t add much value IMO and adds unnecessary bloat.”
The other pressure point: Zed’s core editor complaints have been piling up, and DeltaDB lands in that context. NoDodgeQuestion linked a GitHub discussion where Zed fails to show newly created files on WSL and refuses a refresh button. JaggedJax quit over a stale-tree issue: “I can’t use an editor where the file contents I’m being shown don’t match the reality of the file.” yza listed broken copy/paste and laggy file manager on Linux Wayland. umvi listed a dozen features he’d rather they build first. manmal’s summary: “Sticking to the basics will kill them IMO.”
ACP Support: The Practical Path
One bright spot for immediate use: DeltaDB works with anything speaking ACP, not just Zed’s Zen Agent. randomblock1: “It supports anything with ACP. So it can actually run Codex and Claude Code, not just the Zed Agent.” omp.sh supports ACP, so users can specify it as a Custom Agent in Zed and wire DeltaDB to terminal-based agents today. For people running Codex CLI or Claude Code inside Zed’s terminal, that’s the integration that makes the conversation-tracing story concrete rather than theoretical.
Pricing and Status
| Component | Cost / Status |
|---|---|
| Zed Personal plan | Free (no AI features) |
| Zed Pro | Includes Zed-hosted models, unlimited Edit Predictions |
| Zed Business | Org admin layer: model restrictions, data-sharing locks, unified billing |
| DeltaDB | Early access — waitlist signup; beta in a few weeks; pricing TBD |
Use Case: Who Should Actually Use This
The strongest concrete scenario comes from manzu: agent sessions that run long, produce many changes, and need to be reviewable as a whole. With DeltaDB you can branch from any point in an agent run, iterate infinitely, and keep every attempt — “you have infinite try and retry possibilities.” The early-collaboration workflow Zed describes is the second one: a teammate joins mid-run, talks to the agent directly, and annotates as the work happens, instead of waiting for a PR.
prinny_ flagged the most interesting future use: pinpointing exactly which change was made by whom when multiple people and agents work the same code simultaneously — which pairs with Zed’s async collaboration and instant-sharing plans.
FAQ
Is DeltaDB a replacement for Git? No. It’s a layer on top of git. Git and CI stay for checks and external integration; DeltaDB handles the work between commits.
When can I try it? It’s early access. The landing page takes waitlist signups; the beta is expected in a few weeks per Zed’s blog post.
Does it work with Claude Code or Codex? Yes, through ACP. Zed supports external agents via Custom Agent, and DeltaDB’s tracing applies to any ACP-speaking agent, not just Zen Agent.
Is this just JetBrains Local History? Local History records every change locally. DeltaDB additionally ties each change to the agent conversation that produced it, makes deltas addressable across machines via CRDTs, and virtualizes the worktree so branching mid-run is free.
Verdict
DeltaDB has the strongest thesis of any dev-tool launch this week: if agent conversations are becoming the source of software, then version control that can’t reference them is obsolete. The architecture — delta-addressable history, CRDT worktrees, conversation-code anchoring — is the right shape for that problem.
But it’s a waitlist today, it lands on top of a pile of unresolved core-editor complaints, and a large part of HN genuinely doesn’t believe the problem exists. Try it when the beta ships if you run agent-heavy workflows and want reviewable, branchable work between commits. Skip it if you’re happy with jj’s changeset splitting and JetBrains-style local history, or if the thought of your agent conversations becoming auditable company records makes you uneasy — that objection isn’t going away.