Centralized Git was always going to break under agent load. The protocol that Linus shipped in 2005 was designed for a handful of humans running git push from a coffee shop — not a swarm of coding agents each running shallow-clone → edit → push in a tight loop, thousands of times an hour, against the same repository. By 2026, that constraint is showing up as GitHub rate-limit emails, flaking CI, and "the agent pool is throttled" Slack messages. The fix has been talked about for years — mirror traffic, push to CDN, fan out the read side — but nobody had shipped it as a product with public numbers.
Entire just shipped the first credible answer. The preview of their distributed Git network is live under waitlist, with active mirrors in the US, EU, and Australia, and the numbers from the initial test run are the first real evidence that the agent era has a Git backend it can grow into: ~570,000 clones/hour, 586 pushes/second (~2.1M/hour), and a sustained ~470 clone+push ops/sec on a single repository at ~50–60 ms p50 latency. The Git backend itself is going open source. If you've been waiting for the infrastructure story to catch up to the agent story, this is it.
The problem, in one line
A single central server per repository is a rate limit dressed up as a feature. When you have a hundred agents — let alone the "billions" the industry keeps waving at — all cloning and pushing into the same repo, you stop being able to pretend that GitHub is the canonical bottleneck. You start being one abuse-detection false positive away from a multi-hour outage.
[[DIAGRAM: an agent fleet cloning from and pushing to a regional mirror in front of the GitHub origin — the mirror absorbs the read traffic, the origin stays untouched, pushes coalesce at the mirror]]
Entire's premise is simple: keep the source of truth where it is (GitHub, for now), and put a regional mirror in front of it that agents can hammer without either side getting rate-limited. The origin keeps its existing CI, its existing webhooks, its existing access controls. The mirror takes the read load and the concurrent push pressure, and it does that for every region that needs it.
What the distributed network actually is
Three things ship in the preview:
- Regional mirrors in the US, EU, and Australia, with more regions planned.
- One-step GitHub mirroring — you point Entire at a GitHub repo, the code stays on GitHub, and your agents clone and pull from the regional mirror.
- A rebuilt Git backend tuned for concurrent, high-volume agent activity, which Entire says it will open source in the coming months.
The next two milestones, per the announcement: native repository hosting (so you don't need GitHub as the origin at all) and a fully decentralized network where you can run your own region for data residency and sovereignty. Those are the parts that matter for enterprises that can't put their code on a US-hosted server for regulatory reasons — but the preview is what unblocks the agent workload today.
The numbers, in one place
From the initial test run, the announcement lists three concrete benchmarks. All on a single repository.
| Operation | Throughput | Workload |
|---|---|---|
git clone (shallow) |
~570,000 / hour | 200 simulated clients in Frankfurt (40%), Paris, London, Dublin — 3 min |
git push |
586 / sec (~2.1M / hour) | 128 simulated agents, 1–10 files @ 2 KB each, 2 min, one branch per agent |
| clone + push (mixed loop) | ~470 / sec | 128 agents running shallow clone → 5 pushes → repeat, ~50–60 ms p50 |
The mixed-loop number is the one to circle. 470 clone+push ops/sec at 50–60 ms p50 is what an agent actually does — pull, work, push, repeat — and that's the workload traditional Git hosting wasn't designed for. 200 clients pulling shallow clones in parallel is also roughly what a 50-engineer team with aggressive CI looks like on a busy day, before you add agents to the mix.
[[CHART: a relative comparison of clones-per-hour, pushes-per-hour, and mixed-ops-per-second on one repository — order of magnitude, not exact]]
How to actually use it today
The preview is gated behind a waitlist. The good news is the integration is small:
# 1. Join the waitlist at entire.io (link in the launch post)
# 2. Approve → connect your GitHub account via the Entire dashboard
# 3. Pick the repos you want mirrored
# 4. Choose the regional mirror closest to your agent fleet (us, eu, au)
# Point your agents at the regional mirror
git clone
# Origin stays on GitHub — your existing CI, webhooks, deploys don't change
# Mirror is read-heavy on clone, write-through on push
# For an existing clone, swap the remote:
git remote set-url origin
That's the whole integration. For anything that already supports a custom Git remote — Cursor, Claude Code, Aider, custom harnesses, your CI runner — it's a one-line config change per remote. If you're running a fleet of agents in a single region, point them at the closest mirror. If you're running agents in multiple regions, the dashboard picks the mirror per clone, and your Git origin stays where it's always been.
The day-to-day operational change is also small. Pulls are faster. Pushes coalesce at the mirror so you're not opening N connections to GitHub per agent. And when GitHub's rate limiter does fire — and it will, for some agent workload, eventually — your fleet is reading from the mirror, not the origin, and the only thing that notices is the push queue.
What the open-source backend changes
The numbers are impressive but they aren't the most interesting part. The most interesting part is at the end of the announcement: Entire is going to open source the Git backend.
Read that again. The same backend that just hit 570k clones/hour and 586 pushes/sec on a single repo is going to ship with a license you can read, fork, and self-host. If you've ever tried to scale Git at the protocol level — every team that runs GitHub Enterprise at non-trivial size has, at least once, rage-Googled "git protocol scalability" — you know that this is the layer everyone wants to tweak and almost nobody can.
Combine an open backend with the upcoming native hosting and full decentralization, and the long-term shape is clear: any team can run its own region, on its own infrastructure, in its own jurisdiction, and the network still functions. Linus said it in 2007 at Google: "If you're not distributed, you're not worth using." The preview is the first step toward an implementation that actually matches that statement at production scale.
Honest limits
Three things the announcement doesn't paper over:
- Waitlist. The preview is gated. You can't benchmark it on your real workload until they approve you, and approval speed is the only thing we don't know yet.
- Region coverage. US, EU, AU is enough for North American and European fleets. APAC and South America aren't covered. If your agents sit in São Paulo, the closest mirror is in Virginia, and the latency story changes.
- Backend isn't open yet. "Will open source" is a promise. The 570k-clone number is real, but you can't read the implementation until it ships, and you can't self-host it until then either.
None of these are reasons to skip it. They're reasons to know what you're signing up for before you migrate your agent fleet onto a preview.
Where OTF fits
Entire is solving the "where the code lives" problem. The mirror is the part that changes; the code is the part that doesn't. OTF solves the same shape of problem on the other side of the stack: the source of truth is one codebase, and the surface — web, iOS, Android — is many.
[[CONCEPT: one source of truth, many surfaces — a single component definition rendered identically across web and mobile, the same way a single Git repo is read identically from any region]]
When you ship a product that has to behave the same way on three platforms and survive a year of agent-driven refactors, the durable layer is the one that doesn't have to change every time the infra changes. The Git host changes — mirror goes from one region to three, then to native, then to fully decentralized. The model behind your agent changes. The component on the screen stays the same, and that's the part your users actually feel.
Use Entire, and you've freed your agents to work as fast as the network will let them. The thing you put in front of your users is the part that needs to be just as durable — and that's the part OTF is built to be.
What to watch
- Native repository hosting. Right now, GitHub is still the origin. When that drops, the "your code stays where it is" caveat goes away.
- More regions. US, EU, AU covers most fleets. APAC and South America are the obvious gaps for global teams.
- The open-source backend. When it lands, look at the rate-shaping layer first. That's where the 570k-clone number is actually being earned.
The preview is small, the waitlist is the only friction, and the integration is a URL swap. If you have an agent fleet that's already outgrown GitHub's rate limits, this is the first backend that's been built for the workload you're actually running — and the open-source promise is the part that turns it from a product into infrastructure.
Top comments (0)