Agentic development is forcing a rethink of how Git infrastructure is built. Developers and agents now work concurrently inside repositories that absorb millions of commits a day, and the workloads they generate behave nothing like the human-paced traffic the current architecture was designed around. GitHub is rebuilding its Git tier for that shift.

The shape of the load

The monthly repository activity distribution on GitHub for August 2026 climbs sharply at its far end: the busiest single repository saw roughly a billion requests in that month. Aggregate activity is rising just as fast. Between September 2025 and August 2026, total Git activity on GitHub went from 218.2 billion events per month to 473.3 billion — more than 2x its previous level. In September alone, 7.38 billion commits landed, more than five times the count of a year earlier.

Those top-of-curve repositories are what agentic development looks like at its leading edge: large engineering teams running busy CI pipelines alongside growing fleets of agents.

Why the current design tops out

Repositories are stored by Spokes, which keeps a full copy on the local disks of several fileservers — five by default. Local disks give Git operations low-latency access to native repository data, the extra copies provide redundancy, and reads spread across fileservers. A push that updates a reference goes through a three-phase commit protocol that uses a quorum so CI, the web UI, and API clients see a consistent state. That pairing currently serves a billion repositories.

The problem is that the mechanism providing durability is also the mechanism providing scale. Disk copies are the source of truth, so additional read capacity means another durable replica — and every replica takes part in every write. A push is therefore only as fast as the slowest replica in its set. Adding read replicas makes writes slower.

For most repositories the tradeoff is acceptable. At high activity levels it becomes a ceiling: extra read replicas add write overhead, losing a replica shrinks read capacity, and losing quorum halts writes altogether.

The new demands break down along four axes:

  • Per-agent commit turnaround. An agent in a tight loop commits or checkpoints after nearly every action, so its speed is bounded by how fast a single push completes. Latency a human would never notice becomes the limiting factor.
  • Write throughput. Pushes grew 4.9x year over year, from 0.69 billion to 3.35 billion per month. Thousands of agents on their own branches in one repository produce a sustained write rate that converges on a single point in the architecture.
  • Merge contention on one reference. Trunk-based development, release trains, and merge queues funnel work onto a single ref. Pull request merges are at nearly 4x their volume a year ago.
  • Write amplification into reads. CI and code scanning clone or fetch the same branch tip thousands of times per minute. GitHub Actions ran 3.26 billion times in September, more than 4x the prior year.

Repository maintenance compounds the pressure. Fast queries require continuous compaction and cleanup of unneeded objects, and every new write adds to that work. Read scaling alone cannot solve this: caches and replicas serve the same bytes to more clients, but each push must be durably stored and consistently visible before the next agent or CI job can build on it.

Design principles

The rebuild happens while GitHub keeps serving traffic — there is no maintenance window and no change imposed on how teams build software. Engineering for the most demanding cases (an enterprise under strict regulatory requirements, a team landing a change across a repo that builds an operating system, an organization running thousands of agents against one codebase) raises the floor for everyone. The same foundation serves the maintainer reviewing contributions across time zones and the student opening a first pull request.

Existing controls must survive: branch protections and required reviews so unreviewed changes never reach the default branch, audit logs and repository visibility for security investigations, dependable automation and observability for on-call engineers. Three principles guide the work:

  • Build on the workflows developers already trust. Branching, review, merge, and history are how teams ship and govern software; the new infrastructure supports those same workflows at far higher volumes.
  • Put reliability first. Streamlining a change across a repo that builds an operating system, an organization running thousands of agents against one codebase) raises the floor for everyone. The same foundation serves the maintainer reviewing contributions across time zones and the student opening a first pull request.

The architecture

Only the reference update itself truly requires agreement. Object storage, object connectivity validation, and secret scanning involve far more work but can mostly run in parallel with other writes. Shrinking the critical path to that small coordinated step means the rest of the work no longer delays acknowledgment.

Maintenance moves off the serving path entirely. Compaction and garbage collection are among the heaviest operations a repository performs, and today they run on the same hosts answering live Git requests. Separate workers will handle them directly against durable storage, letting a busy repository be optimized continuously in the background without slowing pushes and fetches.

Storage and compute, separated

Authoritative repository data moves to Azure Blob Storage, which already provides durability and replication at Azure scale. A compute layer optimized for throughput at the lowest latency sits above it, and read capacity comes from lightweight workers that cache data to serve requests rather than from additional durable copies.

Failure handling changes accordingly. When storage and compute are coupled, losing a host cuts both capacity and durability, and recovery means rebuilding a full repository copy. When they are separate, losing a compute worker resembles a cache miss: a replacement starts serving immediately and fills its cache from durable storage as traffic arrives.

Provisioning also changes. Compute workers are added or removed as traffic shifts instead of being sized for peak in advance, so a burst — a release, a new agent fleet coming online — can draw extra capacity that disappears once the burst passes. Read spikes from CI fan-out and large clones no longer add work to every push.

Results and what follows

In internal benchmarks the new architecture has delivered up to 35x higher write throughput, with read capacity that scales independently to meet demand.

As automated development raises the frequency and concurrency of software change, GitHub intends to evolve its foundations without giving up the governance and control teams depend on. That foundation is already going into place, and a follow-up post will cover the future architecture and the journey to it in more detail.