R1 · how it works · parallelism

How R1 runs steps in parallel.

R1 can fan out work, but it still treats the final merge like a scarce resource. That is what keeps concurrency useful instead of destructive.

Parallelism in R1 starts with dependency separation. Independent steps can move at once, but steps that touch the same file surface or the same release boundary are isolated into separate worktrees with conflict awareness.

During execution

Workers can read, patch, and verify in parallel. The receipt records which branch did what, which matters later when a reviewer wants to understand why a retry was needed.

At merge time

Main stays serialized. R1 rebases, rechecks, and only then lands the change. If a late conflict appears, that branch gets rolled back or retried instead of letting the bad state leak forward.

When one branch fails

Failed work is bounded. A bad branch should not poison the rest of the queue. The harness keeps enough structure to retry the branch with the failure mode in mind while unrelated work continues.

See the parallel timeline on the homepage.