Codex broke OpenAI's Git, so it built Pando. The coordination problem sits one floor up
Agents do not just burn GPUs. They wreck the boring stuff. OpenAI's engineering post on Pando, published Monday and at 261 points on HN by Tuesday, gives a rare first-party number: starting around the end of last year, the systems behind its monorepo fell at times below 90% reliability, with slow fetches and failed merges, because Codex let engineers do far more in parallel.
Pando is a new Git backend, and the client and protocol stay Git, so nobody had to change how they work. The design trick is giving up something Git hosting usually promises. Each branch is coordinated on its own, so pushes to unrelated branches do not fight over one lock. The tradeoff, stated plainly: a reader looking at several branches can see them at different points in time. Reads come from shared packfiles in cache instead of a custom pack for every client. OpenAI reports median push latency down nearly 5x and nearly a petabyte of Git data served per day. These are self-reported, and it is the kind of problem few companies have yet. Everybody running a swarm of agents is headed toward a small version of it.
Two papers from the same week show what Pando does not fix. ParallACT tests parallel coding agents against a single-agent oracle, and on tasks with contradictory requirements Claude Code with Opus 4.8 drops from 62% to 16%, with the same gap in six more configurations. Telling an agent that a peer exists does not significantly help. Giving them a chat channel recovers only a small part and costs tokens. Switch-SWE looks at the human side of parallelism, interleaved unfinished work, and finds it costs seven coding agents 11.5 points on average, with a context-management plug-in recovering 5.5 to 15.5 points on OpenCode.
Put together: storage for parallel writes is now a solved problem if you have OpenAI's budget, and merging the intent behind those writes is not. Your Git can take a thousand pushes an hour. Whether those pushes agree with each other is a different question, and more agents make it worse.
Pando: https://openai.com/index/scaling-git-at-openai/ ParallACT: https://arxiv.org/abs/2611.00314 Switch-SWE: https://arxiv.org/abs/2611.02017
← Back to all articles
Pando is a new Git backend, and the client and protocol stay Git, so nobody had to change how they work. The design trick is giving up something Git hosting usually promises. Each branch is coordinated on its own, so pushes to unrelated branches do not fight over one lock. The tradeoff, stated plainly: a reader looking at several branches can see them at different points in time. Reads come from shared packfiles in cache instead of a custom pack for every client. OpenAI reports median push latency down nearly 5x and nearly a petabyte of Git data served per day. These are self-reported, and it is the kind of problem few companies have yet. Everybody running a swarm of agents is headed toward a small version of it.
Two papers from the same week show what Pando does not fix. ParallACT tests parallel coding agents against a single-agent oracle, and on tasks with contradictory requirements Claude Code with Opus 4.8 drops from 62% to 16%, with the same gap in six more configurations. Telling an agent that a peer exists does not significantly help. Giving them a chat channel recovers only a small part and costs tokens. Switch-SWE looks at the human side of parallelism, interleaved unfinished work, and finds it costs seven coding agents 11.5 points on average, with a context-management plug-in recovering 5.5 to 15.5 points on OpenCode.
Put together: storage for parallel writes is now a solved problem if you have OpenAI's budget, and merging the intent behind those writes is not. Your Git can take a thousand pushes an hour. Whether those pushes agree with each other is a different question, and more agents make it worse.
Pando: https://openai.com/index/scaling-git-at-openai/ ParallACT: https://arxiv.org/abs/2611.00314 Switch-SWE: https://arxiv.org/abs/2611.02017
Comments