Scion-style merges: one comparison takes 1.93 s at 100,000 files
What we took from Anthropic's Scion for Workspaces, and the merge cost we measured before changing anything.
On October 13, 2026, Anthropic described Scion, the system that replaced git for its monorepo. We compared it with plori Workspaces, and measured Scion's rule that a commit's cost scales with the size of the change before we built anything.
The short answer
- We added a per-path history, built from each accepted revision by a background job, and the platform now accepts a worker's change without review when the merge has no conflicts.
- One merge comparison takes 1.93 s at 100,000 files. About 75% of the time goes to building the flat list of every path in the merged tree.
- We deferred the merge change. The latest revision of our Workspaces has a median of 19 entries and a 99th percentile of 9,361.
Cost of one merge comparison
| Files in the tree | Time (median of 3) | Bytes allocated |
|---|---|---|
| 1,000 | 15.6 ms | 5.7 MB |
| 10,000 | 125 ms | 47.1 MB |
| 100,000 | 1.93 s | 447 MB |
| 500,000 | 13.9 s | 2.43 GB |
When the answer changes
- Benchmark conditions: two changes of 10 files each, merged in memory on one 8-core development host that also ran CI jobs. The production storage service runs with 1 CPU. The numbers exclude restic reads from object storage and the time to write and check the merged revision.
- When we revisit: when a Workspace with active workers reaches about 100,000 entries, or when we measure more than about three comparisons per accepted change on average.
- Automatic acceptance has limits: a merge with no conflicts can still produce code that does not build. Workspaces run no tests before or after an automatic accept, and there is no one-step undo.
The full post has the per-path history design, two bugs we fixed on the way, and the 96 MiB write limit that the flat list reaches at about 435,000 files.