Nice benchmarks, impressive numbers. 20x less space than btrfs for the deep seek harness.
They even have some explanations. Files writes in btrfs snapshots recreatethe contents as opposed to storing what's changed. Btrfs has no dedupe, if multiple snapshots happen to have the same data. And small files store metadata twice in btrfs for reasons.
I do think their use case is a bit pathological, checking out the same harness at every commit. Most of these btrfs gotchas don't feel like they would be super impactful to me. But really cool results none the less.
I have this pattern but because I run pipelined agents working on a speculative merge topologically sorted task list merging into a merge train. This leads to lots and lots of work trees that largely overlap except for slight variants. Their articulated use case is mine, and I can have up to a hundred work trees at a time. The storage and related back pressures can be complicated.