GitHub outages and agent-scale workloads are exposing the limits of centralized development platforms—learn where Cursor Origin and Entire could help, and which bottlenecks they cannot fix. Andrey Devyatkin, Vladimir Samoylov, and Fernando Gonçalves examine AI-native Git forges, distributed mirrors, API and Actions limits, repository sovereignty, and whether Git is even the real constraint. They weigh agent-scale throughput claims against human review, CI, internet bandwidth, and the token cost of best-of-N agent fleets, asking whether teams need to leave GitHub or simply reduce their dependence on it.
Summary
Every few weeks lately, a new round of “GitHub is down again” screenshots makes the rounds — and this time there is a business plan attached. This episode of Agentic AI in DevOps, recorded July 17 with Andrey Devyatkin, Vladimir Samoylov, and Fernando Gonçalves, asks a question that suddenly has real money behind it: do we need a new GitHub built for AI agents, and is it time for humans to leave? Two new answers frame the debate — Cursor’s Origin and ex-GitHub CEO Thomas Dohmke’s Entire — both betting that centralized Git hosting buckles when thousands of agents clone, branch, and commit in parallel. The hosts are sympathetic but skeptical: they credit GitHub for staying up as agent traffic climbs — GitHub itself frames the challenge as designing for a future that could need roughly 30× today’s scale, not a 30× jump that has already happened — while owned by Microsoft and standing up more compute through its Azure migration, and they keep poking at the same nerve: is Git actually the bottleneck, or is it everything wrapped around Git (Actions, issues, rate limits) and the humans still doing reviews? Along the way: a marketer telling her peers to get a GitHub profile “or be left behind,” a comparison of repositories to Instagram photos, the Theory of Constraints via a 1984 factory novel, Vladimir’s blunt point that his real bottleneck is his home internet connection, and a running debate over whether best-of-N agent experiments — several agents racing the same problem — justify the fortune in tokens they burn to do “more stupid stuff faster.”
Key Topics
Is GitHub actually down all the time?
The episode opens on a disconnect. Fernando Gonçalves describes a client hit hard by GitHub instability — outages that consistently landed during European working hours, which he theorizes lined up with maintenance windows scheduled for the quiet US night. Andrey Devyatkin, working in a different timezone, says he mostly hasn’t lived that pain lately, though he clearly remembers the version from roughly two years ago: GitHub Actions dying, checks refusing to run on pull requests, and the whole team blocked as a result.
Where they agree is on giving GitHub credit most of the takes online skip. Andrey grants that staying up through the agent boom is no small feat — not perfectly, but at levels he’d still call solid for a service of that complexity. It’s worth being precise about the number that gets thrown around, though: GitHub itself has framed the pressure as needing to design for a future that could require roughly 30× today’s scale, not a 30× jump in traffic that has already happened. Fernando points out that GitHub isn’t “a website”; it’s a large API surface plus the runner infrastructure for Actions plus everything agents now hammer. And they note the irony that GitHub pulls this off while owned by Microsoft and standing up more compute through its migration to Azure — something the internet rarely credits. As Fernando puts it, everyone is “throwing stones at GitHub,” but the load it handles is enormous.
The hosts float a structural explanation for the recent wobbles: a lot of people online tie GitHub’s struggles to Microsoft’s reorganization, where GitHub reportedly stopped being an independent business unit and got folded under Microsoft’s core AI organization. Andrey connects that to the product feel — the sense that you go to click the Actions tab and an Agents button has appeared where Actions used to be, “AI over all the things.” Vladimir Samoylov adds a sharper worry: if it’s AI everywhere, that likely includes AI writing the product itself. Fernando ties that to a “fix-forward” culture (“it breaks, we fix it, keep moving”) that could show up as instability well beyond raw load.
GitHub turned into social media
One of the episode’s more memorable riffs is that GitHub has quietly become a social network. Fernando recounts a marketer posting a screenshot of her GitHub profile on LinkedIn, telling her fellow marketers that if you’re a marketer without a GitHub profile today, you’re being left behind — because non-engineers are now shipping things with coding agents. That’s a whole new category of user on the platform: not agents, and not the people who historically wrote code.
Fernando says his last AWS Summit talk in Bangkok compared GitHub to Instagram — a repository is now effectively your picture, your public artifact. Vladimir extends it: GitHub already has a feed and news you can scroll. The point isn’t decoration. If the platform’s audience is expanding from engineers to marketers-with-agents, the demands on it — and the definition of “downtime hurts” — change with it.
The new forges: Entire and Cursor Origin
The concrete reason to have this conversation now is that two offerings have just surfaced — and it’s worth being honest about how early both are. Andrey walks through Entire, launched by former GitHub CEO Thomas Dohmke, which he describes as starting from the fact that Git was always distributed — GitHub just centralized hosting on one platform. Entire’s pitch is a network of mirrors around the world: you mirror your GitHub repository onto their network, keep your code where it lives, and let agents clone, branch, and pull from a faster, closer copy while work syncs back. It’s shipped as a preview — existing users and the launch regions (US, EU, Australia) are live, but new signups are waitlisted while the team watches load. Vladimir cuts through the branding — “it’s just a torrent ecosystem where you’re mirroring things around.” That’s fair as a mental model, though the plan reaches further. Entire’s published roadmap names native repository hosting, self-hosting, CI/CD, and identity and organization features — the layer around Git that actually keeps people on GitHub. Andrey expects it to keep going, bootstrapping the rest of that layer as they build, including issues and discussions, even though Entire hasn’t announced those. Andrey’s read is that mirroring is the wedge, because people won’t leave GitHub without a strong reason, so inertia keeps their canonical repo there while Entire earns trust.
The other entry is Origin from Cursor, built from scratch on the assumption that dozens or hundreds of agents will hammer a single repo at once. Origin is further back still: its public page is a waitlist, so this is an announcement more than something teams can run today. Vladimir points to a figure reported from Origin’s launch coverage: roughly 22 commits per second into a single repository. Treat that as a reported demo number, not a verified benchmark. For context, GitHub documents a recommended maximum of six Git pushes per minute per repository — but that isn’t a like-for-like comparison, since a single push can bundle many commits, so the two figures can’t be stacked into an orders-of-magnitude claim. Both are also distinct from GitHub’s REST API rate limits. Origin’s launch coverage also highlights automated merge-conflict resolution as a feature aimed squarely at the agent-scale problem. Andrey adds a qualifier: some of these systems promise open-source, self-hostable backends, so even if the central network goes down you can still run a node, and he adds sovereignty to the mix — geopolitical tension gives teams real reasons to want a Git node closer to home. Making Git hosting distributed again, they agree, is the part of this trend with the strongest arguments; the “AI forge” framing may be riding the hype wave.
Is Git even the bottleneck?
This is the episode’s central skepticism, and the hosts keep returning to it. Vladimir makes the strongest case for the new forges by naming the real constraint: GitHub’s REST API caps a personal access token at 5,000 requests per hour — and Enterprise Cloud membership doesn’t lift that ceiling for a personal token. The higher 15,000-per-hour limit applies instead to eligible GitHub App or OAuth app requests made on a user’s behalf. The GITHUB_TOKEN used inside an Actions workflow is scoped separately again — 1,000 requests per hour per repository, rising to 15,000 per repository for GitHub Enterprise Cloud. At human pace that’s plenty — you branch, review, comment. Multiply yourself by 20 or 50 agents, and CI/CD pipelines and automation start slamming into those limits; with agents it’s 10× or 30× the call volume. GitHub has to protect the API, he notes, or it becomes unusable — “like Twitter in the big years.”
But Andrey draws a careful line: most of his own GitHub pain has been the API and the machinery around Git — rate limits, Actions not running — not the core Git operations of clone and branch. His example: AI jobs that audit every repository in an org (say, how a GitHub organization is configured via Terraform) fire enormous request volume, but that’s the GitHub API, not git clone. Vladimir wonders whether a new model of Git could let you commit a one-line change to a remote without pulling the whole codebase locally first — a genuinely different workflow. Yet even he questions whether teams need 22 commits per second, and he raises the human cost, too: shovel thousands of agent commits into a branch and the history loses its meaning, since Git history exists so people can understand how something evolved.
The other under-appreciated point comes from Vladimir: issue and comment threads were designed for humans, not agents. When an agent wants to comment on a specific line, it has to pull all the context and map the comment back to the right line — friction that has nothing to do with Git and everything to do with the lack of an agent-native standard around it. And Andrey adds the CI/CD reality check: branching may take a millisecond, but the unit tests that run afterward take much longer, so rapid-fire branching doesn’t remove the real wait.
The real dependency, and the Theory of Constraints
When Andrey names what actually scares people about GitHub, it isn’t speed — it’s dependency. Two years ago, when the team’s GitHub went down, work simply stopped: you couldn’t ship a fix for a production incident because you didn’t have the credentials to deploy in a compliant way outside the platform. That single point of failure, not clone latency, is what makes teams nervous now that everyone wants to move fast.
To frame whether agent forges even attack the right problem, Andrey reaches for the Theory of Constraints — Eliyahu Goldratt and Jeff Cox’s The Goal, the business novel about a plant manager who turns his factory around by optimizing the slowest element in the chain, because that’s what drags down the whole system. Andrey’s argument: Git isn’t the slowest element. In 2026 the constraint is still the humans doing reviews. Optimizing Git throughput while the bottleneck sits elsewhere is optimizing the wrong station. He ties it to the Agile manifesto’s line about “the art of maximizing work not done” — and to a meme he can’t shake: “now with coffee I can do much more stupid stuff faster.” The deeper waste, Andrey adds, is running huge fleets of distributed operations on code you’re likely to throw away.
That leads to a half-joking pendulum swing back to self-hosting. If GitHub is a dependency risk, Andrey suggests, dust off Artifactory and Nexus, and keep a Jenkins JAR — plugins and all — parked in your artifact store, ready to spin up when needed. Fernando, who says he hasn’t touched Artifactory since around 2019, plays along; Vladimir chimes in that “Jenkins is fast.” The serious version, Vladimir adds, is the local mirror: if agents talk to a mirror close to home, then clone, fetch, and local or Entire-native Git work stop depending on GitHub being up, close, or under its rate limits — you run as many agents as you want against the mirror and sync when the work is done. The caveat the hosts don’t dwell on: a push backed by GitHub still runs at GitHub’s speed, and Actions, issues, and the GitHub APIs remain dependencies. As Andrey summarizes the cycle: everything moved to SaaS, and now the pendulum is swinging back toward self-hosting.
At what scale does this actually matter?
The hosts close by pressure-testing the scale assumption. Fernando cites the framework from Claude Code’s creator, Boris Cherny, describing levels of AI adoption — roughly a progression from pair-programming, to coordinating ~10 agents, to ~100, to 1,000-plus. Cherny reportedly places himself at the upper end personally while pushing Anthropic org-wide toward that direction. Fernando’s inference is pointed: if even a frontier lab isn’t routinely operating fleets of thousands of agents, then most people complaining about GitHub probably aren’t there either — so is the problem really throughput, or just “this blocks me”? Vladimir sketches where scale would bite: a big enterprise monorepo with a hundred thousand agents all cloning at once, then constantly rebasing — “a complete mess.”
Andrey grounds it in his own experiment, extending the last two episodes. He combined Viktor Vedmich’s cmux advice from episode #13 with the loop engineering from episode #14: spawning agents inside cmux panes so an orchestrator can observe what each one is doing through the cmux API — visibility you lose when Claude Code opens and closes sub-agent tabs. With a bigger Codex subscription he ran a loop for 12–13 hours. It works, but the bottleneck wasn’t Git — it was the model looping on a hard problem, failing, restarting, and needing careful scoping (“don’t try to eat the whole elephant in one go”).
The natural next step — parallelizing into a best-of-N race where a planner spawns three or four agents attacking a problem from different angles — is where both cost and doubt spike. Vladimir estimates this style of work could run $5,000–$7,000 per month per developer, and notes best-of-five was more compelling before models learned to explore multiple approaches under the hood; you also still have to describe how to pick the winner, and if you can describe the best solution that precisely, maybe you didn’t need five tries. Fernando is candid about his own resistance to going fully hands-off and blunt about the waste: “the amount of wasted tokens on this is insane.” Andrey shares the doubt, worried the quality lands at “very meh” because the model makes its own calls along the way. Vladimir offers the one case where fan-out earns its cost — give each agent a different goal (shortest solution, then a security review, then consensus) rather than five identical attempts. And he pins his personal bottleneck with refreshing honesty: not Git operations, but how fast his home internet can pull a fresh repo for each new agent — exactly the pain a local mirror would fix.
The hosts don’t declare a winner. Their stance, fitting a weekly show, is to put the trend on your radar: it’s too early to judge where AI-native forges land, but making Git hosting distributed again has real arguments behind it — and it is worth watching which parts survive the hype.
Resources
- An update on GitHub availability (GitHub Blog) — GitHub’s own post and the primary source for two claims the hosts lean on: the need to “design for a future that requires 30X today’s scale” (a future target, not a 30× jump already absorbed) and leveraging “our migration to Azure to stand up a lot more compute.”
- An entirely new Git hosting network (Entire blog) — Entire’s own launch post and published roadmap: native repository hosting, self-hosting, CI/CD, and identity/organization features, plus the caveats that new users are waitlisted during the preview and a branch backed by GitHub still pushes “as fast as GitHub allows.”
- Cursor Origin — official waitlist and its launch report (AlphaSignal) — Origin’s own page is currently just a waitlist (“a git forge for the agentic era”), confirming it’s an announcement rather than something teams can run today; AlphaSignal’s launch report is the source for the throughput number the hosts cite — Cursor’s on-stage Compile demo showed 22.6 commits per second inside a single repository (plus hundreds of thousands of clones per hour). Treat it as an unverified demo figure, not a production benchmark, which is exactly how the episode frames it.
- Cursor, GitLab and Zed agree GitHub is breaking. They disagree on how to rebuild it (The New Stack) — the best single overview of the “new forge” wave the episode reacts to: three vendors that agree GitHub is straining under agent-scale load but propose different rebuilds — Cursor’s from-scratch Origin, GitLab’s AI-native redesign, and Zed’s approach. Useful for the framing; the commit-throughput demo number and the Hacker News/Reddit reaction are sourced separately, not from this piece.
- Rate limits for the REST API (GitHub Docs) — the precise, differently scoped limits behind Vladimir’s core argument: 5,000 requests/hour for a personal access token (Enterprise Cloud membership does not raise that; the 15,000/hour figure applies to eligible GitHub App or OAuth app requests made on a user’s behalf), and a separate
GITHUB_TOKENlimit of 1,000 requests/hour per repository (15,000 per repository for GitHub Enterprise Cloud). - Repository limits (GitHub Docs) — GitHub’s Git push guidance: a recommended maximum of six pushes per minute per repository. Useful context for the throughput discussion, though not directly comparable to Origin’s commit-per-second figure, since one push can carry many commits (and a different constraint from the REST API rate limits).
- Episode #13 — cmux vs iTerm with Viktor Vedmich — where Viktor’s cmux workflow and socket API came from; Andrey builds on it to observe agents running inside cmux panes.
- Episode #14 — Loop Engineering in DevOps — the loop-engineering foundation behind Andrey’s 12-hour Codex run and the best-of-N parallelization discussion here.