GitHub Rubicon: One Contended Reference Matters More Than 5,000 Agents

Agents pushing to their own branches create a different workload from agents updating the same branch. A server may accept thousands of pushes, but changes based on one old commit cannot all become the next value of the same reference.

GitHub's November 5 Rubicon post reports an internal test with 5,000 concurrent agents and 7,200 pushes per second. Checked November 8, these are company measurements, not an independent benchmark or a guarantee for every repository.

Agreement belongs to the small pointer

In the published design, Azure Blob Storage holds packs; Ref-CAS holds references and the pack manifest. Virtual replicas cache state. A write uploads its pack before committing the reference transaction, with reference compare-and-swap confirmed by a quorum. The architecture and write-path discussion informs this original conceptual redraw; it is not a deployment topology or protocol specification.

Git push
   │
   ▼
Virtual replica ── upload pack ──▶ Blob Storage
   │                                 │
   │ after objects are durable       │ immutable objects
   ▼                                 │
Ref-CAS: check expected ref + update manifest/references
   │
   ▼
Clients reading the new reference

There are two costs here. Storing and transferring bytes depends on data volume. Deciding the next reference value depends on which writes touch the same state. Counting workers alone hides that distinction.

Reject an update when its expected value is stale

Git's update-ref accepts an expected old object ID alongside the new value. This command pattern illustrates two writers starting from one known value in a disposable repository.

# Illustrative pattern. OIDs must identify real commits in that repository.
git update-ref refs/heads/demo "$writer_a_oid" "$base_oid"
git update-ref refs/heads/demo "$writer_b_oid" "$base_oid"

Once the first update succeeds, the reference no longer equals base_oid. Rejecting the second prevents a silent overwrite. The comparison does not determine whether file changes can merge; it decides whether the reference still matches the writer's expectation.

We checked this with Node.js 18 or later and local Git: create a temporary empty repository, make three commits from an empty tree, accept A, reject B's stale update, and assert that the reference still points to A. Actual output:

writer A: accepted; writer B with stale base: rejected; ref still A
Local Git semantics only; not Rubicon or a throughput test.

Run the retained experiment from this project's root:

node docs/editorial/2026-11-08/evidence/ref-race.mjs

No remote repository or user branch was changed. This sequential demonstration checks stale-write rejection, not distributed races or Rubicon performance.

Separate branches move the integration problem

Separate branches can reduce reference contention. Changes to the same files, APIs or schemas still need integration later. That work lies beyond the storage layer.

This is a proposed operations ledger, not a set of GitHub test results. Record the intervals before increasing worker counts; otherwise a slow merge may be misdiagnosed as a storage problem.

Throughput does not establish productivity

We have not established that the test's repository size, push distribution or branch concentration matches a particular team's workload. Dividing a team's work by 7,200 would not produce a valid capacity plan. Our local example also says nothing about long-term garbage collection or user experience with large changes.

The useful design lesson is to separate large immutable data from small coordinated state. For a team, observe reference contention separately from integration validation. As a server accepts more writes, the next constraint may become the order in which reviewable changes can be safely combined.