Scaling Git at OpenAI
- ID
- 42575
- Status
- summarized
- Published
- 03 Nov 2026, 7:47 AM
- Fetched
- 04 Nov 2026, 12:27 AM
- Provider
- Hacker News
- Category
- dev-community
- Original URL
- https://openai.com/index/scaling-git-at-openai/
- Source URL
- https://hnrss.org/best
Summary
- Score
- 7.0
- Created
- 04 Nov 2026, 12:28 AM
- Tags
- Audience
- developersvibe_codersai_agent_users
What happened
OpenAI built Pando, a Git-compatible backend for its monorepo, to handle the concurrency created by Codex: many branches, pushes, merges, and CI fetches happening at once. Before Pando, reliability sometimes fell below 90%; in production it cut median push latency by nearly 5x and now serves nearly a petabyte of Git data per day while keeping the Git protocol and client unchanged.
Why it matters
If your team runs a monorepo with CI jobs repeatedly fetching the same commits, treat push concurrency and fetch fan-out as separate scaling problems. OpenAI's numbers give you concrete thresholds to instrument against: sub-90% reliability, ~5x median push-latency improvement, and ~1 PB/day served. The useful decision is to prefer a backend change that preserves Git protocol/client compatibility over forcing engineers and agents onto a new workflow.
Discussion angle
Where would agent-driven branch creation break first in your setup: concurrent pushes, CI fetching the same commit repeatedly, or clone/fetch bandwidth, and what metric would you track before considering a Git backend rewrite?