Cursor Origin
22.6 Commits per Second: The Origin Demo Numbers, Unpacked
The 22.6 commits per second figure comes from coverage of Cursor's Origin demo at Compile on June 16, 2026: write throughput into a single repository. Cursor has not published it as a benchmark. Taken at face value it is about 1.95 million commits a day, which measures git infrastructure, not how fast anyone reviews or ships.
On this page
Where does the 22.6 commits per second figure come from?
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 the number on a Cursor property. As of July 2026, cursor.com/origin is a waitlist page with no performance figures, no feature list and no benchmark methodology. Everything below starts from that fact.
- Figure
- 22.6 commits per second, one repository
- Shown at
- Origin demo, Compile event, June 16, 2026
- Carried by
- Press and newsletter coverage of the demo
- Published by Cursor
- No. cursor.com/origin has no performance numbers.
- Companion claims
- Roughly 296,000 clones per hour and sub-400ms sync, also coverage-only
Provenance as of July 2026. A demo stat carried by coverage is a claim, not a benchmark.
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.
This is covered hands-on in Cursor Compile 2026 — 1 short module, free to read.
What does 22.6 commits per second actually measure?
It measures ingest: the hosting layer accepting writes into one repository. Nothing about review, nothing about merging, nothing about shipping. To feel the scale of the claim, run the multiplication.
- Window
- Per minute
- Commits at 22.6/sec
- 1,356
- Window
- Per hour
- Commits at 22.6/sec
- 81,360
- Window
- Per day
- Commits at 22.6/sec
- about 1.95 million
- Window
- Per year
- Commits at 22.6/sec
- over 700 million, in one repo
| Window | Commits at 22.6/sec |
|---|---|
| Per minute | 1,356 |
| Per hour | 81,360 |
| Per day | about 1.95 million |
| Per year | over 700 million, in one repo |
Straight arithmetic on the demo figure. The point is the order of magnitude, not the decimals.
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 precisely the design statement Cursor wanted to make: Origin assumes machine traffic is the primary traffic.
What does commit throughput not tell you?
A software team has three separate capacities, and the demo number speaks to only one of them.
How fast code gets written. Agents made this effectively unbounded, and 22.6/sec lives here: proof the pipe can absorb what agents produce.
How fast humans can judge changes. Unchanged by faster hosting. A person reads a diff at the same speed whether the forge ingests 2 commits a second or 22.
How fast validated changes land on trunk. Bounded by CI time and merge-queue batching, not by git write speed.
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.
What is the skeptic's question about 22.6 commits per second?
Who reads any of it. At even a hundredth of the demo rate, roughly 19,000 commits a day, no team on earth reviews every change. 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. Benchmarks earn trust through the boring details, and none of them are public.
Quote it as "coverage of the Compile demo reported 22.6 commits per second," never as "Origin does 22.6 commits per second." If Cursor publishes an engineering post with methodology, upgrade it to a benchmark. Until then it is a well-attested demo claim with unpublished conditions.
The honest reading is that 22.6 is a design statement wearing a benchmark's clothes. It says Origin was engineered on the assumption that agents, not people, generate most of the traffic. That assumption is the interesting part, and it will be checkable the day the product ships.
Frequently asked questions
Did Cursor publish the 22.6 commits per second number?
No. The figure was shown at the Origin demo at Compile on June 16, 2026 and carried by press and newsletter coverage. As of July 2026, cursor.com/origin publishes no performance numbers, no methodology and no feature list, so the stat remains a demo claim rather than a first-party benchmark.
How many commits per day is 22.6 per second?
About 1.95 million commits a day into a single repository, or 81,360 an hour. For contrast, a 1,000-engineer organization merging five changes per person per day produces about 5,000. The demo rate is roughly 390 times that, which is why it only makes sense as an agent-load test.
Does a fast git host make my team ship faster?
Not by itself. Ingest throughput is one of three capacities; review speed and merge capacity are the ones most teams are bound by, and they are set by human attention and CI time. Fast hosting removes a ceiling you probably haven't hit yet.
What other numbers came out of the Origin demo?
Coverage also carried roughly 296,000 clones per hour and sub-400-millisecond sync latency. Those are coverage-only too, and at least one had its unit and timeframe garbled between the original source and the headlines, which is a good reason to treat the whole set as demo claims.
Sources & last verified
Cursor ships frequently. Facts verified against primary sources on July 16, 2026.