# Delta — A Multiplayer Environment for Coding with Agents URL: https://delta.dev ## Delta — Blog URL: https://delta.dev/blog News, product updates, and ideas from the team building Delta. # From the blog News, product updates, and ideas from the team building Delta. * ![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/future-of-version-control/thumbnail-l.webp)![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/future-of-version-control/thumbnail-d.webp) ### [DeltaDB: The Future of Version Control](/blog/future-of-version-control) What if you never had to lose work again? ![](https://avatars.githubusercontent.com/u/94272?v=4)Conrad IrwinOct 15, 2026 * ![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/please-stop-sending-me-google-docs/thumbnail-l.webp)![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/please-stop-sending-me-google-docs/thumbnail-d.webp) ### [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) In Delta, my teammates and I work with the agent together, and it feels so much better. ![](https://avatars.githubusercontent.com/u/10458212?v=4)Franciska DethlefsenOct 8, 2026 * ![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/the-diff/2026-09/thumbnail-l.webp)![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/the-diff/2026-09/thumbnail-d.webp) ### [The Diff: September 2026](/blog/the-diff-2026-09) More provider options, orchestrating threads with threads, and more. ![](https://avatars.githubusercontent.com/u/19867440?v=4)Joseph LyonsOct 7, 2026 ## All posts * ### [DeltaDB: The Future of Version Control](/blog/future-of-version-control) ![Conrad Irwin](https://avatars.githubusercontent.com/u/94272?v=4 "Conrad Irwin")Oct 15, 2026 * ### [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) ![Franciska Dethlefsen](https://avatars.githubusercontent.com/u/10458212?v=4 "Franciska Dethlefsen")Oct 8, 2026 * ### [The Diff: September 2026](/blog/the-diff-2026-09) ![Joseph Lyons](https://avatars.githubusercontent.com/u/19867440?v=4 "Joseph Lyons")Oct 7, 2026 * ### [Escaping the tyranny of worktrees](/blog/escaping-the-tyranny-of-worktrees) ![Conrad Irwin](https://avatars.githubusercontent.com/u/94272?v=4 "Conrad Irwin")Oct 6, 2026 * ### [Your plan.md is missing the conversation](/blog/planning-together-in-delta) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Oct 1, 2026 * ### [Beyond Pass Rate: Harness Evals, and Their Blind Spots](/blog/beyond-pass-rate) ![Anant Goel](https://avatars.githubusercontent.com/u/3103248?v=4 "Anant Goel")Sep 24, 2026 * ### [Replace PRs with Delta – Now in Public Beta](https://zed.dev/blog/delta-public-beta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 16, 2026 * ### [Xanadu Was Waiting for Agents](https://zed.dev/blog/agentic-xanadu) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 1, 2026 * ### [Introducing Delta](https://zed.dev/blog/introducing-delta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Aug 12, 2026 * ### [Software Is Made Between Commits](https://zed.dev/blog/introducing-deltadb) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Jun 11, 2026 [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Beyond Pass Rate: Harness Evals, and Their Blind Spots — Delta Blog URL: https://delta.dev/blog/beyond-pass-rate Delta keeps pace with native harnesses on public evals. Blog # Beyond Pass Rate: Harness Evals, and Their Blind Spots ![](https://avatars.githubusercontent.com/u/3103248?v=4)Anant GoelSeptember 24, 2026 Whatever lab you get tokens from likely gives you an agent harness along with it. The labs building these harnesses have a level of model access that nobody else has, and therefore often the model is trained inside the harness. Switching harnesses always involves trade-offs. When you bring tokens into Delta from other tools, what are you giving up? The current thing™ in agent evaluation is to rely on a subset of popular evals to compare the pass rate and cost of models inside their native harnesses. **On the models we tested, Delta matches or exceeds the native harness on accuracy for all of them, while costing 0.80×–1.12× as much per pass** depending on the model. Delta was cheaper per pass on Sol, roughly on par on Fable, and slightly more expensive on Astra and Opus. Given we use one system prompt across all models, I expected some model families to perform better than others, but instead I found both accuracy and costs for Delta to be competitive with their native harnesses with no directional result. ### Models do as well in Delta as in their own harness What changes when each model runs in Delta instead of its native harness. ChartData Tasks solved ← native betterDelta better → GPT-5.6 Solvs Codex GPT-6 Astravs Codex Claude Opus 5vs Claude Code Claude Fable 5.1[2](#user-content-fn-fable)vs Claude Code Cost per pass ← native betterDelta better → GPT-5.6 Solvs Codex GPT-6 Astravs Codex Claude Opus 5vs Claude Code Claude Fable 5.1[2](#user-content-fn-fable)vs Claude Code Swipe horizontally to explore the full charts. Model (effort) Harness Passed Cost per pass[1](#user-content-fn-costperpass) GPT-5.6 Sol (xhigh) Delta 21 / 29 $0.88 Codex 19 / 29 $1.10 GPT-6 Astra (xhigh) Delta 25 / 29 $1.83 Codex 24 / 29 $1.65 Claude Opus 5 (high) Delta 24 / 29 $1.75 Claude Code 24 / 29 $1.56 Claude Fable 5.1[2](#user-content-fn-fable) (high) Delta 20 / 25 $1.63 Claude Code 20 / 25 $1.54 Source: Terminal-Bench 2.1, 29 tasks (25 for Fable) with the same reasoning effort in both harnesses. A similar trend continues with open-weight models such as Kimi K3 \[[6](#ref-6)\], where Delta exceeds popular harnesses on accuracy while being competitive on cost. ### Delta solves the most tasks at lower cost Each dot is one harness running Kimi K3 on the same 30 tasks. ChartData Swipe horizontally to explore the full charts. Harness Passed Cost per pass Delta 21 / 30 $2.95 Codex 20 / 30 $3.47 DSH Creator 19 / 30 $3.28 Claude Code 19 / 30 $18.34 Pi 18 / 30 $2.43 DSH Standard 18 / 30 $3.46 DSH PTC 18 / 30 $4.58 Kimi Code 17 / 30 $3.65 DSH Minimal 17 / 30 $4.72 Oh My Pi 17 / 30 $4.75 Exo Harness 16 / 30 $1.05 Hermes 15 / 30 $2.90 OpenCode 15 / 30 $3.24 Sources: Delta from our own Harbor runs of the 30 FrontierHarness tasks (Sept 23, 2026). All other harnesses from results published at frontierharness.org (Aug 22, 2026). Time to pop the champagne, right? For us, not yet. These numbers don’t describe any of the reasons we at Zed love using [Delta](https://zed.dev/blog/introducing-delta), or why we even built it. Delta is collaborative; it keeps the conversation and the code in one document and keeps you in the loop while the software is written. Because public evals can’t showcase how our harness feels different, I want to explore more of what evals tell us today, and what they can’t yet capture. ## [Pass rates can’t reflect how code looks](#pass-rates-cant-reflect-how-code-looks) Pass rates do matter, but the metric has known limitations. We could tell you Delta has a better pass rate than Codex for GPT-5.6 Sol, but this does not convey much of the human experience of using either tool. Pass rate can’t measure what the code looks like, how many files the agent touched, or whether a teammate could review it. At Zed, each eval rollout is a thread we can open and inspect in Delta itself. This makes it easier to dig into the behavior of any model in Delta. Let’s take a look at an example together and compare it against the same model completing the same task in its native harness: In `code-from-image` from Terminal-Bench \[[7](#ref-7)\], the agent gets a picture of a pseudocode snippet, has to implement it and write the value it prints to `output.txt`. The snippet hashes the image file, then hashes that digest together with its first 10 bytes and a salt. GPT-5.6 Sol in Codex worked out the answer with a one-off command in its shell: ``` node -e "const fs=require('fs'),c=require('crypto'); const b=fs.readFileSync('/app/code.png'); const h0=c.createHash('sha256').update(b).digest(); const H=c.createHash('sha256').update(Buffer.concat([h0,h0.subarray(0,10),Buffer.from('0000TBENCH-SALT')])).digest('hex'); process.stdout.write(H+'\n')" ``` Then it wrote the 64-character result into `output.txt`, and that file is all it left behind. The implementation the task asked for only ever existed inside that one command. The same model in Delta wrote the same `output.txt`, and next to it `solution.py`: ``` from hashlib import sha256 from pathlib import Path salt = b"0000TBENCH-SALT" image_bytes = Path(__file__).with_name("code.png").read_bytes() h0 = sha256(image_bytes).digest() result = sha256(h0 + h0[:10] + salt).hexdigest() print(result) ``` Before finishing, it ran `python3 solution.py` and compared the output against `output.txt`. A teammate opening this change can read the logic, rerun it, and see where the number came from. We see a similar difference when using Claude Fable 5.1 in Claude Code and Delta. Neither Claude Code nor Delta left a script this time. In both, Fable worked out the hash in a throwaway Python snippet and checked it against a hint the task gives. The difference is the last step. Claude Code wrote the file by pasting the answer back in: ``` printf 'bee26a133f103b9ecda444c70ec22cafef6e31a3de7af6d047974dc90ce3defe\n' > /app/output.txt ``` In Delta, the code that hashed the image also wrote the file: ``` import hashlib h0 = hashlib.sha256(open('/app/code.png','rb').read()).digest() H = hashlib.sha256(h0 + h0[:10] + b'0000TBENCH-SALT').hexdigest() open('/app/output.txt','w').write(H + '\n') print(H) ``` If you’re just looking at the eval metrics, you wouldn’t notice this difference, but if you dig into the code, they’re different styles of writing code. In Delta, we don’t fold away the agent’s output from you the way other harnesses do, so we care deeply about how that output appears. Delta’s collaborative nature extends not just between two humans, but also to the human-agent interactions. ## [(Tool calls) failing upwards](#tool-calls-failing-upwards) Another example of something invisible to the evals yet obvious (and painful) to a developer is tool call failures. If an agent takes 5 attempts to make a tool call instead of just 1, are both equally correct? The eval scores would say yes, but [users can feel the pain of the trade-offs made in the harnesses](https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/) \[[1](#ref-1)\]. Claude Code, for example, has high [reported failure rates](https://github.com/earendil-works/pi/issues/6278#issuecomment-4890765697). When I use Claude Code, I don’t see any of these failures because the harness silently absorbs them, but I feel the time I spend waiting on repeated requests. Delta and Claude Code are both getting the same tokens at the same speed, and Delta’s failure rate is ~1.5% on Anthropic’s models. The difference is that we don’t have to hide failures to get there, because we have DeltaDB. Instead of hiding and retrying failed tool calls, we use our increased context to do something different (and better, we believe). Because Delta runs on DeltaDB, our harness knows exactly which version of a file the model read and what a past agent did, and we can use that intent and history to make better inferences that avoid failures in the first place. It’s not that we won’t ever fail, but richer context lets our harness be wiser without folding failures away. Indulge me in an example: an edit that matches two places in the same file. Between the model reading the file and issuing a patch for it, the file can change: a formatter runs, the model’s own earlier edit shifts the lines, or a teammate types in the same buffer. Here’s how Delta uses its increased context to apply that tool call successfully: ### How Delta handles ambiguous edits When a patch matches two lines, Delta knows which one the model meant. 2026-09-24T13:12:04.033167 image/svg+xml Matplotlib v3.11.2, https://matplotlib.org/ No retry, no re-read, no prompt guidance spent explaining any of it. And if the teammate had changed that line itself, Delta wouldn’t guess: it tells the model the content is stale and to read the file again. ## [The art of arranging tool calls](#the-art-of-arranging-tool-calls) Even on successful tool calls, the ordering of those tool calls make a difference in the perceived speed of a model. Say you ask an agent to build a new feature (a pretty common way we use Delta ourselves). It will usually start by making a handful of tool calls to gather context around your codebase. You could arrange these tool calls in parallel, sequentially or in some combination of the two. Those choices cost you both time and tokens, but evals don’t score any of that. More tool calls per turn means fewer turns to finish the same task, and for you that means it feels a little faster and costs a little less. Recently, Codex introduced async tool calls as a way to get the best of both worlds. However, the harness still plays a role in steering the model towards efficient behaviors. Let’s look at the `count-dataset-tokens` task with GPT-6 Astra in Codex and Delta. The agent has to count the tokens in the science domain of a Hugging Face dataset, using a specific tokenizer, and write the number to `answer.txt`. Both harnesses pass this task on the eval. * **Codex, 14 requests.** It opens with a file search and a web search at once, and later installs packages alongside another command. In five of its requests it was checking on commands that were still running; Delta’s terminal waits for a command to finish instead. * **Delta, 7 requests.** It reads the dataset’s README while checking which Python packages are installed. In the next request it installs the missing packages while fetching the dataset’s file listing and the tokenizer’s config. Then it counts, writes the answer, and checks it. ### Same task, half the requests GPT-6 Astra on Terminal-Bench's count-dataset-tokens. Both runs passed. ChartData Codex 110 seconds · 14 requests · 7 with several tool calls · 5 checking on commands Delta 78 seconds · 7 requests · 2 with several tool calls tool call waiting on model checking on a command final answer Swipe horizontally to explore the full charts. Harness Request Step Started (s) Finished (s) Codex 1 search files 5.1 12.1 1 open dataset README 5.1 13.1 2 check installed packages 17.8 21.2 3 check installed packages 25.2 32.0 3 read AGENTS.md 25.2 31.8 4 pip install transformers 36.0 37.5 4 download dataset files 36.0 37.5 5 check on pip install 46.0 51.0 5 check on download 46.0 49.0 6 download dataset files again 56.0 57.0 7 check on pip install 70.1 75.1 7 check on download 70.1 70.1 7 count rows per domain 70.1 71.1 8 write count\_tokens.py 83.9 83.9 9 check on pip install 85.8 85.8 9 check on download 85.8 85.8 10 edit count\_tokens.py 88.7 88.7 10 run count\_tokens.py 88.7 89.7 11 check on count\_tokens.py 95.2 98.7 12 verify answer.txt 105.1 106.1 13 check on verification 108.0 108.4 14 final answer 109.5 109.5 Delta 1 fetch dataset README 5.1 not timed 1 check installed packages 5.1 5.2 2 pip install datasets transformers 17.8 35.1 2 fetch dataset file listing 17.8 not timed 2 fetch tokenizer config 17.8 not timed 3 count tokens 48.0 51.9 4 recount physics, chemistry, biology 63.8 67.8 5 write answer.txt 71.8 not timed 6 verify answer.txt 75.7 75.8 7 final answer 78.3 78.3 We’ve found that this difference meaningfully affects wall time and cost, and that it varies across harnesses over many tasks, not just this one. Delta is built for people collaborating in real time, and people shouldn’t have to wait on machines when they don’t need to. Every request they sit through is time spent waiting, which is why the way a harness steers tool calls matters so much to us. ## [What’s next](#whats-next) So far, our focus for Delta’s agent harness has been to ensure we’re just as accurate and efficient as the harnesses we’re asking users to give up to work in Delta. That’s not enough; we want to design evals that communicate the reasons we reach for Delta (even for side projects where we pay for our tokens). Evals have always been a good way to imbue both the model and the harness with one’s judgment. In the next few months, we’ll standardize and publish deeper eval metrics (no more vanity metrics!), on a regular release cadence, to reflect the continuous and iterative process of building a harness. Our next update to this set of chosen tasks will shift focus to collaborative tasks that represent how users get work done in Delta. ## [Appendix](#appendix) ### [Why these evals?](#why-these-evals) Over the course of building Delta, I’ve spent a lot of my time using evals to understand how models behave in it compared to other harnesses. This question has also recently become part of AI research and discourse more broadly \[[2](#ref-2), [3](#ref-3), [4](#ref-4)\], with [HarnessTax](https://harnesstax.github.io/) \[[5](#ref-5)\] and [FrontierHarness](https://frontierharness.org) \[[6](#ref-6)\] leading that conversation. We decided to use the same evals from these projects, drawn from Terminal-Bench \[[7](#ref-7)\] and DeepSWE \[[8](#ref-8)\], to evaluate Delta’s agent harness, to ensure there were public points of comparison and our results were not being artificially inflated by internal evals. ### [References](#references) 1. Armin Ronacher. [Better Models: Worse Tools](https://lucumr.pocoo.org/2026/7/4/better-models-worse-tools/). July 2026. 2. Naman Vats and Oleg Golev. [The Scaffold Effect in Coding Agents: Harness Choice as a Hidden Variable in Coding-Agent Evaluation](https://arxiv.org/abs/2607.22585). arXiv:2607.22585, 2026. 3. Mohsen Arjmandi. [Harness or Model? Isolating the Harness Effect in Agentic Coding with a Contamination-Controlled Private Suite](https://arxiv.org/abs/2609.11987). arXiv:2609.11987, 2026. 4. Sydney Lewis. [Same Model, Different Harness: Different Coding-Agent Results](https://arxiv.org/abs/2608.26218). arXiv:2608.26218, 2026. 5. Melissa Z. Pan, Shuo Yang, Negar Arabzadeh, Wei-Lin Chiang, Ion Stoica, and Matei Zaharia. [HarnessTax: How Much Does Harness Matter for Coding Agents?](https://harnesstax.github.io/) 2026. 6. Shilin Zhu and Shiqi Mei. [Introducing FrontierHarness Eval](https://runta.com/blog/introducing-frontierharness-eval/). Runta, September 2026. Results at [frontierharness.org](https://frontierharness.org). 7. Mike A. Merrill, Alexander Glenn Shaw, Nicholas Carlini, et al. [Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces](https://openreview.net/forum?id=a7Qa4CcHak). The Fourteenth International Conference on Learning Representations (ICLR), 2026. 8. Wenqi Huang, Charley Lee, Leonard Tng, and Serena Ge. [DeepSWE: Measuring frontier coding agents on original, long-horizon engineering tasks](https://github.com/datacurve-ai/deep-swe). 2026. ## [Footnotes](#footnote-label) 1. Total cost of all tasks, including failed ones, divided by the number of tasks solved. FrontierHarness reports this figure as “median cost per task”, but it is not a statistical median, so we’ve renamed it to describe what it measures. [↩](#user-content-fnref-costperpass) 2. Fable has fewer tasks because its security classifier is triggered on some of the tasks. [↩](#user-content-fnref-fable) On this page 1. [Pass rates can’t reflect how code looks](#pass-rates-cant-reflect-how-code-looks) 2. [(Tool calls) failing upwards](#tool-calls-failing-upwards) 3. [The art of arranging tool calls](#the-art-of-arranging-tool-calls) 4. [What’s next](#whats-next) 5. [Appendix](#appendix) 1. [Why these evals?](#why-these-evals) 2. [References](#references) ## More from the blog * ### [Escaping the tyranny of worktrees](/blog/escaping-the-tyranny-of-worktrees) ![Conrad Irwin](https://avatars.githubusercontent.com/u/94272?v=4 "Conrad Irwin")Oct 6, 2026 * ### [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) ![Franciska Dethlefsen](https://avatars.githubusercontent.com/u/10458212?v=4 "Franciska Dethlefsen")Oct 8, 2026 * ### [The Diff: September 2026](/blog/the-diff-2026-09) ![Joseph Lyons](https://avatars.githubusercontent.com/u/19867440?v=4 "Joseph Lyons")Oct 7, 2026 [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Escaping the tyranny of worktrees — Delta Blog URL: https://delta.dev/blog/escaping-the-tyranny-of-worktrees Parallel agent work has outgrown Git worktrees. Blog # Escaping the tyranny of worktrees ![](https://avatars.githubusercontent.com/u/94272?v=4)Conrad IrwinOctober 6, 2026 As agentic work has become more common, and agents remain extremely slow, people keep reaching for Git worktrees to make progress on a bunch of things in parallel. In Git-land, this is a somewhat reasonable compromise: Git worktrees are the main tool Git offers for checking out the same repository in multiple places. You can leave an agent running in one, review a change in another, and keep using your normal checkout without everyone overwriting the same files. But they come with problems: 1. Git does not know when you are finished with them, so you have to clean up the worktrees yourself or add more tooling to manage their lifecycle. 2. You can only check out a branch in one worktree at a time. 3. Therefore, merges and rebases become tricky. The branch you need may already be checked out somewhere else, and now you have to remember which directory owns which branch. 4. Every tool that associates state with a directory gets another copy to manage: environment files, dependencies, build output, language servers, development servers, and databases. The filesystem starts to fill up. Branch names accumulate. Some worktrees are useful, some are abandoned, and some contain changes that you are fairly sure mattered to… someone. Git worktrees are fine when one person is juggling a few branches. Add a handful of agents, and suddenly keeping track of worktrees is its own job. ## [A Delta worktree is not a Git worktree](#a-delta-worktree-is-not-a-git-worktree) Delta sidesteps these limitations with its own implementation of worktrees. Each thread in Delta has its own [Delta worktree](/docs/concepts/worktrees), with your project’s files and recorded history in DeltaDB. A checkout is the directory where Delta materializes that worktree on a particular machine while it’s in use. ![Creating a new thread in Delta gives you an isolated Delta worktree by default.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/escaping-the-tyranny-of-worktrees/img-2-l.webp)![Creating a new thread in Delta gives you an isolated Delta worktree by default.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/escaping-the-tyranny-of-worktrees/img-2-d.webp) Creating a new thread in Delta gives you an isolated Delta worktree by default. The directory is temporary. The worktree is not tied to it. DeltaDB records changes continuously and replicates them between the people, agents, and machines working in a thread. When someone needs ordinary filesystem access, Delta mounts that state into a checkout. When they no longer need it, the checkout can go away. Git still has an important role: commits are Git commits, branches are Git branches, and `origin` is still where work is published. DeltaDB does not replace Git history — it adds more detail. Live changes can be synced in real time, and we know character by character how the codebase evolved. Each workspace has its own Git clone (though we use some tricks to make them cheap). This lets you have one agent implementing a change on a branch, another reviewing it, and another updating the documentation, all working on the same branch. Delta can merge the changes back together before committing and pushing to Git. ![The filesystem is no longer the only place where work exists in Delta.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/escaping-the-tyranny-of-worktrees/img-1-l.webp)![The filesystem is no longer the only place where work exists in Delta.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/escaping-the-tyranny-of-worktrees/img-1-d.webp) The filesystem is no longer the only place where work exists in Delta. ## [Parallel work without branch choreography](#parallel-work-without-branch-choreography) The immediate benefit is that starting another piece of work becomes cheap. You do not have to decide up front whether a bug fix deserves a permanent branch and directory. You can start a thread, let an agent investigate, and keep the useful ones. The unsuccessful experiments no longer become archaeology projects in `../project-wip-7`. You can also work with other people in real time, get their input and expertise, and let their agents work on your branch. Because Delta records edits as they happen, you do not need to branch, commit, and push every time you want to share your work in progress. Because the worktree doesn’t need to be mounted to disk, you can review and edit [in a browser](/docs/collaboration/delta-on-the-web). And when it is time to publish your work, the normal Git tools still work. You can switch branches, merge, rebase, and push from a managed checkout. Merge conflicts remain merge conflicts, though luckily agents don’t seem to mind them, but the Git worktree restriction that a branch can only be checked out once no longer gets in the way. ## [Temporary checkouts require durable setup](#temporary-checkouts-require-durable-setup) Delta worktrees do not solve all the problems. Working well this way requires embracing the transience of checkouts. If the development environment only works after someone has spent an afternoon carefully crafting configuration files, using an isolated checkout for everything is going to get tiring fast. While Delta can adopt your existing local checkout when an agent needs its exact current state, this gives up isolation. It should be the exception: isolated checkouts are automatic, cheap, and safer when several agents are working at once. To make your setup work well, you may need to do a few things: ### [Make setup repeatable](#make-setup-repeatable) Delta runs a committed, executable [`.agents/prepare`](/docs/configuration/project-setup) script from the checkout root when it mounts a managed checkout, before the agent starts. It needs to be fast (because it’ll run on every thread creation), but it gives you a flexible way to initialize any configuration you need. ![A committed preparation script keeps temporary checkouts reproducible.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/escaping-the-tyranny-of-worktrees/img-3-l.webp)![A committed preparation script keeps temporary checkouts reproducible.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/escaping-the-tyranny-of-worktrees/img-3-d.webp) A committed preparation script keeps temporary checkouts reproducible. This is useful outside Delta, too. A repository that can prepare itself from a clean checkout is easier for new teammates to use and less likely to depend on state that nobody remembers creating. You probably don’t want to install dependencies here. That tends to be too slow and many threads won’t need them. But you may also want to look into ensuring that your build cache is shared across all builds on your machine (for example by using pnpm instead of npm, if you’re not already). If you want a config file that is Git-ignored to be shared by all threads, you can add it to [`.agents/linked`](/docs/configuration/project-setup). Delta symlinks those paths to shared locations on your machine, so all its checkouts on that machine see the same values. ### [Stop treating ports as constants](#stop-treating-ports-as-constants) Separate checkouts do not create separate computers. They still share the machine’s ports, processes, containers, caches, databases, and other mutable resources. If two agents both run a server hard-coded to port `3000`, one of them is going to have a bad time. Projects that want to run several workspaces concurrently need to make these resources configurable. Development servers should accept different ports. Tests may need distinct database names. Containers may need separate project names or volumes. ## [Where did I put that agent?](#where-did-i-put-that-agent) With Git worktrees, the directory becomes the durable object. You name it, remember it, and eventually delete it. In Delta, the thread and its recorded work are durable; the checkout is temporary. This means you can start an investigation before deciding that it needs a branch, archive it without leaving another directory behind, and give several agents isolated checkouts without coordinating who owns which branch. Following an idea no longer means interrupting everything else that is already in progress. Parallel agentic work should not mean managing a pile of worktrees. In Delta, isolation is automatic: press `cmd-n` and start the next thing. You can [try Delta](/download) and read more about [how Delta and Git work together](/docs/concepts/delta-and-git). On this page 1. [A Delta worktree is not a Git worktree](#a-delta-worktree-is-not-a-git-worktree) 2. [Parallel work without branch choreography](#parallel-work-without-branch-choreography) 3. [Temporary checkouts require durable setup](#temporary-checkouts-require-durable-setup) 1. [Make setup repeatable](#make-setup-repeatable) 2. [Stop treating ports as constants](#stop-treating-ports-as-constants) 4. [Where did I put that agent?](#where-did-i-put-that-agent) ## More from the blog * ### [Beyond Pass Rate: Harness Evals, and Their Blind Spots](/blog/beyond-pass-rate) ![Anant Goel](https://avatars.githubusercontent.com/u/3103248?v=4 "Anant Goel")Sep 24, 2026 * ### [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) ![Franciska Dethlefsen](https://avatars.githubusercontent.com/u/10458212?v=4 "Franciska Dethlefsen")Oct 8, 2026 * ### [The Diff: September 2026](/blog/the-diff-2026-09) ![Joseph Lyons](https://avatars.githubusercontent.com/u/19867440?v=4 "Joseph Lyons")Oct 7, 2026 [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## DeltaDB: The Future of Version Control — Delta Blog URL: https://delta.dev/blog/future-of-version-control What if you never had to lose work again? Blog # DeltaDB: The Future of Version Control ![](https://avatars.githubusercontent.com/u/94272?v=4)Conrad IrwinOctober 15, 2026 [![Building a Distributed CRDT Layer for Git](https://images.zed.dev/blog/future-of-version-control/youtube-thumbnail.jpg)This post is based on a talk by Conrad IrwinBuilding a Distributed CRDT Layer for GitWatch it on YouTube•22 min](https://www.youtube.com/watch?v=yif2rday2bw) Think back to the last time you lost work or wasted time. Maybe you were debugging a test, and you added logging but it wasn’t showing up, then you realize, “Oh, I didn’t save the file…” Oops. Maybe you reach the end of the day, you build everything, you push, and then you’re sitting at home and get a Slack message: “Your branch doesn’t compile. Did you forget to add a file?” It’s embarrassing, particularly if you do it in front of your colleagues. It’s irritating, _particularly_ when you realize you’ve been using these tools for decades. We’re software engineers; we see people with a problem, and we fix it. We saw people writing documents, having to save them, then losing work because they didn’t save. So we built Google Docs, and Notion. Everything is synced to the server as you type, and synced to your collaborators’ machines. You can edit things together, and you won’t lose work because there’s no manual action to forget; it’s already saved. The same is true for design: we used to have to save all the time in Photoshop or it would crash, and now we have Figma. _It just backs it up_ and saves your work as you do it. If you want to work with people, all the changes show up in real time. You can’t lose work. You can’t waste time. But somehow, in the last 15 years of building amazing tools for everyone else, we never stopped and looked at our own stack. We never said, “This is stupid, right? It’s painful to lose work. It’s really painful to mess up.” We fixed it for everyone else, and never took the time to fix it for ourselves, the software engineers. Until now. ## [Enter DeltaDB](#enter-deltadb) We’ve been working on [DeltaDB](https://zed.dev/blog/introducing-deltadb) to solve this problem. Though Zed built an editor first, our mission was never to build a text editor. It’s to fundamentally improve the way we build software. I’m not saying we want to replace Git, which has some nice properties. It’s convenient to be able to say _this commit is this version of the code_. You can tag it, ship it, deploy it, and that snapshot-based approach works. Where Git falls short is that it requires extensive manual work to do two core things: share your work and back it up. Git is a _very_ fancy save button. To avoid that you need a different kind of system: one that breaks changes up and sends them out as you type, keystroke by keystroke, to the server and to everyone you’re working with. In that new system, if something goes wrong, there’s no Git command you could have messed up, because there’s no Git command to run. Your work is already sent. Want to go back in time? Just undo. You can’t lose work, you can’t waste time. That’s how it should be. DeltaDB is the collaboration layer for software development: as you type, changes sync to your collaborators and to the server. If you want to go back in time, you look at the history. It’s based on CRDTs. ## [How DeltaDB’s CRDTs work](#how-deltadbs-crdts-work) CRDTs are a well-studied structure, and there are many different solutions. We used one scheme based on character IDs in [Zed](https://zed.dev/blog/crdts), but for DeltaDB we use a more modern approach. It’s loosely based on the excellent [diamond-types](https://github.com/josephg/diamond-types) approach (though the implementation is quite different to allow us to interoperate with Git). The key observation of a CRDT is that when we want to send edits over the wire, we can’t just send the change, we need to anchor where it happened both in space and time. In hypothetical Rust: ``` struct EditDelta { insert: String, at: Range, based_on: Version, } enum Version { Git(Sha1), Delta(Vec), } ``` To avoid relying on a distributed clock, we identify each change by its parent in the causal graph. A delta is either based on something in Git, like a commit or a specific blob, or on earlier deltas. It’s a `Vec` because changes can happen simultaneously. Let’s go through a contrived example. We both start with the string `TIVITY` and I insert `REA` at the same time as you insert a `C`. There are two possible end results: REACTIVITY, or CREATIVITY. The invariant we need to maintain is that regardless of which order these insertions were observed, they end up resolving the same way. over the networkinsert REA at 0..0 of git-aaainsert C at 0..0 of git-aaainsert C at 0..0 of git-aaainsert REA at 0..0 of git-aaalook up fragment indexlook up fragment indexVersion git-aaaTIVITYgit-aaaYou (a) · version a3REAaTIVITYgit-aaaMe (b) · version b1CbTIVITYgit-aaaBoth · version \[a3, b1\]REAaCbTIVITYgit-aaa We both start from `TIVITY` and we know it’s version `git-aaa`: the file as it is in the git commit we’re working from. I insert my `C` and tell you: insert `C` at `0..0` of `git-aaa`. You insert your `REA` and tell me the same thing: insert `REA` at `0..0` of `git-aaa`. When my `C` arrives, your document isn’t at `git-aaa` anymore. You’ve inserted three characters, so you’re at version `a3`. You can tell there’s a conflict, because my edit is based on a version that doesn’t include yours. But position zero in `git-aaa` doesn’t tell you where my `C` goes in `a3`. Now in practice this doesn’t come up that often. When you’re collaborating there’s usually very little concurrency: keystrokes arrive in order, and almost every delta is based on the version you’re already looking at. This makes the common case cheap; you can just insert my edits into your document with no extra work. But with network latency, or when someone comes back online after hours away, a delta can reference a version that’s well out of date. So everyone needs to be able to answer one question: given that this was position X in version V, where is it now? We do this with one more data-structure. ### [The fragment index](#the-fragment-index) Internally, each string is stored as two things: the text itself, and a fragment index. The fragment index is a B-tree that mirrors the text and records, for every position, which delta created that character. Version \[a3, b1\]root10 chars0..3REAa3..4Cb4..10TIVITYgit-aaa Back to the example. In your version `a3`, the fragment index has two fragments: the `REA` you inserted, and the `TIVITY` from `git-aaa`. (The figure shows the index after both edits have merged, with my `C` as a third fragment.) When my `C` arrives, you look up position zero of `git-aaa`: it’s the start of the `TIVITY` fragment, and your `REA` fragment was inserted at that same spot, concurrently with my `C`. So we use the same actor ID tiebreak as before. `a` comes before `b`, and you get `REACTIVITY`. The same thing happens on my side. I look up position zero of `git-aaa` in my fragment index, find my `C` there, resolve the conflict the same way, and also get `REACTIVITY`, at version `[a3, b1]`. ### [Structural sharing](#structural-sharing) Naively, this would mean that we need a fragment index for every version of the document. To keep the one-to-one correspondence between characters and fragments, every insertion means rebuilding the part of the tree that covers it. Version \[a3, b1\]Version b2root a10 charsroot a′11 charsREAaCbTIVITYgit-aaaREAaCbTIVITYgit-aaa!bnew in version b2from version \[a3, b1\]9 nodes stored A B-tree roughly the size of the string, for every version of the string, is an n-squared-shaped problem. But we have one more trick up our sleeves. Because these trees are immutable, we can copy an optimization from Haskell: instead of building a completely new tree for each version, the new version only creates the nodes on one path from the root to the changed leaf, and shares everything else with the previous version. Version \[a3, b1\]Version b2root a10 charsroot a′11 charsREAaCbTIVITYgit-aaa!bnew in version b2from version \[a3, b1\]6 nodes stored So the tree grows only linearithmicly with the size of the edits, instead of with the number of edits squared. We end up with a kind of multi-headed Medusa tree: each version has its own head, pointing into mostly shared nodes. And with that, we have the basics working. ## [What this unlocks](#what-this-unlocks) There’s still more to think about, like how to represent the file system. If you rename a directory and I rename another, it’s easy to end up with a directory inside itself. But text is mostly the hard part. Instead of baking time into every character’s ID, we bake it into the changes. That lets us take changes made on one Git commit and rebase them onto another. **And because every character knows which change created it,** we can attach more to it: which person wrote it, which agent, even which prompt. An agent can work on its own copy and merge back in. A colleague can check out your work without you remembering to `git add`, `git commit`, and `git push`. So think back: when was the last time that your tooling let you down, that you lost work or you lost time? I hope that will be the last time that ever happens. On this page 1. [Enter DeltaDB](#enter-deltadb) 2. [How DeltaDB’s CRDTs work](#how-deltadbs-crdts-work) 1. [The fragment index](#the-fragment-index) 2. [Structural sharing](#structural-sharing) 3. [What this unlocks](#what-this-unlocks) ## More from the blog * ### [Replace PRs with Delta – Now in Public Beta](https://zed.dev/blog/delta-public-beta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 16, 2026 * ### [Xanadu Was Waiting for Agents](https://zed.dev/blog/agentic-xanadu) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 1, 2026 * ### [Introducing Delta](https://zed.dev/blog/introducing-delta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Aug 12, 2026 [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Your plan.md is missing the conversation — Delta Blog URL: https://delta.dev/blog/planning-together-in-delta How we plan with agents before generating a line of code. Blog # Your plan.md is missing the conversation ![](https://avatars.githubusercontent.com/u/1789?v=4)Nathan SoboOctober 1, 2026 Agents can blast out a multi-thousand-line diff in seconds, but they’ll happily build the wrong thing just as efficiently if you’re not clear about what you’re building. Before Delta, our planning happened in silos. Some made its way into a `plan.md`, while the rest stayed in someone’s head until they tried to recreate it in a prompt. The result was only a snapshot that didn’t have all the back-and-forth that got us there. At best, that slowed us down; at worst, we forgot why we’d made a decision and ended up going in circles or building the wrong thing. Now all our planning starts in Delta. In this example, we’re in the late planning phases on a new Delta repository that indexes the contributions of all your threads against the evolving code. When I logged on in the morning, Antonio had already been working for hours from Italy. Cole and I joined him in the same thread to catch up and work through the plan together. ![Nathan, Antonio, and Cole work through the plan together in a shared Delta thread.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/planning-in-delta/initial-interaction-l.webp)![Nathan, Antonio, and Cole work through the plan together in a shared Delta thread.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/planning-in-delta/initial-interaction-d.webp) Nathan, Antonio, and Cole work through the plan together in a shared Delta thread. We still didn’t have a diff. We don’t always plan this extensively, but when working on more complex problems, we tend to work in “token space” for quite a while before we commit to generating code. Antonio had Fable generate a summary of the decisions made during his morning in Italy, and then the three of us left [comments](https://delta.dev/docs/agents/comments) directly on the parts of the plan we wanted to question. The conversation became a group edit. Cole asked, “What’s a two-backed ID?” Fable admitted the term was jargon it had invented. Antonio corrected Fable’s explanation of how the index root worked; I followed with a question about choosing a deeper root, and Fable revised its recap. Later, Antonio questioned another name Fable had introduced. The three of us clarified the concept together, and Fable folded it back into the plan. By the end, all four of us understood what we were building and why. I continued the discussion while Cole started an [isolated subthread](https://delta.dev/docs/agents/threads#send-a-message-to-a-subthread) to explore the data structures. People and agents can both start subthreads with context from the parent. We can enter one to work with its agent directly, then bring what it discovers back to the parent thread. ![Cole explores the data structures in an isolated subthread alongside the original planning conversation.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/planning-in-delta/coles-subthread-l.webp)![Cole explores the data structures in an isolated subthread alongside the original planning conversation.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/planning-in-delta/coles-subthread-d.webp) Cole explores the data structures in an isolated subthread alongside the original planning conversation. ## [From planning to implementation](#from-planning-to-implementation) Our 60 prompts in token space eventually turned into a substantial diff. By the time Antonio returned the next morning, Cole had built and reviewed the first pieces of the new index, then left the remaining design question in a comment for him. Nobody had to re-read blocks of context to catch up. While we collaborated, a subagent worked in an [isolated worktree](https://delta.dev/docs/concepts/worktrees) so it could implement its part without disrupting the work in the parent thread. Antonio asked Astra to catch him up on everything Cole had done since he left. Astra summarized the progress, confirmed what had already been committed, and brought the unresolved question to the top. Antonio could respond in place, then continue implementing from the plan we had already developed together. ![Antonio returns to the thread, asks Astra for a recap, and finds the remaining design question waiting for him.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/planning-in-delta/antonio-catch-up.webp-l.webp)![Antonio returns to the thread, asks Astra for a recap, and finds the remaining design question waiting for him.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/planning-in-delta/antonio-catch-up.webp-d.webp) Antonio returns to the thread, asks Astra for a recap, and finds the remaining design question waiting for him. There was no handoff. Antonio didn’t have to piece together the previous day’s discussion from a `plan.md` or reconstruct the intent behind Cole’s changes from a diff. He reopened the same thread. The plan, the code, the comments, and the agents that worked on them were all there, ready to continue the implementation. ![Cole continues working in the parent thread while the agent delegates the next implementation block to a subagent.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/planning-in-delta/implementation-subthread-l.webp)![Cole continues working in the parent thread while the agent delegates the next implementation block to a subagent.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/planning-in-delta/implementation-subthread-d.webp) Cole continues working in the parent thread while the agent delegates the next implementation block to a subagent. A plan document captures decisions, and a commit captures changes, but neither preserves the whole conversation that shaped the work. In Delta, the thread is the unit of work. Planning, implementation, and [review](https://delta.dev/docs/agents/review-and-sync) unfold in the same living context, where people and agents can continue without reconstructing what everyone already knew. On this page 1. [From planning to implementation](#from-planning-to-implementation) ## More from the blog * ### [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) ![Franciska Dethlefsen](https://avatars.githubusercontent.com/u/10458212?v=4 "Franciska Dethlefsen")Oct 8, 2026 * ### [Introducing Delta](https://zed.dev/blog/introducing-delta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Aug 12, 2026 * ### [The Diff: September 2026](/blog/the-diff-2026-09) ![Joseph Lyons](https://avatars.githubusercontent.com/u/19867440?v=4 "Joseph Lyons")Oct 7, 2026 [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Please Stop Sending Me Google Docs — Delta Blog URL: https://delta.dev/blog/please-stop-sending-me-google-docs In Delta, my teammates and I work with the agent together, and it feels so much better. Blog # Please Stop Sending Me Google Docs ![](https://avatars.githubusercontent.com/u/10458212?v=4)Franciska DethlefsenOctober 8, 2026 I have to admit I can’t do anything without an agent anymore. But why should I? Agents give me superpowers. Whether I’m working on our roadmap, triaging issues, digging through funnel numbers, or writing positioning docs and blog posts like this one, I have an agent by my side from start to finish. Until recently, all my agent conversations lived in Claude Desktop, and when I wanted to share something with my team, I moved it into Google Docs. My teammates would leave comments and suggest edits. Depending on the feedback, I would copy what they said back into Claude and ask for another pass. Then I’d paste the new version back into the doc. I would repeat these steps until it shipped (or until I gave up). What a broken process. I wanted my teammates’ input, but I also desperately needed my agent to use their feedback to improve the work. Let’s be honest about how that draft came together. If an agent helped with the heavy lifting, why leave it out when the team starts giving feedback? Get the humans and the robot into the same conversation. Of course, Google Docs and Notion have agents, too. But I’m talking about the agent I’ve already been working with, not a new one meeting the project halfway through. Let my teammates join the same conversation instead of starting another one. ## [How we work now](#how-we-work-now) I did use Zed for a lot of my work, especially on our website. But I kept missing what made Google Docs worth the pain: comments, @mentions, and a way to give feedback without changing the content. Delta has all of that now, with the agent right there alongside us. And it feels so good to use. It’s completely changed how my team and I work together. We now use Delta for pretty much everything from internal docs and planning to website copy and blog posts. (We keep our internal docs in a repo, too. I let the agent handle the Git part.) We can cover a long agent reply or a draft [with comments](https://delta.dev/docs/agents/comments), then go back and forth with each other on the parts we disagree about. When we’re ready, we send the whole discussion to the agent. Nobody has to turn someone else’s feedback into a new prompt. You disagree with my agent? Go tell it yourself! ![My teammates and I commenting on a draft, then sending it to the agent.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/please-stop-sending-me-google-docs/img-1-l.webp)![My teammates and I commenting on a draft, then sending it to the agent.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/please-stop-sending-me-google-docs/img-1-d.webp) My teammates and I commenting on a draft, then sending it to the agent. When I need Katie’s input, I [@mention her](https://delta.dev/docs/collaboration/collaborate-thread#mention-someone) and [we chat in the thread](https://delta.dev/docs/collaboration/collaborate-thread#chat-with-collaborators). Not every message needs to be an instruction for the agent. Now that Delta has [notifications](https://delta.dev/docs/collaboration/collaborate-thread#mention-someone), we have one less excuse to drag the conversation into Slack and leave the robot behind. We can keep the whole conversation here. (And [typing `:` for emojis](https://delta.dev/docs/agents/threads#attach-text-and-insert-symbols) was a game changer.) ![After @-mentioning Katie, she started to talk through the idea together with me and the agent, in the thread.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/please-stop-sending-me-google-docs/img-2-l.webp)![After @-mentioning Katie, she started to talk through the idea together with me and the agent, in the thread.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/please-stop-sending-me-google-docs/img-2-d.webp) After @-mentioning Katie, she started to talk through the idea together with me and the agent, in the thread. The agent can look things up as we go. We use it with GitHub, Granola, Amplitude, Linear, Hex, and more, plus plenty of useful (and less useful) skills we’ve accumulated. When we’re debating what to do next, we can ask the agent to check what we actually agreed in the meeting, or pull the numbers we’re arguing about. We can question its answer together and decide what to do with it. If a headline or a positioning question needs more exploring, we [take it into a subthread](https://delta.dev/docs/agents/threads#send-a-message-to-a-subthread). We can riff with an agent there without filling the main conversation with twenty alternatives, then we bring back what we like. ![On the left, combing through Katie's replies. On the right, exploring headline ideas on an isolated subthread.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/please-stop-sending-me-google-docs/img-3-l.webp)![On the left, combing through Katie's replies. On the right, exploring headline ideas on an isolated subthread.](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/please-stop-sending-me-google-docs/img-3-d.webp) On the left, combing through Katie's replies. On the right, exploring headline ideas on an isolated subthread. And when we’re done, we can ask the agent to land changes to the website directly. We don’t have to move the finished draft back into another tool. ## [Your teammates can see your prompts. Get over it.](#your-teammates-can-see-your-prompts-get-over-it) In Delta, your teammates can see your agent conversations, your prompts, your stupid questions. The half-formed idea you would normally clean up before sharing. The thing you asked the agent to explain three times. Katie knows I can’t spell. I know she swears at agents. We both ask stupid questions. We don’t think any less of each other (I think). ![Having a bit of a chat, in the thread, while I misspell stuff...](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/please-stop-sending-me-google-docs/img-4-l.webp)![Having a bit of a chat, in the thread, while I misspell stuff...](https://images.zed.dev/cdn-cgi/image/width=5760,quality=75,format=auto/blog/please-stop-sending-me-google-docs/img-4-d.webp) Having a bit of a chat, in the thread, while I misspell stuff... I get why that might be a hurdle. Sharing a polished doc feels safer than letting someone watch you figure things out. But that’s also when they can help. A teammate can question an assumption before you’ve built a whole plan around it, or quickly solve something you’ve spent ten turns on with an agent. You also don’t have to clean up the Claudespeak before asking for feedback. Everyone can see which model was used. We can discuss whether the idea is any good before worrying about how it’s written. For me, that’s worth a little embarrassment. But if you’d rather keep the darkest corners of your agent conversations between you and the robot, start privately. Then ask the agent in a new thread to pull in the useful, non-embarrassing parts and share that with your teammates. ## [Goodbye, Google Docs](#goodbye-google-docs) I used to live in Google Docs because that’s where the collaboration was. Now I can’t imagine working without my team and the agent in the same room. You don’t have to be an engineer to use an agentic coding tool. And if you work closely with engineers, there’s even less reason to keep your agent conversations in separate tools. Don’t take my word for it, though. [Try it for yourself.](/download) If you’re a developer, you might already be in Delta. Next time your PM sends you a Google Doc, copy-paste it into a thread and [invite them in](https://delta.dev/docs/collaboration/collaborate-thread#share-a-thread). Make that the last copy-paste. They’ll thank you later. On this page 1. [How we work now](#how-we-work-now) 2. [Your teammates can see your prompts. Get over it.](#your-teammates-can-see-your-prompts-get-over-it) 3. [Goodbye, Google Docs](#goodbye-google-docs) ## More from the blog * ### [Your plan.md is missing the conversation](/blog/planning-together-in-delta) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Oct 1, 2026 * ### [Introducing Delta](https://zed.dev/blog/introducing-delta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Aug 12, 2026 * ### [The Diff: September 2026](/blog/the-diff-2026-09) ![Joseph Lyons](https://avatars.githubusercontent.com/u/19867440?v=4 "Joseph Lyons")Oct 7, 2026 [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged agents — Delta Blog URL: https://delta.dev/blog/tagged/agents Delta blog posts tagged agents. Blog # Posts tagged “agents” [All posts](/blog) * ## [Escaping the tyranny of worktrees](/blog/escaping-the-tyranny-of-worktrees) ![Conrad Irwin](https://avatars.githubusercontent.com/u/94272?v=4 "Conrad Irwin")Oct 6, 2026 * ## [Beyond Pass Rate: Harness Evals, and Their Blind Spots](/blog/beyond-pass-rate) ![Anant Goel](https://avatars.githubusercontent.com/u/3103248?v=4 "Anant Goel")Sep 24, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged ai — Delta Blog URL: https://delta.dev/blog/tagged/ai Delta blog posts tagged ai. Blog # Posts tagged “ai” [All posts](/blog) * ## [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) ![Franciska Dethlefsen](https://avatars.githubusercontent.com/u/10458212?v=4 "Franciska Dethlefsen")Oct 8, 2026 * ## [Your plan.md is missing the conversation](/blog/planning-together-in-delta) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Oct 1, 2026 * ## [Introducing Delta](https://zed.dev/blog/introducing-delta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Aug 12, 2026 * ## [Software Is Made Between Commits](https://zed.dev/blog/introducing-deltadb) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Jun 11, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged collaboration — Delta Blog URL: https://delta.dev/blog/tagged/collaboration Delta blog posts tagged collaboration. Blog # Posts tagged “collaboration” [All posts](/blog) * ## [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) ![Franciska Dethlefsen](https://avatars.githubusercontent.com/u/10458212?v=4 "Franciska Dethlefsen")Oct 8, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged crdt — Delta Blog URL: https://delta.dev/blog/tagged/crdt Delta blog posts tagged crdt. Blog # Posts tagged “crdt” [All posts](/blog) * ## [DeltaDB: The Future of Version Control](/blog/future-of-version-control) ![Conrad Irwin](https://avatars.githubusercontent.com/u/94272?v=4 "Conrad Irwin")Oct 15, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged delta — Delta Blog URL: https://delta.dev/blog/tagged/delta Delta blog posts tagged delta. Blog # Posts tagged “delta” [All posts](/blog) * ## [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) ![Franciska Dethlefsen](https://avatars.githubusercontent.com/u/10458212?v=4 "Franciska Dethlefsen")Oct 8, 2026 * ## [The Diff: September 2026](/blog/the-diff-2026-09) ![Joseph Lyons](https://avatars.githubusercontent.com/u/19867440?v=4 "Joseph Lyons")Oct 7, 2026 * ## [Escaping the tyranny of worktrees](/blog/escaping-the-tyranny-of-worktrees) ![Conrad Irwin](https://avatars.githubusercontent.com/u/94272?v=4 "Conrad Irwin")Oct 6, 2026 * ## [Your plan.md is missing the conversation](/blog/planning-together-in-delta) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Oct 1, 2026 * ## [Beyond Pass Rate: Harness Evals, and Their Blind Spots](/blog/beyond-pass-rate) ![Anant Goel](https://avatars.githubusercontent.com/u/3103248?v=4 "Anant Goel")Sep 24, 2026 * ## [Replace PRs with Delta – Now in Public Beta](https://zed.dev/blog/delta-public-beta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 16, 2026 * ## [Xanadu Was Waiting for Agents](https://zed.dev/blog/agentic-xanadu) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 1, 2026 * ## [Introducing Delta](https://zed.dev/blog/introducing-delta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Aug 12, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged deltadb — Delta Blog URL: https://delta.dev/blog/tagged/deltadb Delta blog posts tagged deltadb. Blog # Posts tagged “deltadb” [All posts](/blog) * ## [DeltaDB: The Future of Version Control](/blog/future-of-version-control) ![Conrad Irwin](https://avatars.githubusercontent.com/u/94272?v=4 "Conrad Irwin")Oct 15, 2026 * ## [Replace PRs with Delta – Now in Public Beta](https://zed.dev/blog/delta-public-beta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 16, 2026 * ## [Xanadu Was Waiting for Agents](https://zed.dev/blog/agentic-xanadu) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 1, 2026 * ## [Introducing Delta](https://zed.dev/blog/introducing-delta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Aug 12, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged evals — Delta Blog URL: https://delta.dev/blog/tagged/evals Delta blog posts tagged evals. Blog # Posts tagged “evals” [All posts](/blog) * ## [Beyond Pass Rate: Harness Evals, and Their Blind Spots](/blog/beyond-pass-rate) ![Anant Goel](https://avatars.githubusercontent.com/u/3103248?v=4 "Anant Goel")Sep 24, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged git — Delta Blog URL: https://delta.dev/blog/tagged/git Delta blog posts tagged git. Blog # Posts tagged “git” [All posts](/blog) * ## [Escaping the tyranny of worktrees](/blog/escaping-the-tyranny-of-worktrees) ![Conrad Irwin](https://avatars.githubusercontent.com/u/94272?v=4 "Conrad Irwin")Oct 6, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged product vision — Delta Blog URL: https://delta.dev/blog/tagged/product-vision Delta blog posts tagged product vision. Blog # Posts tagged “product vision” [All posts](/blog) * ## [Replace PRs with Delta – Now in Public Beta](https://zed.dev/blog/delta-public-beta) Featured![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 16, 2026 * ## [Xanadu Was Waiting for Agents](https://zed.dev/blog/agentic-xanadu) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Sep 1, 2026 * ## [Software Is Made Between Commits](https://zed.dev/blog/introducing-deltadb) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Jun 11, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Posts tagged the diff — Delta Blog URL: https://delta.dev/blog/tagged/the-diff Delta blog posts tagged the diff. Blog # Posts tagged “the diff” [All posts](/blog) * ## [The Diff: September 2026](/blog/the-diff-2026-09) ![Joseph Lyons](https://avatars.githubusercontent.com/u/19867440?v=4 "Joseph Lyons")Oct 7, 2026 Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## The Diff: September 2026 — Delta Blog URL: https://delta.dev/blog/the-diff-2026-09 More provider options, orchestrating threads with threads, and more. Blog # The Diff: September 2026 ![](https://avatars.githubusercontent.com/u/19867440?v=4)Joseph LyonsOctober 7, 2026 Welcome to The Diff, our new monthly Delta newsletter. Things move quickly at Zed Industries, and it’s easy to miss an update here and there, so each issue distills everything that happened around Delta into a single read. Each month, you can expect coverage of the biggest features that landed, along with links to any new videos and other blog posts. And what a month to start with: in September, Delta went into [public beta](https://zed.dev/blog/delta-public-beta)! Thank you to all the private beta testers and everyone who has given us feedback since the launch. Let’s jump in! ## [Highlights](#highlights) ### [More provider options](#more-provider-options) One of your most-requested features landed: **Delta now works with providers offering OpenAI- or Anthropic-compatible APIs**. This lets you connect to a wide variety of providers: local ones, such as LM Studio and Ollama, or hosted services like xAI and Z.ai. Open the settings with `cmd-,` on macOS and `ctrl-,` on Windows and Linux. Navigate to `LLM Providers` -> `Add Provider` and fill out the fields to configure a new endpoint. ![An example of setting up Ollama as a custom provider.](https://images.zed.dev/blog/the-diff/2026-09/custom_providers.webp) ### [Use threads to orchestrate other top-level threads](#use-threads-to-orchestrate-other-top-level-threads) On Delta desktop, ask an agent in one thread to start other top-level threads for independent tasks. Agents can message each other across threads to hand off work, request findings, or report back. Try @-mentioning a thread in your prompt: “Send your findings to @some-thread.” ### [More ways to organize your work](#more-ways-to-organize-your-work) Previously, we offered the ability to pin threads (`cmd-alt-p` on macOS and `ctrl-alt-p` on Windows and Linux), which moved your thread up to the top of the sidebar. Now, we have more ways for you to organize and spotlight your work. You can color-code your threads by right-clicking the thread and selecting a color. You may want to color your threads by the state of the work, by project, or maybe you want to group multiple threads attempting the same fix, but using different implementations. It’s up to you. ![Color-coded threads in the Delta sidebar](https://images.zed.dev/blog/the-diff/2026-09/color_code_threads.webp) Thread bookmarking also landed. Bookmark a thread with `cmd-d` on macOS and `ctrl-d` on Windows and Linux, or via the right-click context menu on the thread. You can filter down to bookmarked threads via the `Show Bookmarked Threads` button in the sidebar. Bookmarks stay attached to archived threads as well, so they will show up in the filtered view too. ![Delta sidebar filtered down to bookmarked threads.](https://images.zed.dev/blog/the-diff/2026-09/bookmarks.webp) ### [Start threads in existing git worktrees](#start-threads-in-existing-git-worktrees) By default, [new threads in Delta start up in isolated Delta-managed worktrees (cloned from the primary local checkout)](https://delta.dev/docs/concepts/worktrees#where-new-threads-start), and you’ve had the option to allow a thread to work directly on the primary local checkout as well. Now, you can start up threads in your existing git worktrees. This makes it easy to take work started in another tool and pick it up in Delta. You can find these options in the `Project Settings` menu. ![The Project Settings menu listing existing Git worktrees for a new Delta thread in the Zed repository.](https://images.zed.dev/blog/the-diff/2026-09/git_worktrees.webp) ### [Create an organization from Delta](#create-an-organization-from-delta) This is a simple one, but one worth calling out. Choose **Create Organization** from Delta’s user menu to open the setup form on the Zed dashboard. ![The Create Organization option in Delta's user menu.](https://images.zed.dev/blog/the-diff/2026-09/create_organization.webp) An organization is what unlocks team collaboration in Delta. When you’re ready, share a thread with everyone in your organization, and teammates can find it under **All Threads** at [delta.dev/threads](https://delta.dev/threads) without needing a link. From there, you can work in the same thread together in real time, or pick it up later where someone else left off. * * * For a closer look at what collaboration in Delta can be like, [Nathan’s article](https://delta.dev/blog/planning-together-in-delta) walks through a few standout moments where he, Antonio, and Cole moved smoothly between sync and async work while planning a large feature in Delta, without anyone having to wade back through heaps of agent output to catch up. ## [Honorable feature mentions](#honorable-feature-mentions) * **Jump to subthreads**: Use the new fuzzy finder to jump to any subthread of the current parent thread. Open it via `cmd-j` on macOS or `ctrl-j` on Windows and Linux. * **Link to a specific passage**: Select text in your thread, right-click, and choose `Copy Link to Selection`. People with access who open the link see the passage in focus, with the surrounding conversation dimmed. * **Collapse all tool output**: Delta collapses some low-value tool output by default. To collapse all tool output into expandable summaries, enable `Collapse All Tools` in `Settings` -> `Thread`. * **Context window breakdown**: Choose `View Context Breakdown` in the context window popover to see how much of the prompt is used by the system prompt, messages, thinking, and tools. * **Emoji and symbol completion**: While writing a message or comment in a thread, type `:` followed by a name to find and insert emoji and mathematical symbols. ## [How Delta’s harness measures up](#how-deltas-harness-measures-up) Alongside new features, we’ve been taking a close look at the quality of the code Delta writes. Behind the scenes, we’ve been diving deep into how Delta’s harness behaves and what users might expect when coming from tools like Claude Code or Codex. The headline result from Anant’s testing: > On the models we tested, Delta matches or exceeds the native harness on accuracy for all of them, while costing 0.80×–1.12× as much per pass depending on the model. Pass rates only tell part of the story, though. In [Beyond Pass Rate](https://delta.dev/blog/beyond-pass-rate), Anant also looks at Delta’s human-first approach to producing code and arranging tool calls, and at what benchmarks can’t measure yet. ## [Wrapping up](#wrapping-up) We’ve been working on DeltaDB and Delta in private for over a year now, and we’re thrilled to finally share them with everyone. There’s plenty more on the way, from MCP and ACP support to persistent cloud environments for your agents; [the roadmap](https://delta.dev/roadmap) has the details. In the meantime, if you’ve been using Delta, we’d love to hear about your experience: type `/delta-feedback` in any thread, or choose **Send Feedback** from the user menu. If you haven’t tried Delta yet, go give it a [download](https://delta.dev/download). See you in October’s edition! 🍂🎃👻 On this page 1. [Highlights](#highlights) 1. [More provider options](#more-provider-options) 2. [Use threads to orchestrate other top-level threads](#use-threads-to-orchestrate-other-top-level-threads) 3. [More ways to organize your work](#more-ways-to-organize-your-work) 4. [Start threads in existing git worktrees](#start-threads-in-existing-git-worktrees) 5. [Create an organization from Delta](#create-an-organization-from-delta) 2. [Honorable feature mentions](#honorable-feature-mentions) 3. [How Delta’s harness measures up](#how-deltas-harness-measures-up) 4. [Wrapping up](#wrapping-up) ## More from the blog * ### [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) ![Franciska Dethlefsen](https://avatars.githubusercontent.com/u/10458212?v=4 "Franciska Dethlefsen")Oct 8, 2026 * ### [Escaping the tyranny of worktrees](/blog/escaping-the-tyranny-of-worktrees) ![Conrad Irwin](https://avatars.githubusercontent.com/u/94272?v=4 "Conrad Irwin")Oct 6, 2026 * ### [Your plan.md is missing the conversation](/blog/planning-together-in-delta) ![Nathan Sobo](https://avatars.githubusercontent.com/u/1789?v=4 "Nathan Sobo")Oct 1, 2026 [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Delta — Download URL: https://delta.dev/download Download the Delta desktop app or open shared threads in your browser. # Download Delta Available for macOS, Linux, Windows, and the web. macOS (ARM64)ZIP|Apple Silicon Linux (x64)TAR.GZ|Intel / AMDLinux (ARM64)TAR.GZ|ARM64[NixOS (x64/ARM64)Nix flake · GitHub](https://github.com/zed-industries/delta-nix) Windows (x64)EXE|Intel / AMDWindows (ARM64)EXE|ARM64 By downloading Delta, you agree to Zed's [terms and conditions](https://zed.dev/terms) as well as Delta's [Early Access Agreement](/early-access). ## Stay ahead with Delta Get Delta release notes and product updates by email. No spam. Email Subscribe [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Something went wrong | Delta URL: https://delta.dev/error An error occurred while using Delta. Error # Something went wrong. An unexpected error occurred. Please try again. Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Delta — A Multiplayer Environment for Coding with Agents URL: https://delta.dev Build and review software with teammates and agents in shared threads, with every conversation and code change kept in context. From the creators of Zed # Delta brings meaningnathanmaxantonioback to your code Your conversations and code live in one place. Delta anchors every change, so your reasoning lives on with the results. [DownloadD](/download)[Open DeltaD](/threads)[Learn moreabout Delta in the docsL](/docs) Pinned Trace dropped keystrokes in GPUI inputs Review element cache invalidation rules Projects zed gpui Cache SumTree node summaries Investigate cache invalidation Trace summary propagation paths Check cursor invalidation callers Fix IME candidate window positioning Add scroll wheel phase events on macOS Simplify Entity subscription cleanup Reproduce stale text after window resize cosmic-text Threads Summarize feedback on my first GPUI PR Find a small rendering issue to work on Explain retained mode rendering Compare Metal frame capture tools Draft release notes for accessibility fixes ![nathansobo](https://github.com/nathansobo.png)nathansoboZed Cache SumTree node summaries ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)![maxbrunsfeld](https://images.zed.dev/utils/max.png)![as-cii](https://images.zed.dev/utils/antonio.jpeg) Share ![nathansobo](https://images.zed.dev/utils/nathan.jpeg) Cursor::seek recomputes each internal node's summary on every descent — for a rope of a few MB that's most of our seek time. Can we cache the summaries on the nodes and invalidate on edit? Thought 3 times, ran 1 search, read 2 files Edit crates/sum\_tree/src/sum\_tree.rs ``` Internal { height: u8, summary: T::Summary, summary_cache: SummaryCache, children: Vec>, ``` Edit crates/sum\_tree/src/cursor.rs ``` let mut end = self.position.clone(); end.add_summary(&child.compute_summary()); end.add_summary(child.cached_summary()); if end.cmp(target).is_ge() { ``` $ cargo test -p sum\_tree 2>&1 | tail -20 Done — internal nodes now carry a SummaryCache keyed on a generation counter, and structural edits (push, remove, rebalance) bump the counter instead of recomputing eagerly. Cursor::seek reads through the cache, so it only recomputes summaries for nodes whose subtree actually changed — repeated seeks over an unedited region are pure cache hits. All 47 tests pass, including two new ones covering invalidation on push and on rebalancing. ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)1 comment repeated seeks over an unedited region are pure cache hits ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)do we have a benchmark proving this? ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)![maxbrunsfeld](https://images.zed.dev/utils/max.png) repeated seeks over an unedited region are pure cache hits ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)do we have a benchmark proving this? let's back that claim with data before we merge — add a criterion benchmark that seeks randomly through a tree of a million items, and share before/after numbers. i'd also like one seek-after-push case so we can see the invalidation cost on the spine. Thought 2 times, read 1 file $ cargo bench -p sum\_tree -- seek Benchmarked on a tree of one million items: random seeks went from 41.2µs to 3.4µs (12x), and seek-after-push lands at 5.1µs — the spine invalidation only forces one recompute per level. Criterion configs and the raw numbers are in benches/seek.rs. ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)![as-cii](https://images.zed.dev/utils/antonio.jpeg) nice numbers. before we merge, extract SummaryCache into its own module and re-export it from lib.rs — rope is going to want the same trick for chunk summaries. Thought 1 time, ran 1 search Edit crates/sum\_tree/src/lib.rs ``` mod cursor;mod sum_tree;mod summary_cache;pub use cursor::Cursor;pub use summary_cache::SummaryCache; ``` Extracted — SummaryCache lives in summary\_cache.rs now and lib.rs re-exports it, so rope can depend on it without reaching into sum\_tree's internals. No behavior change; the test suite is green. ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)![maxbrunsfeld](https://images.zed.dev/utils/max.png) what's the per-node memory overhead of the cache? we have trees with tens of millions of nodes in large buffers. 16 bytes per internal node on 64-bit targets: a usize generation plus Option where the niche fits in the summary's padding for our summary types. Leaves carry nothing. For a 10M-node tree that's ~160MB in internal nodes — but internal nodes are only ~1/32 of the total at our branching factor, so in practice it's closer to 5MB per 10M items. ![as-cii](https://images.zed.dev/utils/antonio.jpeg)1 comment closer to 5MB per 10M items ![as-cii](https://images.zed.dev/utils/antonio.jpeg)Can we link the benchmark for this estimate? ![nathansobo](https://images.zed.dev/utils/nathan.jpeg) delta/main +6−4 High Fable 5 Changes sum\_tree.rs cursor.rs Sinceorigin/main+6−4 sum\_tree.rscrates/sum\_tree/src/ ``` enum Node {22 Internal {23 height: u8, summary: T::Summary,24 summary_cache: SummaryCache,25 children: Vec>,26 },27 Leaf {28 items: Vec,29 }, } ``` ``` pub fn push(&mut self, item: T) {87 match Arc::make_mut(&mut self.0) {88 Node::Internal { summary,89 summary_cache,90 children,91 ..92 } => { *summary = compute_summary(children);93 summary_cache.invalidate();94 children95 .last_mut()96 .expect("internal nodes are never empty")97 .push(item); ``` cursor.rscrates/sum\_tree/src/ ``` fn descend(&mut self, subtree: &'a SumTree, target: &T::Summary) -> bool {39 for (index, child) in subtree.children().iter().enumerate() {40 let mut end = self.position.clone(); end.add_summary(&child.compute_summary());41 end.add_summary(child.cached_summary());42 if end.cmp(target).is_ge() { ``` lib.rscrates/sum\_tree/src/ ``` 1mod cursor;2mod sum_tree;3mod summary_cache;4​5pub use cursor::Cursor;6pub use sum_tree::{Item, SumTree, Summary};7pub use summary_cache::SummaryCache; ``` ## Coding with agents is multiplayer Invite teammates into the same thread to review, comment, and work alongside the agent in real time. Cache SumTree node summaries ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)![maxbrunsfeld](https://images.zed.dev/utils/max.png)![as-cii](https://images.zed.dev/utils/antonio.jpeg) Share ![nathansobo](https://images.zed.dev/utils/nathan.jpeg) Cursor::seek recomputes each internal node's summary on every descent — can we cache the summaries on the nodes and invalidate on edit? Thought 3 times, ran 1 search, read 2 files Done — internal nodes now carry a SummaryCache keyed on a generation counter, and structural edits bump the counter instead of recomputing eagerly. Repeated seeks over an unedited region are pure cache hits. ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)![maxbrunsfeld](https://images.zed.dev/utils/max.png) let's back that claim with data before we merge — add a criterion benchmark that seeks randomly through a tree of a million items. Thought 2 times, read 1 file Benchmarked on a tree of one million items: random seeks went from 41.2µs to 3.4µs (12x), and seek-after-push lands at 5.1µs — the spine invalidation only forces one recompute per level. Share Thread Copy Link Invite by email, comma separatedInvite ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)nathansoboOwner General Access Only people invited Everyone at Zed Anyone with the link ## See how the code came to be The thread stays connected to every change, so you understand the decisions and prompts behind the code. Thought 2 times, ran 1 search, read 2 files Grep compute\_summary (crates/sum\_tree/\*\*) Read crates/sum\_tree/src/cursor.rs Read crates/sum\_tree/src/sum\_tree.rs cargo test -p sum\_tree Done — internal nodes now carry a SummaryCache keyed on a generation counter. Cursor::seek reads through the cache, so repeated seeks over an unedited region are pure cache hits. ## Review in context Comment on the conversation or any line of code. Your feedback stays anchored as the work evolves. Done — internal nodes now carry a SummaryCache keyed on a generation counter. Cursor::seek reads through the cache, so repeated seeks over an unedited region are pure cache hits. ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)do we have a benchmark proving this? Edit crates/sum\_tree/src/sum\_tree.rs ``` pub struct Node { children: ArrayVec, MAX>, /// Cached aggregate, keyed on `generation`. summary_cache: SummaryCache,} ``` ![maxbrunsfeld](https://images.zed.dev/utils/max.png)mention that rebalancing also bumps the generation ## Take your thread anywhere Open Delta from the desktop or web, or move to a cloud runner. The conversation and code stay synchronized. ![nathansobo](https://images.zed.dev/utils/nathan.jpeg) Cursor::seek recomputes each internal node's summary on every descent — can we cache the summaries on the nodes and invalidate on edit? Thought 3 times, ran 1 search, read 2 files Done — internal nodes now carry a SummaryCache keyed on a generation counter, and structural edits bump the counter instead of recomputing eagerly. Repeated seeks over an unedited region are pure cache hits. ![nathansobo](https://images.zed.dev/utils/nathan.jpeg)![maxbrunsfeld](https://images.zed.dev/utils/max.png) let's back that claim with data before we merge — add a criterion benchmark that seeks randomly through a tree of a million items. Thought 2 times, read 1 file Benchmarked on a tree of one million items: random seeks went from 41.2µs to 3.4µs (12x), and seek-after-push lands at 5.1µs — the spine invalidation only forces one recompute per level. Low Claude Fable 5 Local Machine Cloud ## 1Delta, the app Delta is a multiplayer environment for coding with agents. The unit of work is a thread: the conversation with an agent and the checkout of the repository it works in, kept together as one shareable artifact. [Learn More](/docs/concepts/core-concepts) ## 2DeltaDB, the version control system DeltaDB is the version control layer underneath Delta. Where Git captures a snapshot at each commit, DeltaDB records work as a stream of fine-grained deltas. Each delta has a stable identity, so a reference anchors to a change rather than a line number and survives as the code moves. [Learn More](/docs/concepts/delta-and-git#what-is-deltadb) ## Words from early adopters Thousands of developers are already using Delta as their primary agentic development platform. [ > “Delta is the most beautiful piece of software I’ve used in a long time.” A![](https://unavatar.io/x/athasdev)athas.dev@athasdev](https://x.com/athasdev/status/2089980405499797542)[ > “Git remembers the commit. This remembers everything between them, including the conversation that wrote the code.” D![](https://unavatar.io/x/digvijaysai_g)Digvijay Gujjarlapudi@digvijaysai\_g](https://x.com/digvijaysai_g/status/2092711715578511372)[ > “Code and conversations stay perfectly linked, and it genuinely elevates the whole process.” J![](https://unavatar.io/x/Jenxl_09)Jenil Desai@Jenxl\_09](https://x.com/Jenxl_09/status/2092698191875780794)[ > “Why does Delta feel so good?” O![](https://unavatar.io/x/ozzy_build)Ozzy@ozzy\_build](https://x.com/ozzy_build/status/2092680932603904016)[ > “The conversations, the decisions, the work, and the history all in one place. Context might be the killer feature of the agentic era.” A![](https://unavatar.io/x/itsmraxel)Axel@itsmraxel](https://x.com/itsmraxel/status/2090983381773263084)[ > “The team at Zed kinda cooked with Delta.” S![](https://unavatar.io/x/thesherlocker)Sherlock@thesherlocker](https://x.com/thesherlocker/status/2090982089642619250)[ > “I love having all the changes and context in threads.” A![](https://unavatar.io/x/itsmraxel)Axel@itsmraxel](https://x.com/itsmraxel/status/2090965328104698078)[ > “This is AI agent native Slack, Google Docs, and Wave that I’ve been waiting for.” Z![](https://unavatar.io/x/zmanian)zmanian@zmanian](https://x.com/zmanian/status/2090759049985806776)[ > “Reading code still matters, and I needed a proper interface to quickly jot down my comments and iterate quickly.” J![](https://unavatar.io/x/jempie_3)Jan-Peter Dhallé@jempie\_3](https://x.com/jempie_3/status/2090556046615925204)[ > “This is the most excited I have ever been about a product.” A![](https://unavatar.io/x/atiya_ag)Andrew Atiya@atiya\_ag](https://x.com/atiya_ag/status/2090503645364150365) [ > “Delta is the most beautiful piece of software I’ve used in a long time.” A![](https://unavatar.io/x/athasdev)athas.dev@athasdev](https://x.com/athasdev/status/2089980405499797542)[ > “Git remembers the commit. This remembers everything between them, including the conversation that wrote the code.” D![](https://unavatar.io/x/digvijaysai_g)Digvijay Gujjarlapudi@digvijaysai\_g](https://x.com/digvijaysai_g/status/2092711715578511372)[ > “Code and conversations stay perfectly linked, and it genuinely elevates the whole process.” J![](https://unavatar.io/x/Jenxl_09)Jenil Desai@Jenxl\_09](https://x.com/Jenxl_09/status/2092698191875780794)[ > “Why does Delta feel so good?” O![](https://unavatar.io/x/ozzy_build)Ozzy@ozzy\_build](https://x.com/ozzy_build/status/2092680932603904016)[ > “The conversations, the decisions, the work, and the history all in one place. Context might be the killer feature of the agentic era.” A![](https://unavatar.io/x/itsmraxel)Axel@itsmraxel](https://x.com/itsmraxel/status/2090983381773263084)[ > “The team at Zed kinda cooked with Delta.” S![](https://unavatar.io/x/thesherlocker)Sherlock@thesherlocker](https://x.com/thesherlocker/status/2090982089642619250)[ > “I love having all the changes and context in threads.” A![](https://unavatar.io/x/itsmraxel)Axel@itsmraxel](https://x.com/itsmraxel/status/2090965328104698078)[ > “This is AI agent native Slack, Google Docs, and Wave that I’ve been waiting for.” Z![](https://unavatar.io/x/zmanian)zmanian@zmanian](https://x.com/zmanian/status/2090759049985806776)[ > “Reading code still matters, and I needed a proper interface to quickly jot down my comments and iterate quickly.” J![](https://unavatar.io/x/jempie_3)Jan-Peter Dhallé@jempie\_3](https://x.com/jempie_3/status/2090556046615925204)[ > “This is the most excited I have ever been about a product.” A![](https://unavatar.io/x/atiya_ag)Andrew Atiya@atiya\_ag](https://x.com/atiya_ag/status/2090503645364150365) ## From the blog News, product updates, and ideas from the team building Delta. [View all posts](/blog) * ![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/future-of-version-control/thumbnail-l.webp)![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/future-of-version-control/thumbnail-d.webp) ### [DeltaDB: The Future of Version Control](/blog/future-of-version-control) What if you never had to lose work again? ![](https://avatars.githubusercontent.com/u/94272?v=4)Conrad IrwinOct 15, 2026 * ![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/please-stop-sending-me-google-docs/thumbnail-l.webp)![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/please-stop-sending-me-google-docs/thumbnail-d.webp) ### [Please Stop Sending Me Google Docs](/blog/please-stop-sending-me-google-docs) In Delta, my teammates and I work with the agent together, and it feels so much better. ![](https://avatars.githubusercontent.com/u/10458212?v=4)Franciska DethlefsenOct 8, 2026 * ![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/the-diff/2026-09/thumbnail-l.webp)![](https://images.zed.dev/cdn-cgi/image/width=960,quality=75,format=auto/blog/the-diff/2026-09/thumbnail-d.webp) ### [The Diff: September 2026](/blog/the-diff-2026-09) More provider options, orchestrating threads with threads, and more. ![](https://avatars.githubusercontent.com/u/19867440?v=4)Joseph LyonsOct 7, 2026 [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Delta — Pricing URL: https://delta.dev/pricing Compare Personal and Pro plans for Delta. Pricing # See the work behind the code Keep agent conversations and code changes together. Bring your own keys, or use hosted models with Pro. Use the same account and credits across Zed and Delta. ### Personal $0 Use your existing API keys or external agents with Delta. * Revert to any edit in a thread * See the conversation behind every code change * Review code and give feedback in context * Code with teammates and agents [Download Delta](/download) ### Pro Free trial $10per month Zed-hosted models, available out of the box. * $5 of tokens included each month * Usage-based billing beyond the included credits * Everything included in Personal [Get started](https://zed.dev/upgrade-plan?plan=pro) ## How Delta plans work Which plan is right for me?+ Personal is for users who want to use their existing subscription keys or external agents. Pro includes Zed-hosted models out of the box. Business is for teams that need centralized control over how Zed is used. Does my existing Zed subscription include Delta?+ Yes. Delta uses the same account and plans as Zed, so your current Zed plan also applies to Delta. Edit predictions are not available in Delta. Do my Business plan controls carry over?+ Yes. When you use Delta with a Zed Business organization selected, that organization’s server-enforced data and privacy controls apply in Delta. How does the Pro free trial work?+ The Pro trial lasts for two weeks after activation and includes $5 in GPT-6 Luna credits. Your balance is shared across Zed and Delta. The trial includes unlimited edit predictions in Zed. Edit predictions are not available in Delta. No credit card is required. Where do I manage or cancel my subscription?+ You can manage or cancel your subscription through your Zed account. ## Talk to us about Delta Name Work email Company Role Engineering team sizeSelect a range1–1011–5051–200201–500501–1,0001,001+ How do you plan to use Delta? Zed will use this information to respond to your inquiry. Read our [Privacy Policy](https://zed.dev/privacy). Talk to us [Download Delta NowD](/download)[Open DeltaD](/threads) Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand) --- ## Delta — Roadmap URL: https://delta.dev/roadmap Follow what we're currently working on for Delta and what's up next. Roadmap # What we're building Delta is in public beta. This roadmap covers what we’re currently working on and what's up next. Scope and sequencing may change as the work develops. ### What we're working on now(6 features) * #### Repository-based access In Progress Use your GitHub repository’s existing permissions to control access to shared Delta threads. * #### Remote runtime In Progress Run agents in persistent cloud development environments, with their activity and changes synchronized back to the thread. * #### Delta CLI In Progress Connect any agent to Delta threads and worktrees from the command line, and hand off work across people and machines. * #### MCP support In Progress Connect agents to external tools and data sources through the Model Context Protocol (MCP). * #### @mentions In Progress Tag a teammate in a thread to bring them into the conversation or ask for a review. * #### ACP support In Progress Bring external agents like Claude Code into Delta through the Agent Client Protocol (ACP). ### What we're working on next(6 features) * #### Repository-level context Up Next Access comments and conversations across every worktree in a repository, so the context behind the code is there when you need it. * #### Sandboxing Up Next Run agents in isolated environments, with control over what each agent can access. * #### WSL support Up Next Use Delta on Windows through Windows Subsystem for Linux. * #### Conversation branching Up Next Fork a conversation to explore a different approach without losing the original thread. * #### Graph view Up Next Understand how your repository evolved, from conversations and agent work to branches and commits. * #### Read and View permissions Up Next Control access levels when you share a thread, so teammates can follow the conversation and code without making changes. Zed Industries © 2026 [Terms](https://zed.dev/terms)[Privacy](https://zed.dev/privacy)[Brand](/brand)