On 2 November, OpenAI published “Scaling Git at OpenAI”, an engineering post about a problem most teams haven't hit yet. Once its engineers started running many Codex tasks in parallel, the systems serving its main monorepo began to struggle. Fetches and pushes got slow, and merge reliability sometimes fell below 90%. Its fix was to build a new Git backend, called Pando.
You are not OpenAI, and you will not be writing a Git server. But the cause of their problem applies to any team that gives engineers coding agents: agents don't just write code faster, they create far more repository traffic. That load lands on your Git hosting, your CI and, above all, your reviewers.
What happened at OpenAI
According to the coverage in GBHackers and Cyber Security News, the trouble started around the end of 2025. Codex let each engineer run more work in parallel, and every task means branches, pushes, merges, fetches and clones from development environments, research jobs and CI. Interesting Engineering reports that quarterly commits to the monorepo grew 2,442% since the first quarter of 2024.
OpenAI concluded that Git itself was fine and the bottleneck was how the monorepo was served. Pando keeps the normal Git client and protocol, so signed commits and branch protections still work. Underneath, it stores each pushed packfile as an immutable blob and tracks branch versions in a metadata store, so two pushes only conflict when they target the same branch. It also stops advertising every branch to every client, since with millions of branches that list alone could pass 100 MiB.
The reported results:
- median push latency down by nearly 80%;
- merge reliability up to 99.99%;
- nearly a petabyte of Git data served per day, with over 99% of it from local cache.
The build itself is a story about agents too. One engineer designed the core, teams of Codex agents implemented it, and it went from start to production in ten weeks, taking live traffic from April 2026. Agents wrote Lean and TLA+ specifications to find bugs, and OpenAI says agents now red-team Git and Pando around the clock.
Why a 30-person team should care
Your Git host will almost certainly cope. GitHub and GitLab serve repositories with far more branches than yours. What changes is everything around the repository. When each engineer runs three or four agent tasks at once, you get three or four times the branches, the pull requests and the CI runs, while the number of people who can review them stays the same.
OpenAI's warning signs are worth borrowing, because they show up long before anything breaks: pushes and fetches getting slower, and merges failing more often. At a smaller scale they look like a CI queue that never empties, pull requests that conflict with each other because they were started from the same commit, and a branch list nobody can read.
What to change before the load arrives
- Measure merge health. Track how often a pull request's first CI run fails for reasons unrelated to its change, and how long merges wait. OpenAI's headline number was merge reliability. Yours can be too.
- Use a merge queue. Many parallel agent PRs touching the same files will pass CI alone and break main together. A merge queue tests each one against what is about to land, not against a stale base.
- Clean up branches automatically. Turn on automatic deletion of merged branches, and close agent branches that sit untouched for a week. Agents rarely tidy up after themselves.
- Make agent sandboxes cheap to start. A shallow or partial clone (
--depth 1or--filter=blob:none) and cached dependencies cut most of the cost of each new task. At OpenAI, clones and fetches could saturate 10 Gbps links, and its fix leaned heavily on caching. - Budget CI per task, not per engineer. Run the fast checks on every push and the slow suites when a PR is ready for review. Otherwise agents that push often will spend your CI minutes on work in progress.
- Cap work in progress. The real limit is review. If agents open more pull requests than your team can read carefully, more agents make things slower. A simple rule such as “no more than two open agent PRs per engineer” keeps the queue honest.
The takeaway
OpenAI had to rebuild part of its infrastructure because agents changed the shape of its traffic, not because anything was broken. Every team adopting coding agents goes through a smaller version of the same shift. Watch merge health and review load now, while the fixes are settings and team rules rather than a new backend.
Sources: OpenAI, “Scaling Git at OpenAI” (2 November 2026), GBHackers, Cyber Security News, Interesting Engineering.