worktrunk: Five Agent Workspaces, Measured — Slower Creation, Near-Zero Dependency Copies
A practical overhead of parallel AI agent workflows disappears on APFS and other CoW filesystems, where copying a 120MB dependency drops from 0.20s to 0.02s; but the tool's whole disk-saving premise collapses on ext4, and creation gets slower, so teams on non-CoW filesystems get none of the upside.
Parallel AI agents need isolated directories. worktrunk, a 10.7k-star Rust tool, gives you one-line `wt switch -c -x` commands that create a worktree and launch an agent in it, a `wt list` dashboard that shows uncommitted changes and sync status in a single table, and lifecycle hooks for dependency install and dev-server ports. The genuine payoff is cold-start cost: `wt step copy-ignored` reflinks ignored files on APFS/btrfs/XFS, so copying a 120MB dependency took 0.02s with no visible `df` increase, versus 0.20s and 120MB for an ordinary `cp`.
That saving doesn't come free. Creating 5 worktrees took 0.45s versus 0.11s for native git in a single measurement (about 0.07s extra each). The tool adds 44MB of binaries, requires shell integration for automatic `cd`, and hooks need one-time approval. The author was explicit about what wasn't measured: real node_modules with thousands of small files, reflink after writes, merge conflicts, and five agents running to completion. On ext4, reflink doesn't apply and disk savings vanish.
The practical judgment: worktrunk isn't for making worktrees faster; it's for making the act of spawning another agent cheap enough that you actually do it. For developers running three or more agents on a CoW filesystem, the `wt list` overview and near-zero-copy dependency cloning change the workflow. For single-agent users on ext4, it's 44MB and three extra commands for no benefit.
The measured 4x and 10x ratios are single-run numbers at 0.1-second and 0.02-second scales, where process startup and timer precision dominate; they should be read as order-of-magnitude, not benchmarks.
worktrunk's real contribution is lowering the friction of opening a new workspace, not making git faster; that aligns with the conclusion that it's only worth installing at three or more parallel agents.
The reflink benefit is tightly coupled to file-system support and read-only dependencies; since build caches get written, block splitting will reclaim disk usage, so the win concentrates on cold starts.
The author's refusal to test real node_modules and conflict workflows keeps the claims honest; the disk-saving conclusion would likely differ for tens of thousands of small files.