22.6 Commits per Second: The Origin Demo Numbers, Unpacked

The number was shown during Cursor's Origin demo at the Compile event on June 16, 2026, where Graphite co-founder Tomas Reimers presented the platform on stage. Coverage of the demo carried it as Origin sustaining 22.6 commits per second into a single repository, and the figure has been quoted in write-ups and newsletters ever since. It is the one stat from the launch most people can recite.

What you will not find is that number on a Cursor property. Origin has shipped in early beta and has a docs section, and neither the docs nor the August 17 changelog carries a performance figure or a benchmark methodology. What Cursor did publish, on August 18, 2026, is an engineering post titled "Git at any scale" about Continuity, the Git storage system under Origin, and it uses a different unit: pushes per second. Using S3 Standard, the post says, Continuity can sustain up to 120 pushes/s while compacting and replicating to all other nodes, and on S3 Express One Zone it can ingest more than 300 pushes/s, bottlenecked by how fast Git can compact on-disk data. The charts are labelled as push and clone throughput for everysphere, Cursor's monorepo. Everything below starts from the gap between those two sets of numbers.

The qualifier in that first row matters as much as the number. Writes to separate repositories do not contend for the same refs, so the same rate spread over a thousand repos is a much easier problem than the same rate landing on one.

The companion figures already show how launch numbers mutate in transit. One outlet covering the demo flagged that the widely shared clones-per-hour figure had its unit and timeframe truncated from the original source's headline, and this site's earlier research traced a different widely shared Compile throughput stat to another product entirely. The 22.6 figure is the best-attested of the set, and it is still a demo claim.

A push and a commit are not the same unit, which is why the two sets of numbers do not reconcile and should not be made to. A push can carry many commits, so 120 pushes/s says nothing about commits per second on its own, and the post is about the storage layer's write-ahead log on S3 rather than the product's review path. It also states its durability rule plainly: a push is never acknowledged until it has been fully persisted. That is the kind of first-party claim worth planning around, where the demo figure is not.

The usual move with a vendor number is to reproduce it: get access and run the load against your own repository. Since the August 17 early beta that is possible on a paid plan, though a single team's push rate on one synced repo tells you little about a figure of this size, and the beta docs say nothing about load limits. Provenance is still the better check, which is why the first section here covers where the figure came from rather than what it means.

It measures ingest: the hosting layer accepting writes into one repository. It says nothing about review, merging or shipping. To feel the scale of the claim, run the multiplication.

Part of why this figure travels so well is the unit. 22.6 of anything per second sounds modest, while the same rate written out as 1.95 million commits a day sounds like a claim about infrastructure. The table converts one into the other. It adds no precision the source did not have, and the decimal does its own work here: 22.6 reads as measured, and it may well have been. What it was measured on is the part nobody has said.

For a human anchor: an organization of 1,000 engineers where each person merges five changes a day produces 5,000 commits daily. The demo rate is roughly 390 times that, sustained, into a single repository. No human workforce generates that load. The number only makes sense as a stress test for agent swarms, which is the reading the demo invites: Origin is pitched at machine traffic as the primary traffic.

A software team has three separate capacities, and the demo number speaks to only one of them.

The gap between the first capacity and the other two is the actual story of agent-scale development. Fast ingest removes a bottleneck most teams have never hit; review and merge are the ones they hit every day. That is why Origin's other reported features, the merge queue, the automated CI fixes, the conflict resolution, matter more than the headline stat, and why they deserve the same scrutiny.

The failure mode this number produces is a planning one, and it does not take a credulous reader to hit it. A team sees the rate, decides hosting is the constraint, and starts scoping a migration, which costs weeks of pipeline work and buys headroom on the one capacity nobody was short of. The review queue ends up exactly where it started.

Before accepting that hosting is your constraint, time one recent change from the agent opening it to the merge landing. If most of that clock is CI wait or a person's inbox, a faster forge moves none of it.

Who reads any of it. Cut the demo rate by a factor of a hundred and it is still roughly 19,000 commits a day, more than a human review process can absorb. A forge that can ingest millions of commits is implicitly promising an answer to who reviews agent code, and that answer, bots on the first pass, humans on judgment, is a workflow claim the demo did not prove.

The second question is what a commit was in the demo. One-line synthetic writes and real feature commits load a system very differently, and no methodology was published: commit size, repo size, hardware, duration, whether hooks and checks ran. Without those, there is no way to tell whether the rate describes a workload anything like yours.

What the figure is good for, I think, is reading the assumptions behind Origin rather than measuring it. The rate sits far past anything a workforce of people could generate, which points at agents as the expected source of the load. Whether the shipped product holds up under that load is a separate question, and nobody outside Cursor can answer it yet.