GitHub Says 2.9 Billion Commits a Month. Its Own Annual Report Says 986 Million a Year.

On 17 August, GitHub went down for 7 hours and 47 minutes. Authentication, Actions, the API, pull requests, issues and Copilot, globally. CTO Vlad Fedorov published the post-mortem four days later, and buried in it was a number that has been quoted everywhere since:

Since April, monthly commits have grown from 1.4 billion to 2.9 billion.

Doubled in four months. The obvious reading is that agents are now writing code at a scale no human population could produce, and that GitHub's infrastructure buckled under it.

That reading is probably directionally right. But the number itself does not survive ten minutes of checking, and what it actually reveals is more interesting than the headline.

The number does not reconcile with GitHub's own reporting

GitHub publishes an annual state-of-the-platform report called Octoverse. Here is what it said, against what the outage post says:

GitHub's own annual report counted 986 million commits in all of 2025. The outage post claims 2.9 billion in a single month. That is roughly 35× the Octoverse monthly rate, reached in under a year.

An independent estimator built on GitHub search puts it at 1.03B commits in 2023, 1.07B in 2024, 1.51B in 2025 — the same order of magnitude as Octoverse, nowhere near 2.9B a month.

Both numbers are probably true and measuring different things. Octoverse counts public-repository activity. An infrastructure post-mortem counts what hits the write path: private repos, forks, CI-generated commits, mirrored and imported histories, and every agent scratch branch that gets created and abandoned. Those are legitimate load. They are not the same as 2.9 billion units of software being authored.

Hacker News got there fast, calling commit count "a red herring" and pointing out that one push can contain a hundred commits, and that agents in particular produce micro-commits at a rate no human workflow does. Nobody has demonstrated the figure is inflated. Nobody has demonstrated what it counts either — and GitHub did not say.

So how much of it is actually agents?

This is the part everyone asserts and nobody measures. The honest answer is that the public evidence is thin and all of it is a lower bound.

The tracker numbers look small, and they are useless as a ceiling: they only catch agents that sign their commits. Private repositories, enterprise work, and any agent configured to commit as the user are invisible. The same detection study found that naive bot-name matching misses most Claude Code adoption entirely.

So: agent-authored commits are somewhere between 2% and a lot, and GitHub — the one party with the actual data — publishes a Copilot review share but no platform-wide authored-commit figure. That omission is doing work in a post whose whole argument is that demand exploded.

The outage was not one outage

Fedorov's phrasing is "neither outage was caused by a code or configuration change. Both incidents were capacity failures at their core." The second one is easy to miss.

Neither was a bad deploy. Both were running out of room. And they sit inside a worse pattern: GitHub's own availability reports record 45 degraded-performance incidents between January and July, and August alone produced 13 separate incidents.

One detail in the post deserves more attention than it got. During recovery, "errors in those services triggered a client-side retry loop that increased traffic during recovery." Copilot clients hammering a degraded backend made the degradation worse. That is the agentic failure mode in miniature: software that retries without patience, at machine frequency, precisely when a system needs less load. A human hits refresh a few times and goes for coffee. An agent does not get bored.

What GitHub is buying

The response is not subtle. More than 3 million CPU cores, 120 petabytes of high-speed storage, significant network capacity, and an accelerated migration onto Azure. Plus retry limits and variable timeouts — the actual fix for the amplification problem.

Buying three million cores is a strategy for a demand curve you expect to keep going up. It is also an admission that the previous curve was wrong, and that the platform was being run closer to the edge than anyone outside knew.

And then Cursor shipped a code host on the same day

On 18 August, hours into a GitHub outage with error rates near 20%, Cursor launched Origin — repository hosting, pull requests, review, merging, permissions and an API, with Vercel, Depot and Buildkite integrations on day one. Early beta, all paid plans.

The timing was extraordinary. The product, less so — and Cursor said as much. Tomas Reimers, the Origin engineer who founded Graphite before Cursor acquired it, answered questions on Hacker News. Asked what distinguishes Origin from GitHub, he said: "very little, in all honesty."

He is right, for now. Origin documents repos, git operations, browsing, search, PRs, checks, comments, merging and permissions. What it does not document is telling:

And the default posture is not replacement. Synced GitHub repositories keep GitHub as the source of truth. Push still goes to GitHub. Origin is a lens on your code that happens to sit next to your agent.

Which is exactly why it might work

The argument for Origin is not feature parity. It is adjacency.

If agents write a growing share of code, the review surface matters more than the hosting surface, and whoever owns the editor and the agent is one step from owning the repository. Cursor now controls all three. Reimers's roadmap is explicit about the direction: deeper agent integration, tooling that makes sense of agent-written code, and automation that pushes pull requests toward mergeable on their own.

That is a real thesis. Review was designed for code a human wrote and another human reads. It does not survive a hundred agent PRs a day, and nobody has built the replacement yet.

The counter-argument is GitHub's moat, which is not the git server. It is Actions, the marketplace, the identity graph, every CI badge and deploy key and webhook in existence, and the fact that your dependencies live there. Origin syncing to GitHub is the proof: even Cursor cannot leave.

Worth noting for context on how fast this is moving: Cursor went from roughly $500M ARR after its 2025 Series C to a reported $4B annualized by June 2026, and was then acquired by SpaceX at an implied equity value near $60B. Origin is its first major product since. Some of the launch-day reaction on Hacker News was less about features than about what happens to Claude access inside a Cursor owned by a company that ships its own model.

The part that is not about GitHub

Strip the numbers back and one thing holds regardless of what 2.9 billion counts: the infrastructure layer under AI coding is where the strain is showing up first, and it is not only GitHub.

GitLab says some customer codebases grew fivefold in a year and that conventional git infrastructure "buckles under agent load" — they are building a new SCM backend because of it. Cloudflare reports non-human traffic now exceeds half of all internet traffic, though that counts crawlers too.

For npm, PyPI and Docker Hub there is no published agent-traffic share. That silence is a gap, not a reassurance. Every agent loop pulls dependencies, and it pulls them at machine frequency without a cache warmed by habit.

What I take from it

Don't quote 2.9 billion as a measure of code written. Quote it as a measure of load, which is what a post-mortem measures and what GitHub actually said. The interesting fact is not the size of the number, it is that GitHub's write path handles thirty-five times the volume its own annual report describes, and that nobody outside GitHub knew.

Assume retry storms are your problem too. If you have agents calling anything, they will hammer it exactly when it is failing. GitHub's own client did this to GitHub. Retry limits and jittered backoff stopped being hygiene and became architecture.

Watch the review layer, not the hosting layer. Origin's git server is not the threat to GitHub. The thing that makes agent output reviewable at volume is, and it is unbuilt. Whoever ships it — GitHub, Cursor, or someone else — takes the workflow with it.

The outage will be forgotten in a month. The number will get repeated for a year, mostly wrongly. The capacity curve behind both is the thing worth watching.