OpenAI Pando: The Git Backend Built for Codex-Scale Pushes

OpenAI published how it rebuilt the server side of Git after Codex made its monorepo too busy for conventional hosting. The system is called Pando, the post is "Scaling Git at OpenAI", and the headline numbers are vendor-reported: median push latency cut by nearly 5x and nearly a petabyte of Git data served per day. If you searched "OpenAI Pando git", the short version is that this is another case study from the far end of the agent curve, not a product you can install today - but the design choices are a useful map of what breaks first when agents do most of your pushing.

Last updated: November 3, 2026

What the primary source says#

The OpenAI engineering post, dated November 2, 2026, lays out the problem plainly. Codex lets engineers run far more work in parallel, which means more branches, more pushes, more merges, and more fetches and clones from development environments, research jobs and CI. OpenAI says that starting around the end of last year its monorepo systems struggled with slow fetches and pushes and failed merges, with reliability at times below 90%.

Its answer was Pando, a backend that keeps the Git protocol and client but changes what the server does. According to the post, Pando now powers all development in OpenAI's monorepo, began serving production traffic in April, and was built with Codex in 10 weeks, with the core designed by a single engineer and implemented by teams of agents.

Two design moves carry most of the weight:

• Causal consistency instead of repository-wide consistency. Each push is stored as an immutable packfile in a blob store, and each branch move records a "ref version" in a metadata store. Only pushes to the same ref conflict. The cost, which OpenAI states openly, is that a client reading several branches cannot assume those reads describe one point in time across the repository.
• Reusing packfiles instead of building one per client. A conventional server computes a bespoke pack for each fetch. Pando reuses the packs pushed earlier and hands clients links to them through the Git packfile-uri feature, served from regional caches. OpenAI reports cache hit rates above 99% and says clone and fetch operations saturated 10 Gbps links on standard cloud virtual machines.

A third piece keeps this from collapsing under its own file count: background compaction, borrowed from log-structured merge-trees, that merges small pushed packs into larger "covers" so a client that is far behind does not need tens of thousands of separate downloads.

The reported results, all OpenAI's own: median push latency cut by nearly 5x (the post also phrases it as nearly 80%), improved merge reliability, more than 57 terabytes of packs served in a single hour with over 99% from local disk cache, and nearly a petabyte of data per day.

The angle: git is where agent throughput gets taxed#

For a year the agent conversation has been about models, context and tools. Pando is a data point that the next bottleneck is boring infrastructure. When one engineer drives several agent sessions and each session pushes, the arrival rate on your version control server stops looking like a human team and starts looking like a build farm.

This is now a pattern, not a one-off. Anthropic described replacing Git for its own merges, which we covered in Anthropic Scion. Cursor announced a forge built for agents in Cursor Origin. A commenter on the Hacker News thread counted OpenAI's post as the fifth major article from large vendors on scaling source control for this workload. The notable difference in OpenAI's version is the choice to stay Git-compatible and push fixes upstream rather than replace the model.

Who wins and who loses from that choice:

• Teams already deep in Git tooling win. Review tools, CI, hooks and every agent harness that shells out to git keep working. OpenAI says it migrated hundreds of integrations alongside Git traffic.
• Teams that want a new version-control model lose a reference point. If the largest agent shop can scale the existing protocol with a different server, "Git cannot cope" gets a harder argument to make.
• Self-hosted Git platforms carry the second-order pressure. Per-client pack generation and repository-wide ref ordering are exactly the costs OpenAI says it removed, so expect vendors to be asked when similar ideas reach their products. OpenAI has not announced that it will ship Pando to customers.

What a builder does Monday#

You almost certainly do not have a monorepo at OpenAI's rate, and Pando is not available to you. Still, the post points at habits that pay off at much smaller scale. These are conclusions from the post, not tested benchmarks of ours.

1. Give every agent its own branch. Pando's whole model rewards pushes that touch different refs. The same logic is why parallel agents work best on separate worktrees - see Git Worktrees + Claude Code and Codex CLI worktrees.
2. Do not assume a multi-branch read is a snapshot. On a causally consistent server, two agents can briefly see different versions of two branches. If your orchestration reads branch A and branch B and treats them as one state, record the commit IDs you read instead.
3. Measure push-to-fetch latency in your own pipeline. OpenAI treats the time from one agent pushing to another reader being able to check out that commit as the metric that matters for collaboration. It is cheap to log and rarely tracked.
4. Use --force-with-lease for agent branches. OpenAI says its Git build adds "explicit haves" so that on Pando a client can use this flag to check that a feature branch has not moved and still build its pack against trunk alone. The flag itself is standard Git; the Pando-specific benefit is OpenAI's claim and applies to its build.
5. Expect smaller, more frequent pushes to cost something. The post notes that advertising only a trunk branch keeps the ref advertisement small but means repeat pushes to a branch resend objects outside trunk. OpenAI reports a median pack of under 20 KiB and a 99th percentile under 3 MiB in its monorepo.

What people are actually saying#

The Hacker News thread had 172 points and 86 comments when we read it, and it split into three camps.

• "Is this actually new?" One commenter pointed out that Meta and Google have run similar ideas for a decade or two, so this is less a breakthrough than agent-era demand arriving at a known problem. Another reply argued git scaling limits hit big tech long before AI, which is a fair counter to using this as proof that agents are special.
• "Why is there so much code?" Several commenters asked what exponentially more commits are producing. A reply argued that software has always been supply-limited, so cheaper code makes marginal projects worth doing. Another asked what tangible benefit that many pull requests have delivered.
• "Git is becoming a protocol." One commenter argued that agent-written code nobody reads makes the point of sharing moot, while low-level plumbing still has to be simple and shared, so Git is turning into a protocol that several products sit behind. Separately, a commenter running OpenAI's GPT-6 Astra said it often produces code that works but is poorly architected, which is an argument that volume and quality are different problems.

The practitioner takeaway from the thread is skepticism about the numbers' meaning rather than the engineering: nobody disputed that the server work is real, many disputed what the traffic represents. We did not find independent verification of OpenAI's latency or throughput figures, so treat them as the vendor's.

Limits and open questions#

• No release. The post says OpenAI is exploring ways to share the technology with users. That is not a commitment.
• Vendor-reported. The 5x and petabyte figures come from one company's monorepo. The post's interactive comparison against two other designs is labelled by OpenAI as a synthetic teaching model, not a production benchmark.
• Consistency trade-off. Dropping repository-wide point-in-time reads is fine for OpenAI's workflows by its own account ("users and agents are agnostic to the global ordering of ref updates"). Your tooling may not be.
• Agent-built. OpenAI says Codex built much of Pando, with a conformance test suite against standard Git and deterministic simulation tests, and that GPT-6 Astra was used to write Lean and TLA+ specifications. For the model itself see our GPT-6 Astra release guide.

Continue Reading#

• Anthropic Scion: Why Anthropic Replaced Git for Agent-Scale Merges - the other lab's version of the same problem
• Cursor Origin: A Git Forge Built for AI Agents - the forge-level answer
• Oak: A New Version Control System Built for AI Agents - the replace-Git camp
• Git Worktrees + Claude Code: Run Parallel Agents - the small-team version of branch-per-agent
• Codex CLI Worktrees and Durable Sessions - how Codex isolates parallel runs

Sources#

• OpenAI - Scaling Git at OpenAI
• Hacker News - Scaling Git at OpenAI discussion
• Git documentation - git push --force-with-lease