From the creators of Zed

Delta brings meaningnathanmaxantonio back to your code

Your conversations and code live in one place. Delta anchors every change, so your reasoning lives on with the results.

Download

Open Delta

Install the CLI

Zed

Trace dropped keystrokes in GPUI inputs

Review element cache invalidation rules

Cache SumTree node summaries

Fix IME candidate window positioning

Add scroll wheel phase events on macOS

Simplify Entity subscription cleanup

Reproduce stale text after window resize

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

Cache SumTree node summaries

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<T::Summary>,        children: Vec<SumTree<T>>,

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.

1 comment

repeated seeks over an unedited region are pure cache hits

do we have a benchmark proving this?

repeated seeks over an unedited region are pure cache hits

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.

$ 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.

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.

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<S> 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.

1 comment

closer to 5MB per 10M items

Can we link the benchmark for this estimate?

Changes

sum_tree.rs

cursor.rs

sum_tree.rscrates/sum_tree/src/

enum Node<T: Item> {22    Internal {23        height: u8,        summary: T::Summary,24        summary_cache: SummaryCache<T::Summary>,25        children: Vec<SumTree<T>>,26    },27    Leaf {28        items: Vec<T>,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<T>, 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;45pub use cursor::Cursor;6pub use sum_tree::{Item, SumTree, Summary};7pub use summary_cache::SummaryCache;

Two ways in, one foundation

Work in the Delta app or from your terminal. DeltaDB keeps both in the same thread.

First-party harness

Delta, the app

Threads with your team and your agents, side by side.

Desktop
Web
Mobile

Download the app

The agent you already use

Delta CLI Beta

Share a session, and a teammate joins from their own.

Claude Code
Pi (coming soon)

Install the CLI

DeltaDB, underneath both

The version control system that records every edit with the conversation behind it. A thread shared from Claude Code can be joined from the Delta app, and the other way around.

Learn about DeltaDB

One agentWhat changes

Model: Claude, then GPT, then Gemini
Harness: Claude Code, then Delta app
Runtime: Laptop, then Cloud Runner
Context window: Holds eight deltas. As each new one enters on the right, the oldest leaves on the left and is recorded in DeltaDB.

Record in DeltaDBWhat persists

Swap the model, the harness, or the machine. Every change, and the conversation behind it, stays in DeltaDB.

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

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.

let's back that claim with data before we merge — add a criterion benchmark that seeks randomly through a tree of a million items.

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 ThreadCopy Link

Invite by email, comma separatedInvite

nathansoboOwner

General AccessOnly people invitedEveryone at ZedAnyone 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.

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.

do we have a benchmark proving this?

Edit crates/sum_tree/src/sum_tree.rs

pub struct Node<S> {    children: ArrayVec<Node<S>, MAX>,    /// Cached aggregate, keyed on `generation`.    summary_cache: SummaryCache<S>,}

mention that rebalancing also bumps the generation

Explore without losing the thread

Branch into a subthread to explore an idea with an agent. Bring what you learn back without cluttering the main conversation.

Speed up project search

Project search stalls for seconds in large monorepos. Profile a cold search and find where the time goes.

Thought 2 times, ran 3 commands, read 4 files

Most of it is ignore handling: the gitignore matcher is rebuilt for every directory we walk. Caching one matcher per worktree takes a cold search from 2.8s to 0.9s.

nice, let's land the cache. I also wonder if streaming matches as they arrive would feel faster than a quicker full search.

Your thread keeps running while you touch grass

Check on your thread from any device.

Learn about Cloud Runners

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

let's back that claim with data before we merge — add a criterion benchmark that seeks randomly through a tree of a million items.

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.

Same conversation and code wherever the thread runs.
Check in from desktop, web, or phone.
Free up your machine while long tasks run.

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.”

athas.dev @athasdev

“Git remembers the commit. This remembers everything between them, including the conversation that wrote the code.”

Digvijay Gujjarlapudi @digvijaysai_g

“Code and conversations stay perfectly linked, and it genuinely elevates the whole process.”

Jenil Desai @Jenxl_09

“Why does Delta feel so good?”

Ozzy @ozzy_build

“The conversations, the decisions, the work, and the history all in one place. Context might be the killer feature of the agentic era.”

Axel @itsmraxel

“The team at Zed kinda cooked with Delta.”

Sherlock @thesherlocker

“I love having all the changes and context in threads.”

Axel @itsmraxel

“This is AI agent native Slack, Google Docs, and Wave that I’ve been waiting for.”

zmanian @zmanian

“Reading code still matters, and I needed a proper interface to quickly jot down my comments and iterate quickly.”

Jan-Peter Dhallé @jempie_3

“This is the most excited I have ever been about a product.”

Andrew Atiya @atiya_ag

“Delta is the most beautiful piece of software I’ve used in a long time.”

athas.dev @athasdev

“Git remembers the commit. This remembers everything between them, including the conversation that wrote the code.”

Digvijay Gujjarlapudi @digvijaysai_g

“Code and conversations stay perfectly linked, and it genuinely elevates the whole process.”

Jenil Desai @Jenxl_09

“Why does Delta feel so good?”

Ozzy @ozzy_build

“The conversations, the decisions, the work, and the history all in one place. Context might be the killer feature of the agentic era.”

Axel @itsmraxel

“The team at Zed kinda cooked with Delta.”

Sherlock @thesherlocker

“I love having all the changes and context in threads.”

Axel @itsmraxel

“This is AI agent native Slack, Google Docs, and Wave that I’ve been waiting for.”

zmanian @zmanian

“Reading code still matters, and I needed a proper interface to quickly jot down my comments and iterate quickly.”

Jan-Peter Dhallé @jempie_3

“This is the most excited I have ever been about a product.”

Andrew Atiya @atiya_ag

From the blog

News, product updates, and ideas from the team building Delta.

View all posts

Cloud Runners are now in Delta
Move a thread to the cloud and the agent keeps working without your computer.
Katie Geer Nov 11, 2026
Bring your Conductor conversations into Delta
Conductor is winding down. Here’s how to bring your chats into Delta.
Franciska Dethlefsen Nov 10, 2026
Building a thread UI on hard mode
We had to build a new kind of editor to support Delta's threads as rich, editable documents.
Agus Zubiaga Nov 9, 2026