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

GitHub’s 17 August outage lasted seven hours and 47 minutes. Its 20 August incident report describes capacity pressure and says monthly commits rose from 1.4 billion in April to 2.9 billion. Those figures deserve careful reading.

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

That increase invites an obvious hypothesis: agents are creating more work. The incident report establishes growth and capacity pressure, but does not isolate agents’ causal contribution.

Before comparing the headline with other GitHub statistics, establish that the counters measure the same thing.

Different counters need different denominators

GitHub’s 2025 Octoverse report gives 986 million commits for its reporting period. Dividing by twelve yields about 82 million per month. That arithmetic alone does not make it comparable with the infrastructure counter in the outage report.

The two published headline rates differ by roughly 35×. That is a ratio between reports, not an established 35× increase in the same measured write path. Their scope and counting rules must be reconciled first.

A repository census, a public activity stream and an internal service counter can count different events. Without an explicit mapping, adding more estimates does not resolve the denominator.

Octoverse includes activity from public and private repositories. Describing it as public-only would be wrong. The available reports do not fully reconcile their treatment of pushes, commits, retries, mirrors and other generated activity.

The operational question is which events consume the constrained service: unique commits, pushed objects, requests, retries or some combination. A commit headline cannot answer that by itself.

So how much of it is actually agents?

Public studies establish visible agent activity in particular samples. They do not directly measure the fraction of all GitHub infrastructure load caused by agents.

A 2026 research preprint combines configuration files, commit messages, authors and bot signatures to study agent traces in open repositories. Its counts are sample- and detection-specific; they are not a platform-wide traffic share.

Missing private activity and unmarked assistance can cause undercounting, while heuristics can also produce false positives. A detected share is not automatically a mathematical lower bound without validating those errors.

The platform-wide agent contribution remains unknown from these sources. The evidence supports asking the question, not assigning a percentage.

The outage was not one outage

The incident report attributes both August 6 and August 17 failures to insufficient capacity rather than a code or configuration change.

The August 17 incident affected services relying on shared capacity in Central US. Consult the incident report for the precise timeline and affected services.

Incident counts depend on how degraded components and related events are grouped. This article does not use an unreconciled count as a reliability metric.

GitHub describes client retries adding load during recovery. Backoff and retry budgets therefore belong in the capacity discussion alongside compute and storage.

Capacity is more than adding machines

Capacity planning has to account for storage, network traffic, dependency bottlenecks and recovery behavior. Adding worker capacity does not remove every shared constraint.

Capacity expansion responds to expected demand. The announced plan does not by itself establish how much headroom GitHub previously had or explain the relationship between the published commit counters.

And then Cursor shipped a code host on the same day

Cursor announced Origin code hosting on August 17. Its native-hosting and GitHub-synced modes create different migration paths; the synced route retains GitHub as the source of truth.

For agent-heavy workflows, a competing host can make repository operations and review part of the agent product. That is a strategy worth evaluating separately from outage frustration.

Origin documents repositories, git operations, browsing, search, pull requests, checks, comments, merging and permissions. Compare the documented hosting modes and workflow requirements separately.

Before migrating, inventory issues, registries, CI, access controls, integrations and audit requirements. Do not infer either parity or absence from a short launch post.

In synced mode, GitHub remains the source of truth and pushes go to GitHub. Origin also documents native hosting. The synchronized route is one integration option, not a description of the entire product.

Which is exactly why it might work

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

Putting an editor, an agent and a repository interface together may reduce handoffs. Evaluate the capabilities actually available: how proposed changes become reviewable, how checks run and how authorization is preserved. That assessment does not require an unsourced roadmap or a prediction about who will own the repository.

Higher pull-request volume can increase review demand. Evaluate existing tools against representative queues, measuring turnaround, defect detection and rework. A count such as a hundred agent pull requests a day does not establish a universal failure threshold.

GitHub’s ecosystem can increase migration costs through CI, identity, integrations and existing repository relationships. A synchronized Origin deployment can preserve those dependencies; its existence does not show that native hosting is unavailable or that migration is impossible.

A code-hosting strategy should be judged by reliability, migration cost and workflow fit. Corporate valuation or speculation about ownership does not establish those properties.

The part that is not about GitHub

The incident is evidence of hosting capacity pressure. It does not establish where AI-related strain appeared first, nor does the unreconciled commit counter quantify how much of that load came from agents.

Other registries and hosting systems can face similar bursts, but each needs its own traffic evidence. This article does not infer their agent share from GitHub’s numbers.

Agent-generated traffic, automated maintenance and ordinary developer activity can overlap. Measuring their operational cost requires explicit attribution and a defined denominator.

What I take from it

First: reconcile the counters before turning 2.9 billion into a growth claim. The outage report establishes substantial activity and capacity pressure; the comparison with Octoverse remains scope-dependent.

Second: clients need bounded retries, backoff and observable failure. Agents can amplify traffic when orchestration keeps retrying, but that behavior depends on the harness and policy.

Evaluate the review workflow alongside hosting reliability. Compare how tools help a team inspect changes, detect defects and preserve approval boundaries under representative load. No single feature or vendor is established here as the inevitable owner of that workflow.

The useful follow-up is to reconcile the counter definitions and track the documented capacity response. Repeating a large number without its counting rules makes the incident harder to understand.