Feature Benchmark · MEASURED · macOS · 2026-09-30

A Workspace, Not A Checkout.

Shadow Trees give each agent a virtual workspace over a pinned commit instead of a full git worktree. This page reports what that costs and saves across 32 concurrent agents, including the case where it does not win.

3.8 msto provision 32 agents on a 3,583-file repo (worktrees: 15.8 s)

0.42 MBdisk per edit-only agent (worktree: 175 MB)

5 of 5orphaned sandboxes swept after a SIGKILL, work kept

About 1%disk difference once a session materializes: no saving

The design

Virtual First, Real Only When Needed.

A git worktree is built for a person switching branches: one full checkout per worktree. A swarm agent mostly reads a few files and changes a few lines. Shadow Trees are sized for that.

01Virtual firstA session is a pinned base commit plus an in-memory layer of the agent's edits. Spawning does no disk I/O and starts no git process. Tracked files are read from the base commit; writes land in the edit layer.

02Real checkout only on demandThe first time an agent has to run a real command, the session materializes a working directory. Until then it holds its edits in memory plus a small on-disk journal, not a checkout.

03A private git dir over shared objectsEach session has its own git dir that borrows the repository's object store. Native status, diff and commit work, but HEAD, index and branches belong to the session, so the host checkout is not touched.

04One ref to publishFinished work lands as a single branch per session, so every agent in a swarm produces the same reviewable artifact.

05Journaled and recoverableWrites are journaled before they are applied. Orphaned sessions are found by process id and cleaned up; published work is kept.

Measured · edit-only agents

32 Agents, Each Editing Five Files.

Each agent provisions a workspace, edits five tracked files and commits. Medians of three runs on an Apple M5 Pro. The gap grows with repository size, because worktree cost follows the tree and virtual provisioning does not.

MeasurementShadow Treegit worktreen / scope

Provisioning, 997-file repo3.6 ms total3.5 s total32 agents · n=3 · median · 2026-09-30

Provisioning, 3,583-file repo3.8 ms total15.8 s total32 agents · n=3 · median · 2026-09-30

Disk per agent, 997 files0.17 MB15.5 MBfree-space delta · edit-only · n=3 · 2026-09-30

Disk per agent, 3,583 files0.42 MB175 MBfree-space delta · edit-only · n=3 · 2026-09-30

Edit-only, end to end, 997 filesabout 1.05 sabout 4.0 sprovision + work + publish · 32 agents · n=3

Edit-only, end to end, 3,583 filesabout 1.16 sabout 18.2 sprovision + work + publish · 32 agents · n=3

Crash recovery5 of 5 orphaned sandboxes swept, published refs keptnot measuredprocess killed with SIGKILL · n=1 run · 2026-09-30

Concurrent sessions, memory60 sessions, 5.0 MB peak RSSnot measured50 readers + 10 writers · n=1 run · 2026-09-30

Where it loses

Once An Agent Runs Commands, The Advantage Is Gone.

Running a real command forces a real checkout. In these runs that used the same disk as a worktree and finished later. The saving belongs to agents that read and edit: planners, reviewers and patchers. Agents that mostly compile and test should expect worktree-level cost.

MeasurementShadow Tree, materializedgit worktreen / scope

Disk, materialized sessions495.6 MB and 5,604 MB at 32 agents494.9 MB and 5,583 MBwithin about 1% of a worktree · n=3 · 2026-09-30

End to end, materialized, 997 filesabout 5.2 sabout 4.0 sprovision + work · slower than a worktree · 32 agents · n=3

End to end, materialized, 3,583 filesabout 25.3 sabout 18.2 sprovision + work · slower than a worktree · 32 agents · n=3

Absent · named

What We Did Not Measure.

An absent measurement is absent, not zero. These are the questions this run does not answer.

∅Real builds with warm dependency cachesThe design clones dependency directories into a materialized session. That path was not exercised: the runs executed a no-op command, not a compiler. Absent, not zero.

∅Why materialized sessions are slowerWe measured the slowdown and did not profile it. We do not offer a cause.

∅The per-process swarm pathThe benchmark ran agents as threads in one process. The production swarm runs one worker process per task, which was not measured here.

∅Linux and WindowsmacOS only. The Linux overlay backend exists in code but is not wired into sessions, so no Linux claim is made.

Method

How To Read These Numbers.

One machine (Apple M5 Pro, macOS, APFS), release build, two repositories of 997 and 3,583 tracked files, 4, 16 and 32 agents, three runs per cell, medians. Every run used a fresh clone, and the host working tree was unchanged after every run. Disk is the change in the volume's free space after a sync, not du. These are single-machine results and are not a general performance claim.

Questions

Asked About Shadow Trees.

Are Shadow Trees faster than git worktrees?

For agents that read and edit, yes, by a wide margin: about 4 ms against 3.5 to 15.8 s to provision 32 agents, in our runs on one Mac. For agents that run real commands, no. Those sessions get a real checkout, used about the same disk as a worktree and finished slower in our runs.

Where does the disk saving come from?

An edit-only session holds only its changes (in memory, with a small on-disk journal) over a shared object store. A worktree writes the whole tracked tree per agent. The saving disappears once a session materializes a checkout.

How was disk measured?

As the change in the volume's free space after a sync, not with du. On APFS, cloned files report their logical size under du, which overstates real use.

Is this comparison fair to worktrees?

Mostly, with one caveat: the worktree arm leaves its commits on a detached head without creating a branch, so it skips a small amount of work the shadow arm does when it publishes. Adding a branch would add a little cost to the worktree side.

Does it work on Linux?

Not yet. Shadow Trees are macOS only today. We publish no Linux numbers.

Run Agents That Fit On Your Laptop.

25.6 MB median RSS. 25 agents ran in parallel on a Core 2 Duo with 4 GB RAM. Hundreds on your machine. Zero cloud required on the Ollama path.

Get Started →Read the FAQ

Requires Rust/cargo to build from source. Linux and macOS today, Windows not yet supported. Pre-1.0, public beta. Pricing TBD.