Takeaway: On Nov 2, 2026, OpenAI detailed Pando — a new Git backend for its monorepo that keeps the Git protocol and client intact while redesigning how packs and refs are stored and served. Codex-driven parallel work had pushed reliability below 90% at times; Pando targets horizontally scalable concurrent branch pushes and maximum read throughput. In production it cut median push latency by nearly 5× (~80% reduction), delivers nearly a petabyte of Git data per day, has served >57 TB of packs in a single hour with >99% cache hits, and can saturate 10 Gbps on standard VMs. Built in Rust with Codex in about 10 weeks (production since April 2026). Distinct from this morning’s ChatGPT Chat/Work tabs merge and noon’s Anthropic Messages API message threads.
Primary source: OpenAI’s engineering post Scaling Git at OpenAI by Aaron Friel, Taylor Blau, and Ted Nyman (Nov 2, 2026). Corroboration: The New Stack on OpenAI Pando.
Why agent-scale monorepos broke the old Git serve path
Codex lets engineers land far more parallel work: more branches, pushes, merges, and fetches from developer machines, research jobs, and CI. One engineer can have several changes ready for CI at once, and each push can trigger several jobs fetching the same commit. OpenAI says that by late last year the systems behind its monorepo were struggling — slow fetches and pushes, failed merges, and reliability sometimes falling below 90%.
The team framed the question carefully: had they hit a limit of Git itself, or of how they served the monorepo? They chose to keep building on Git’s protocol and client so engineers and agents kept familiar workflows, and so client-side improvements could ship upstream beyond OpenAI. That is the contrast with approaches that replace Git wholesale: Pando is a backend redesign, not a new VCS.
What Pando optimizes for
- Horizontally scalable writes — concurrent pushes to many different branches without a single repo-wide lock ordering every ref update.
- Maximum read throughput — clients should download history fast enough to saturate available network bandwidth.
- Git compatibility — same protocol and client; agents and humans keep using Git as they already do.
Two conventional assumptions get relaxed. First, repository-wide point-in-time consistency of all refs is expensive under parallel writers; Pando uses per-branch (causal) consistency so unrelated branches do not wait on each other (a reader looking at several branches may see them at slightly different times). Second, unique packfiles per client burn CPU and disk; Pando reuses packfiles across fetches and serves the same bytes to many clients.
Architecture highlights (packs, Express, compaction)
On push, Pando validates the incoming pack while streaming it into a blob store, without unpacking into a local repository. It records a ref version (new tip, pack, dependencies) in a horizontally scalable metadata store. By default it advertises only a designated trunk as the base for feature-branch pushes, keeping advertisements small even with millions of branches and producing packs that other clients with trunk history can reuse. OpenAI reports median packfiles under 20 KiB and p99 under 3 MiB in its monorepo.
On fetch, Pando maps the client’s haves/wants to stored packfiles and returns them via Git’s packfile-uri feature (empty pack inline; packs downloaded separately). A regional caching service called Express serves packs with >99% cache hits. Background compaction follows an LSM-like pattern: each push is an L0 pack; workers build covers up to L4, improving compression and letting fetch planning select packs in roughly logarithmic time. Packs at every level are kept and served — not discarded after compaction.
Production numbers (from OpenAI)
- Median push latency cut by nearly 5× / roughly 80% reduction; merge reliability improved.
- Nearly a petabyte of Git data delivered per day.
- More than 57 TB of Git packs in a single hour.
- >99% of those bytes from local disk cache; clones/fetches can saturate 10 Gbps on standard cloud VMs.
- Built in Rust with Codex in ~10 weeks (one engineer core design; agent teams implement); production since April 2026.
OpenAI also describes an initial deploy as a read-/write-through proxy to the previous system so traffic could move without downtime, plus shipping its public Git build to developer machines and inside the ChatGPT desktop app.
Pando vs conventional Git serve patterns
| Dimension | Typical 3PC / WAL Git services | OpenAI Pando |
|---|---|---|
| Consistency model | Often repo-wide ordered refs / shared manifest | Per-branch causal consistency; serializable per ref |
| Concurrent pushes to different branches | Contend on quorum or shared WAL/manifest | Independent; only same-ref pushes conflict |
| Pack generation on fetch | Often custom pack per client (CPU/I/O heavy) | Reuse stored packs; packfile-uri + Express caches |
| Ref advertisement | Full hand can exceed 100 MiB with millions of branches | Default: advertise designated trunk as base |
| Client / protocol | Git | Git (compatibility retained) |
| Open source status | Varies by forge | Pando not open-sourced; exploring sharing tech with users |
Upstream Git contributions — and what is not open source
Because Pando leans on packfile-uri and reusable packs, OpenAI improved concurrent pack download/index paths, cleanup after interrupted transfers, resume behavior, and tracing — and contributed work upstream. Its public Git build adds parallel pack download/index and “explicit haves” so servers can advertise a tip separately from history a pushing client may omit (useful with --force-with-lease while packing against trunk). Several improvements are already upstream; others live in OpenAI’s public repository and patch tracker.
Pando itself is not open-sourced. OpenAI says it is exploring ways to share the underlying technology with users. That sits alongside other agent-infra stories on this site — GitHub Copilot connected cloud sessions + MCP connectors, Vercel Labs agent-desktop computer use, and DeepSeek’s open-source coding-agent prototype — without duplicating today’s ChatGPT UI merge or Anthropic thread-latency posts.
What this means for teams watching agentic CI
If your monorepo’s pain is many writers on many branches plus stampeding readers from CI and coding agents, OpenAI’s write-up argues the bottleneck was often the serve architecture (repo-wide coordination + per-client packs), not the Git CLI. Capacity stories such as ChatGPT + Codex shared December usage limits are a different layer — product quotas, not source-control backends. For publishers and platform teams, the actionable signal is: expect agent fleets to stress Git forges the way Codex stressed OpenAI’s, and watch for packfile-uri / cache-friendly designs rather than assuming “replace Git.”
Publisher / platform checklist
- Read the primary post — cite Scaling Git at OpenAI for numbers; do not invent pack or latency stats.
- Frame Pando as a Git backend, not a Git replacement; contrast peers that fork the client/protocol.
- Separate UI and API stories — Chat/Work merge and Anthropic message threads are not Pando.
- Note consistency tradeoffs — per-branch causal consistency vs repo-wide snapshots.
- Track upstream Git — packfile-uri, parallel pack download/index, explicit haves.
- Do not claim Pando is open source — it is not; only “exploring sharing technology.”
- Watch forge roadmaps — agent-scale pushes/fetches are becoming a shared industry problem.
- Link agent-infra context without rewriting same-day ChatGPT/Anthropic posts.
FAQ: OpenAI Pando
Is Pando a new version control system that replaces Git?
No. OpenAI built Pando as a new backend for Git repositories while retaining compatibility with the Git protocol and client. Engineers and agents keep using Git workflows.
What production improvements does OpenAI claim?
Nearly 5× lower median push latency (~80% reduction), nearly a petabyte of Git data per day, more than 57 TB of packs in a single hour, over 99% cache hits, and the ability to saturate 10 Gbps links on standard VMs — figures from the Nov 2, 2026 engineering post.
How does Pando scale concurrent branch pushes?
It coordinates updates per branch (causal consistency) instead of imposing a single order on all repository ref updates. Unrelated branches can proceed in parallel; clients conflict when pushing to the same ref simultaneously.
Is Pando open source?
No. OpenAI is contributing Git client/protocol improvements upstream and maintains a public Git build and patch tracker, but Pando itself is not open-sourced. The company says it is exploring ways to share the technology with users.
When was Pando built and put into production?
OpenAI says Pando was built in Rust with Codex in about 10 weeks — one engineer for the core design, teams of agents implementing — and began serving production traffic in April 2026.
Is this the same story as ChatGPT’s Chat/Work merge or Anthropic message threads?
No. Chat/Work is a ChatGPT product/UI consolidation; Anthropic message threads are a Messages API latency optimization for long agent loops. Pando is OpenAI’s monorepo Git backend for agent-scale pushes and fetches.
Bottom line: OpenAI Pando is a Rust Git backend purpose-built for Codex-era monorepo parallelism — per-branch consistency, reusable packs, Express caches, and LSM-like L0–L4 compaction — delivering nearly 5× faster median pushes and petabyte-scale daily Git delivery while staying Git-compatible. Cite OpenAI’s Nov 2 post for the numbers; do not confuse it with today’s Chat/Work merge or Anthropic message threads.
Leave a Reply
You must be logged in to post a comment.