OpenAI’s Pando Git backend cuts push latency by about 80%

By Tom Whitfield

OpenAI says its Pando Git backend cuts push latency by about 80% and serves nearly a petabyte of Git data each day. The company built the Rust system for its engineering monorepo and announced it on Nov. 2. OpenAI also said Pando had carried production traffic since April.

Why did OpenAI need Pando?

OpenAI’s existing monorepo systems began struggling around the end of 2025 as Codex let each engineer run more work in parallel. That load produced slow fetches, slow pushes and failed merges. GBHackers, summarizing OpenAI’s technical post, reported that merge reliability dropped below 90% at some points.

OpenAI said it built Pando to handle the larger volume of pushes and fetches generated by engineers running many Codex agents at once. The company preserved Git’s protocol and client behavior, so engineers and agents continued to use Git in the same way. Its immediate purpose was to add capacity and restore dependable merges.

Pando addressed a server bottleneck created by parallel agent work without asking developers to change their tools.

How does Pando handle heavy Git traffic?

OpenAI rebuilt only the server. Pando stores each pushed packfile as an immutable blob and records a version for each branch in a metadata store. It therefore processes pushes to different branches in parallel while ordering pushes that target the same branch.

On a fetch, the client identifies the commits it has and wants. Pando returns links to stored packfiles that cover the missing commits rather than constructing a custom pack for every client. Reusing those packs across many readers lets the system serve data from cache.

OpenAI’s technical results, as reported by GBHackers, show the scale and benefit of that design:

• Peak load exceeded 57 TB of Git packs in an hour.
• More than 99% of peak traffic came from local disk cache.
• Merge reliability after cutover reached 99.99%.

By reusing stored data and separating branch updates, Pando removed much of the work that had slowed the old server.

How did OpenAI build Pando in 10 weeks?

One engineer designed Pando’s core, and teams of agents implemented it in Rust. OpenAI moved the project from inception to production in about 10 weeks. Pando has served production traffic since April.

The first deployment ran as a read-and-write-through proxy to the old system. OpenAI could therefore cut over live traffic without downtime while the new backend took over.

OpenAI checked the service with a conformance test suite and deterministic simulation testing. Agents also wrote Lean and TLA+ specifications for the system.

The build combined one human-led design, agent implementation and several layers of formal checking.

Could Pando move beyond OpenAI?

OpenAI has contributed fixes to Git, including cleanup after an interrupted packfile download. Several of those changes are already upstream, while the remaining changes sit in OpenAI’s public Git fork.

OpenAI president Greg Brockman wrote that the company “took the hard road of continuing to use Git,” a choice that kept Pando from changing the developer experience. He also said the company is “considering providing this to others.” That statement signals interest in wider distribution, not a committed release schedule.

Pando remains separate from Pierre Computer, the developer-infrastructure startup OpenAI agreed to acquire two days after the Nov. 2 disclosure. After the acquisition closes, OpenAI plans to fold Pierre’s Code Storage service into Codex. Pando therefore addresses Git capacity inside OpenAI’s own operation, while the Pierre transaction concerns storage inside Codex.

OpenAI’s next commercial step depends on whether it makes Pando available beyond its own engineers. Its nearly petabyte-a-day load and 99.99% post-cutover merge reliability provide the operating evidence, while any wider release remains only under consideration.