OpenAI's Pando Is Not Open Source. Almost Nobody Noticed

The post announcing Pando never says the word open-source. Within a day, four aggregator stories and a handful of Reddit threads were calling it an open-source release anyway.

It wasn't.

The post closes with a line about exploring ways to share the technology. That is what you write when there is no repo, no license, and no date.

i checked github.com/openai/pando myself. 404.

That gap is the story. The engineering underneath is real and worth reading. The reaction around it ran ahead of the facts by about half a day, and almost nobody noticed.

Here is what got buried. OpenAI's monorepo was coming apart. Reliability dropped below 90% at times.

Fetches stalled, pushes stalled, merges failed. Commits landing on master grew 2,442% off a Q1 2024 baseline.

Codex did that. One engineer now keeps five branches alive at once, and every push spins up CI jobs that all fetch the same commit.

You have felt a smaller version of this. Your pipeline re-clones for every job. Your agent opens six branches before lunch.

Scale that to a few thousand people and a tool from 2005 stops holding.

What Pando actually is

Most write-ups say OpenAI replaced Git. It didn't. Pando is a backend.

Same protocol, same client, same git push. Engineers kept typing what they already typed.

That choice is the interesting one. Anthropic went the other way in October and moved its monorepo off Git entirely, onto something called Scion. OpenAI kept the wire format and rebuilt what sits behind it.

i tried to explain this to a friend who runs a 12 person startup. He asked if he should care. i said no, then talked for another ten minutes anyway.

The cost of staying compatible is constraint. You inherit every assumption Git makes, including the ones causing the problem.

The benefit is that nobody retrains. No migration doc, no new CLI, no six month rollout where half the team is on the old thing.

Two tricks, one tradeoff

The first trick is per-branch coordination. Pando updates each branch on its own. Pushes to unrelated branches stop waiting on each other.

The tradeoff is honest and a little unsettling. A client reading several branches can see them at different points in time. There is no single snapshot of the repo anymore.

The second trick is packfile reuse. Normally a Git server builds a fresh pack for every client, tailored to what that client already has. That costs CPU on every fetch.

Pando serves the same bytes to everyone and lets clients download some objects they already own.

Here is the comparison OpenAI laid out:

They picked the row with the asterisk. Causal consistency is a real downgrade. And it is the only row that survives the traffic.

The packfile trick

The detail i keep coming back to is packfile-uri. It is an underused part of the Git protocol that lets a server hand back a link to a pack instead of streaming it. Pando leans on it for almost everything.

The numbers: 57 terabytes of Git packs served in one hour, with more than 99% of those bytes coming off local disk cache. A petabyte a day on a handful of CPU cores.

The background job that makes it work is LSM compaction. Every push produces a tiny L0 pack. Workers fold those into wider covers, L1 through L4, and a fetch walks the levels like a skip list.

They did not invent a new storage engine. They noticed Git already had the hooks and used them properly.

That is the part i respect most. No heroics, just reading the protocol closely enough to find what was already there.

Ten weeks and a lot of agents

Pando went from kickoff to production in 10 weeks. One engineer designed the core. Teams of agents implemented it.

A handful of humans deployed it. It started serving real traffic in April.

It is written in Rust, with no legacy dependencies. That part is normal for a greenfield service in 2026.

The strange part is the validation. Agents wrote Lean and TLA+ models of the system, then used them to hunt race conditions in negotiation and pack planning.

Sessions ran for hundreds of hours. Other agents red-teamed Git and Pando around the clock.

i do not know what to do with that. A model checking a model is either the most useful loop in software right now or a very expensive way to feel safe.

i lean toward useful. But i want to see the bugs it caught, not just the hours it ran.

What people actually said

Hacker News split the usual way. The thread had 180 comments and most of them argued about whether the commit numbers mean anything.

One commenter said commit volume is a proxy for how fast code changes, not for whether the change was worth making. Another said the whole thing reads like a factory for randomizing a spreadsheet cell. Harsh, and not wrong.

But my favorite comment was the one that misremembered the number. The post says nearly a petabyte per day. The comment said 5 petabytes of git commits.

Nobody corrected it.

That is how fast a technical detail turns into folklore.

Pando is also the name of a grove in Utah. It is one organism, a single aspen clone connected by one root system, spread across about 106 acres.

Around 47,000 trunks, all genetically identical. It is one of the oldest and largest living things on the planet.

i think about that whenever i read naming decisions. Someone at OpenAI picked Pando for a system that coordinates thousands of parallel branches. Either they knew about the aspen or they got lucky.

If they knew, it is a better name than they get credit for. One root system, many trunks, all sharing the same history. That is literally the architecture.

Who this is not for

If you have 40 engineers and a monorepo that fits on a laptop, you do not need this. You will never need this. git is fine and will stay fine.

Even at scale, try the boring fixes first. Shallow clones, sparse checkouts, a mirror or two, and CI that stops cloning the world for every job. Anthropic ran hundreds of internal mirrors before giving up and writing Scion.

And the honest critique: Pando is not available. You cannot download it, run it, or benchmark it. What shipped this week is a very good engineering post and a pile of secondhand summaries that got the release status wrong.

"We're exploring ways to share" is doing a lot of work in that last paragraph. i would not plan around it.

The number i cannot shake is 2,442%. That is commit growth in under three years, on one repo.

Somewhere in there is a graph nobody reads, growing because agents are cheap and branches are free. Pando makes that graph easier to write to. It does not make anyone read it.

The aspen does not have that problem. Forty seven thousand trunks, one organism, no pull requests. Sometimes i think the tree got it right.