To understand why that claim is interesting rather than just another startup slogan, it helps to remember what Git hosting was originally designed to do.
From Human Collaboration Tool to High-Frequency Infrastructure
Git itself is a distributed version control system — by design, full copies of a project’s history can live on many machines at once, not just on one central server. But most developers experience Git through a "forge": a hosting service like GitHub that layers pull requests, code review, permissions, and automation on top of that distributed core. For two decades, forges have been optimized around human rhythms — a developer clones a project once, works locally, and pushes a batch of changes when a feature is ready.
AI coding agents break that rhythm. An agent doesn’t clone and pull occasionally; it clones, inspects files, runs tests, checkpoints its progress, and retries — often across many parallel sessions working on the same codebase. That turns what used to be light, occasional traffic into repetitive, high-frequency load. Read activity — cloning and fetching code — can multiply dramatically, even before a single line gets written back.
This is not a hypothetical concern invented by a startup trying to raise money. GitHub itself has said that after planning for 10 times its normal capacity in late 2025, it had to redesign for roughly 30 times that scale by early 2026, citing growth in repository creation, pull requests, and automation driven by agentic workflows. Entire’s timing lands squarely on that pressure point.
What the Preview Actually Offers
It’s tempting to read "former GitHub CEO launches Git network" as a direct challenger aiming to replace GitHub outright. The preview is narrower and, arguably, more interesting than that.
A developer connects an existing GitHub repository through Entire’s GitHub App and creates a mirror — a synced, read-optimized copy hosted in a chosen region (the initial preview covers the United States, the European Union, and Australia). Agents or human developers can then clone and fetch from that regional mirror instead of repeatedly reaching back to GitHub’s servers. Crucially, for ordinary mirrored branches, a push still travels through to the original GitHub repository, and GitHub’s own write limits, branch protection rules, and required checks still apply. Entire also layers in memory: it stores an agent’s prompts, tool calls, and checkpoints alongside repository history, so a reviewer can later see not just what changed in the code, but why an agent made that change.
The distinction between read and write traffic is the hinge the whole story turns on. Cloning and fetching are read-heavy — an agent asking "what does this code currently look like?" over and over. Pushing changes back is write-heavy, and writes are where conflicts, ordering, and consistency guarantees get harder to relax. Offloading reads to regional mirrors is a comparatively contained engineering problem; making writes dramatically faster while preserving GitHub’s existing rules is a much bigger one.
| What the preview does now | What it does not yet do |
|---|---|
| Mirrors existing GitHub repos into regional, read-optimized copies | Replace GitHub as the system of record for ordinary branches |
| Offloads agent clone/fetch traffic to nearby regions | Let standard GitHub-backed branch pushes bypass GitHub’s own write limits |
| Attaches agent session memory and checkpoints to repo history | Offer native hosting, self-hosted nodes, or an open-source backend generally |
| Runs on a global control plane with regional data planes | Provide broader decentralized operation across many more regions |
The Benchmark Question Nobody Should Skip
Entire has published performance figures, including claims about very high clone throughput, using an MIT-licensed benchmarking tool it built for measuring concurrent Git-push behavior. That openness is a genuine step above an unverifiable marketing number, since outside developers can inspect and rerun the tool themselves. But the results as published remain the company’s own, run on its own infrastructure and repositories. The company’s own launch materials note that the strongest write-throughput numbers depend on Entire-native or unmirrored branches — not on the ordinary GitHub-backed branches most teams would actually be using today. Company-published benchmarks are worth treating as indicative rather than independently verified until outside teams reproduce them on their own codebases, regions, and review workflows.
A Market That Hasn’t Chosen a Winner
Entire isn’t alone in treating this as an infrastructure category rather than a feature. Other efforts framed around "Git forges for the agentic era" are emerging in parallel, and Dohmke has separately backed a decentralized Git project of his own. That competitive scatter suggests the industry recognizes a real shift in traffic patterns, even though nobody — including Entire — has settled the underlying architectural debate.
The more durable question isn’t whether Git can be decentralized; it always could be. It’s whether shifting reads to regional mirrors meaningfully reduces the load that matters most, or whether the real bottleneck — writes, coordination, and trust — still runs straight back through the centralized platforms agents were built to work with in the first place. Entire’s preview offers an early, partial answer. The fuller one depends on native hosting, self-hosting, and independent testing that haven’t arrived yet.
