What happened
In an engineering article dated November 2, 2026, OpenAI’s Aaron Friel, Taylor Blau, and Ted Nyman describe building Pando, a new backend for Git repositories. The motivation was the growing size and demands of OpenAI’s monorepo as Codex enabled engineers to do more work in parallel. More concurrent work meant more branches and pushes, more merges, and more fetches and clones from development environments, research jobs, and CI. The article says the systems supporting the monorepo began struggling around the end of the prior year, with slow fetches and pushes, failed merges, and reliability at times below 90%.
OpenAI says Pando now powers all development in its monorepo. The backend was designed around two goals: horizontally scalable writes, particularly concurrent pushes to many branches, and high read throughput so clients can download data fast enough to saturate their available network bandwidth. It retains compatibility with the Git protocol and client, so engineers and agents could use it in existing workflows without interrupting engineering work or changing how the team uses Git. The article presents this compatibility as a deliberate choice to build on Git rather than replace the developer-facing workflow.
Pando’s write path coordinates updates to each branch independently. Updates to unrelated branches can proceed in parallel. The tradeoff is that a reader fetching several branches can see them at different points in time. For reads, Pando reuses packfiles—Git’s format for compressing multiple objects together—across fetches instead of generating an individual packfile for every client. A client may download some objects it already has, but the server can reuse the same bytes for many clients with comparatively little computation. OpenAI says this allows reads to be served from caches.
The article describes Git’s underlying objects and references to explain these choices: commits point to trees and parent commits; trees refer to files and subtrees; branches and tags are references to commits. Objects are immutable and identified by hashes, while a branch update changes a reference. In a fetch, the client requests commits and indicates what it already has; the server sends the remaining reachable objects in a packfile. A push transfers objects in the other direction and asks the server to update refs. This distinction between object storage and ref updates informs Pando’s approach to serving readers and coordinating writers.
In production, OpenAI reports that Pando cut median push latency by nearly 5x and delivers nearly a petabyte of Git data per day. A chart in the article says commits landed on master had grown 2,442% by Q3 2026 relative to Q1 2024, with a Q4 2026 estimate also shown. The supplied material does not state a public release, external access, price, or deployment instructions for Pando; it is described as the system now powering OpenAI’s own monorepo.
What the archive adds
A prior Telegram post described Cursor’s “Git at any scale” engineering discussion and its intersection with Walgit; that post framed repository operations as a growing concern for agentic coding. OpenAI’s account is a new company-specific implementation report, with operational figures and a description of its own backend. No directly related prior Field Note is listed.
Trend signal
This case weakly supports agent economics moves to completed work: OpenAI links Codex-enabled parallel work to increased repository load, and describes infrastructure changes made to sustain that work. The article does not measure cost per completed task or compare agent productivity, so it does not establish the pattern’s economic claim.
Why now
OpenAI attributes the pressure to the past year’s growth in monorepo size and to the pace and concurrency of development enabled by Codex. Its chart reports commits landed on master at 2,442% above the Q1 2024 baseline by Q3 2026. The article says the prior supporting systems had begun to struggle around the end of the previous year.
Why it matters
The case broadens the infrastructure question teams should ask when coding agents increase throughput: can source control absorb many independent writes and serve repeated reads without making the repository a new bottleneck? OpenAI’s design separates those demands. Independent branch updates target concurrent pushes; reusable packfiles target repeated fetches. That is a useful architectural lens for teams seeing more CI jobs, clones, and agent-created branches, even if Pando itself is not presented as an available product.
The report is also a reminder that Git compatibility can preserve familiar developer workflows while the backend changes substantially. For teams evaluating their own systems, the reported outcomes are prompts for measurement, not expected benchmarks: monitor push latency, fetch performance, reliability, and the volume and concurrency of repository operations as agent use grows.
Limits and uncertainty
These are figures and explanations supplied by OpenAI about its own monorepo. The article does not provide an independent evaluation, a detailed methodology for the reported latency comparison, absolute latency values, or a comparison against named alternative architectures. It does not establish that the same approach would improve other repositories, whose workload, history, hosting environment, and client behavior may differ. The supplied material does not state whether Pando will be released, whether it can be adopted outside OpenAI, or what it costs to build and operate. The commit-growth chart includes an estimate for Q4 2026, which should not be treated as an observed result.
Reader takeaway
OpenAI’s report connects agent-enabled parallel development with pressure on source control: more concurrent work creates more pushes, merges, and reads. Pando preserves Git’s client and protocol while changing backend write coordination and read reuse. The practical lesson is to measure repository performance as agent workloads grow, rather than assuming the model or coding harness is the only system that needs to scale.