OpenAI's Pando: a Git backend built for Codex-scale work

What happened?

OpenAI introduced Pando on its engineering blog, an in-house, Git-compatible backend for Git repositories (OpenAI). It now powers all development in the company's monorepo. Engineers and agents keep using Git exactly as before; only the server side changed underneath them.

The reason is simple: Codex lets one engineer run several changes in parallel. That means more branches, pushes and merges, and every push can set several CI jobs fetching the same commit. From around the end of last year the old system struggled to keep up, with reliability at times falling below 90%.

What makes Pando different?

Pando optimizes for two things: many writers pushing to different branches in parallel, and many readers quickly fetching the same history. To get there, it relaxes two common assumptions.

• No repository-wide consistency. Each branch is updated independently, so pushes to unrelated branches never wait on each other. Clients only conflict when they push to the same ref at the same time. OpenAI calls this causal consistency.
• No unique packfile per client. Incoming packfiles are stored unchanged in blob storage, and the server later hands those same packs to clients that fetch. A client may download some objects it already has, but the server does very little computation.
• On push, the server by default advertises only the trunk branch. The resulting pack depends only on trunk, so anyone can reuse it. In OpenAI's monorepo the median pack was under 20 KiB and the 99th percentile under 3 MiB.
• Fetches rely on Git's little-known packfile-uri feature: the server returns links, and a regional cache service called Express serves the packs with a hit rate above 99%.
• Background compaction merges small packs, modeled on log-structured merge-trees, currently from L0 up to L4. That keeps fetch planning logarithmic.

What did it deliver in production?

Median push latency dropped by nearly 80%, and merges became more reliable. Pando delivers nearly a petabyte of Git data per day with a handful of CPU cores, and has served more than 57 terabytes in a single hour. On standard cloud VMs, clone and fetch saturate 10 Gbps network links.

The post includes an interactive simulation comparing Pando with designs based on three-phase commit (3PC) and a write-ahead log (WAL). OpenAI stresses these are synthetic teaching models, not production benchmarks.

How was it built?

Pando is written in Rust from scratch, without legacy dependencies. It went from kickoff to production in 10 weeks: a single engineer designed the core, teams of agents implemented it, and a handful of engineers deployed it. It began serving production traffic in April.

Validation relied on a Git conformance test suite, deterministic simulation testing and formal methods: agents using GPT-6 Astra wrote Lean and TLA+ to formalize the system, which surfaced several bugs. The rollout started as a proxy in front of the old system, and developers could simply ask Codex to migrate their environments.

What comes next?

OpenAI has already upstreamed several improvements to Git, including fixes around packfile-uri, and others live in its public Git build. The company says it is exploring ways to share the technology behind Pando with its users.

The lesson applies more broadly: once a team works with agents, source control quickly becomes a bottleneck. Anyone running many parallel agents on a large monorepo should start measuring push and fetch latency now.