Why OpenAI rebuilt the machinery behind Git

Coding agents can turn one developer’s work into many simultaneous repository operations. The pressure does not stop at model inference: branches must accept updates, evaluation workers must obtain the right history and temporary workspaces must become usable. Source control is part of the agent system’s capacity plan.

OpenAI’s 2 November engineering account introduces Pando, an internal Git backend built to support that change while keeping the existing client and protocol. The company reports improved production push latency. Its account is evidence about its own infrastructure and workload, not a benchmark proving that every team needs a replacement server. OpenAI’s engineering post is the primary release source.

The more durable lesson is about the work behind a familiar command. “Push” sounds like moving some files. In a busy service, it involves agreeing on reference changes while ensuring the associated history is available. “Clone” sounds like downloading a directory. It can entail graph traversal, compression, transfer, indexing and checkout. Coding-agent concurrency puts different pressure on each part.

The unit of demand is a completed work cycle

Consider a hypothetical team asking several coding agents to investigate independent bugs. Each agent starts from the same base revision, creates a branch, makes a change and submits it for evaluation. The model calls are different, but the source-control inputs overlap heavily. If every evaluation starts a fresh environment, the same unchanged history may be requested repeatedly.

The write side is different. Those branches contain distinct changes and must update their own references safely. Treating all repository activity as one undifferentiated traffic count hides that distinction. More readers may benefit from shared cached bytes. More writers may need finer coordination. Buying a larger disk does not automatically solve either problem if the bottleneck lies elsewhere.

This is a proposed workload example, not an account of OpenAI’s exact development process. It illustrates why the infrastructure question should start with the agent work cycle. How many environments are created for one accepted change? How often do they reuse a base? How many pushes trigger builds? How many abandoned branches still incur transfer and storage work?

Our explanation of an agent harness describes the software around a model. Source control belongs in that surrounding system when the agent edits repositories. The harness decides when to create workspaces, what revision to check out, whether retries reuse prior state and which event triggers evaluation. Those choices can amplify or suppress infrastructure demand without changing the underlying model.

A team can therefore improve apparent agent performance by removing avoidable waiting rather than by buying a more capable model. The reverse is also possible: a strong model may spend much of its allotted session waiting for a checkout. End-to-end measurement should expose the wait instead of attributing every slow task to reasoning or token generation.

The relevant denominator is accepted work. A system that doubles repository operations while producing the same number of reviewed, useful changes has increased activity without demonstrating value. This is why the infrastructure story belongs alongside our analysis of an AI product’s full cost. Compute is only one line in a workflow with many dependencies.

Git separates history from the names that point to it

Git’s object model allows an important separation. History consists of objects, while branches and tags provide references to objects. Changing the content of a file creates new history; moving a branch changes a name’s target. A service must handle both the data and the reference update, but they do not have identical coordination needs.

The pack transfer protocol describes distinct fetch and push exchanges. Clients and servers negotiate what is already available and what must be transferred. That negotiation helps avoid unnecessary data movement. It also means a repository operation has more phases than copying an archive from one machine to another.

The git-update-ref documentation gives a concrete example of safe reference movement: an update can require the current value to match an expected old object identifier. That condition protects against silently overwriting a competing update. At scale, the service must decide where such checks happen and which otherwise independent operations have to wait for one another.

Imagine two agents both advancing the same branch from the same starting point. They have a real conflict at the reference even if their file edits happen to be compatible. Someone must decide which new tip becomes visible and how the other change is reconciled. Now imagine those agents writing to different branches. Forcing their reference changes through one queue may impose waiting that their logical work does not require.

That distinction is a general systems observation. Fine-grained coordination can improve concurrency when operations are independent, but it requires clear semantics for readers. A consumer reading several names must know whether it receives one coherent snapshot of the entire set or separately valid observations made at different moments. Both can be useful; neither should be implied accidentally.

This matters especially for release automation. A release job may combine a branch, a tag and configuration stored elsewhere. If its correctness depends on a particular relationship among them, the job should record explicit revisions and validate that relationship. “I read the latest value” is weaker than “I built this exact approved combination”. The latter remains a sensible discipline regardless of the hosting implementation.

A reference is not the same as a release identity

For a human browsing a repository, a branch name is a convenient moving target. For a reproducible evaluation, that same convenience becomes a risk if the worker resolves the name at an unspecified time. A test report should record the commit actually checked out, rather than merely saying that it tested the development branch.

Suppose an agent submits a change, then immediately pushes a correction. A queued worker may obtain the earlier revision while a reviewer sees the later one. Nothing necessarily failed in Git. The ambiguity lies in associating a passing status with the wrong change. Explicit revision identifiers make that dispute visible and prevent a green badge from acquiring broader meaning than its underlying test.

A well-designed agent service therefore treats task identity, workspace identity and revision identity as related but distinct. A task can have several attempts; an attempt can involve several commits; a workspace can outlive either. Recording those relationships provides a useful audit trail without forcing every operation into one global transaction.

Reusable bytes change the economics of repeated reads

A packfile stores Git objects compactly. The git-pack-objects manual explains that an object can be stored as a compressed whole or as a delta from another object. Packing makes transfer and storage efficient, but creating a specialised pack still consumes work. The best response for one reader is not necessarily the cheapest response for a crowded service.

Consider a hypothetical evaluation fleet in which many workers need almost the same history. A perfectly tailored response could omit every object each worker already possesses. A reusable response could include some redundant data but avoid repeated server-side preparation. The trade is between bytes sent and work performed to decide and encode exactly which bytes to send.

This is not unique to Git. Static assets, container layers and package distributions also reward reuse when many consumers need the same immutable material. The useful question is whether the system’s actual cost lies in network capacity, preparation CPU, storage reads or request coordination. A smaller response is attractive only in relation to the resources needed to produce it.

OpenAI’s account identifies reusable packfiles and branch-level coordination as central Pando choices, accepting weaker repository-wide snapshot semantics. That is the architecture’s key trade, rather than a claim that ordinary Git clients stopped working. Teams considering the lesson should examine whether their own consumers can tolerate the same semantic choice before admiring the throughput implications.

The request path can be described without assuming the implementation details of another company’s system. A writer supplies new objects and requests a reference change. A service makes the objects retrievable and publishes the permitted change. A reader resolves a revision and obtains the required history. The reader then turns that history into a usable environment. Each stage has a separate opportunity for caching or waiting.

This is an analytical comparison, not a performance table. No timings have been supplied for the hypothetical platform. Its purpose is to keep an operator from measuring one stage and declaring the entire work cycle solved.

Smaller checkouts are several different optimisations

A slow clone is a symptom, not a diagnosis. The git-clone documentation describes options including depth limits, branch selection and object filtering. Those options change what the client initially obtains. They do not all produce equivalent repositories, and later operations can need material omitted at the start.

A shallow history may be enough for a narrow build but unsuitable for a task investigating when a regression appeared. A worker that initially avoids certain objects may fetch them later when a tool opens additional paths. Initial transfer time can improve while total task time barely changes. The evaluation should follow the actual job rather than stop the clock at the first successful command.

Sparse checkout addresses another boundary. The official manual describes selecting a subset of tracked files for the working tree. It is not simply another name for an object-transfer filter. A platform can reduce the files materialised in a workspace while still having substantial history available locally. Conversely, it can reduce initial object transfer and later materialise a broad tree through additional requests.

For a coding agent, that choice affects context as well as setup time. Restricting the working tree to one service can reduce irrelevant files, but a task may require shared types, build definitions or integration tests elsewhere. An apparently efficient workspace that hides a relevant dependency can encourage an incorrect change. Workspace configuration therefore deserves the same care as the prompt and tool permissions.

A practical platform should distinguish task-specific optimisation from universal defaults. A documentation edit, a dependency upgrade and a cross-service refactor need different repository views. The controller can choose an initial scope and expand it when justified, while recording what the worker actually saw. This is an editorial design suggestion, not a documented feature of Pando.

The decision can be made through a small, representative task set. Measure initial preparation, later network requests, test success and completed review. Include tasks that deliberately cross the proposed boundary. If the optimisation helps only the easiest examples, it may be reducing visibility rather than removing overhead. The appropriate outcome could be a differentiated configuration rather than one setting applied to every agent.

A warm workspace can save work and carry state

Reusing an environment introduces a separate trade. A warm workspace may already contain the base revision and installed dependencies. It may also contain untracked files, generated artefacts or local configuration left by another task. Faster preparation does not excuse uncertainty about the state in which a model edits and tests code.

The platform needs an explicit reset contract. That could mean a fresh worktree, a recreated container or a verified clean environment, depending on the system. The important property is that the test result can be connected to known inputs. An incidental cache hit should not decide which dependency version a task sees.

A useful comparison includes both clean and warm starts. Report what the warm state contains and what preparation is still performed. Otherwise, teams can accidentally compare an entirely new environment with a heavily prepared one and attribute the whole difference to their source-control service. That would be a benchmark of different starting conditions, not solely of a backend.

Maintenance is capacity work rather than housekeeping

A repository accumulates objects and indexes as it changes. The git-maintenance manual makes a deliberate distinction between responsive foreground commands and optimisation tasks that may scale with repository size. Scheduling those tasks can improve later operations without forcing every individual update to pay the full cost immediately.

That distinction is especially relevant when agent work creates many short-lived branches. The operational concern is not that branching is inherently bad. It is that abandoned work, long retention periods and repeated packing can change the shape of the repository over time. Capacity planning needs a policy for what is kept, why it is kept and how its storage is maintained.

Indexes are another part of the story. The multi-pack-index documentation describes commands to write, verify and manage indexes across packs. Such facilities illustrate that “the objects are on disk” is only one condition for efficient access. The service still needs a practical way to find and serve them.

The correct maintenance policy depends on workload and hosting responsibilities. A customer of a managed service may not control the server’s storage layout at all. They can still inspect local environment preparation, excessive fresh clones and unnecessary downloads. A self-hosted operator has more options and more obligations, including ensuring that background optimisation does not create unacceptable foreground interference.

For the hypothetical agent fleet, retention should follow the value of the work. Accepted changes need durable provenance. Failed experiments may need temporary retention for debugging. Secrets accidentally committed require a separate incident process; ordinary deletion of a branch is not a complete response. These are governance decisions around the repository, not reasons to make a model responsible for storage policy.

The team should also measure recovery. A fast service that is difficult to restore can make a rare outage disproportionately expensive. Backups, reference reconstruction and client behaviour after interruption belong in the acceptance plan. No production improvement figure from another organisation establishes that a particular recovery procedure works in the customer’s environment.

A small workload model exposes amplification

Take an explicitly hypothetical service that starts ten coding tasks from one base revision. Suppose each task pushes twice and each push starts three isolated evaluation workers. That creates sixty worker starts from twenty pushes, before accounting for retries. The arithmetic is a planning example, not a measurement of OpenAI, Git or any model’s productivity. Its value is to show which multipliers the operator controls.

Now suppose the second push arrives before the first evaluation finishes. If the earlier jobs continue, both rounds consume repository and build resources. If the platform cancels the earlier jobs, cancellation still needs to arrive soon enough to save work. If it reuses a prepared environment, it must ensure that the second evaluation really sees the second revision. Each choice changes the request pattern reaching source control.

An operator could reduce the hypothetical sixty starts without touching the Git service by combining checks or cancelling superseded work. That does not prove such an intervention is desirable for every task. Some checks need isolation, and some intermediate revisions matter for debugging. The point is that demand has a policy origin. Counting commands without recording the trigger misses an opportunity to control that demand.

The model can also distinguish data reuse from workspace reuse. Several workers might share cached immutable history while keeping separate writable directories. That preserves task isolation at one boundary while allowing reuse at another. Whether a particular platform supports this safely must be checked against its implementation; the conceptual distinction prevents a false choice between complete duplication and one shared mutable workspace.

For planning purposes, record a few ratios alongside the raw request count: worker starts per pushed revision, transferred bytes per completed evaluation and evaluations per accepted change. The ratios reveal different problems. Many starts per revision suggests orchestration amplification. Many bytes per evaluation suggests poor reuse or a genuinely broad task. Many evaluations per accepted change may reflect useful search, weak task selection or review friction, which requires qualitative investigation.

A capacity estimate should keep uncertainty visible. Early adoption may create bursts that a weekly average conceals. A demonstration using one warm environment may tell little about a morning when many employees start new sessions. Use both ordinary load and a plausible simultaneous-start scenario when assessing whether a bottleneck will matter to users.

Finally, connect any savings to the resulting work. Reducing repeated transfer while keeping identical test coverage is a cleaner efficiency result than reducing transfer by skipping a necessary evaluation. Both can lower a bill, but they change the product in different ways. A team should be able to say which one it achieved before presenting the saving as an agent productivity improvement.

Keep compatibility claims separate from application assumptions

Git protocol compatibility is valuable because clients, editors, CI tools and developer habits form a large surrounding ecosystem. Replacing a backend while preserving that interface can reduce migration costs. But compatibility at the protocol boundary does not mean every application assumption about timing, ordering or consistency is automatically preserved.

The protocol version 2 specification describes command-oriented communication and explicit capabilities. That specification is about how peers communicate. A distributed service must additionally decide how accepted writes become visible across its internal components. Readers should not mistake a wire-protocol document for a complete consistency contract for every possible backend.

An integration review can start by listing the assumptions made by existing automation. Does a job resolve several references and expect them to represent one instant? Does a successful push trigger a reader immediately? Does a merge service rely on a particular rejection condition? Does a release tool re-resolve a branch instead of using the exact commit supplied by its trigger?

These questions are useful even without a migration. They can reveal accidental coupling between independent systems. A webhook, a queue, a build worker and a code-review interface may each observe events at a different time. Explicit identifiers and idempotent processing make those differences easier to manage than a vague expectation that everything will be “up to date”.

A hypothetical migration test should include concurrency deliberately. Have independent writers update unrelated branches while readers request known revisions. Also test competing writes to the same reference and a reader starting immediately after acceptance. The purpose is not to infer the implementation from a few examples. It is to verify that the surrounding workflow behaves according to its documented expectations.

Recovery and retries need equivalent attention. If a client loses the connection before learning whether a push succeeded, it should resolve the actual state before repeating a side effect that assumes failure. Agent automation can turn a small ambiguity into repeated work quickly. The controller’s retry policy is part of the system being evaluated, not an incidental implementation detail.

Measure the handoff from accepted push to useful evaluation

A useful source-control dashboard has more than a median push time. It should expose when the pushed revision becomes fetchable by the worker that needs it. It should then show when checkout finishes, dependencies are ready and the first relevant evaluation begins. Otherwise, a bottleneck can move from one stage to another while the headline metric improves.

The proposed measurement unit is one identified revision moving through the work cycle. Associate client submission, server acknowledgement, downstream fetch and evaluation records with that revision. Use separate identifiers for retries. This lets an operator distinguish a slow successful path from repeated failed attempts that eventually produce the same result.

Tail behaviour matters because work often fans out. If one change triggers several evaluation jobs, the slowest necessary job can determine the user’s wait. Averages across unrelated operations obscure that dependency. The platform should ask which operation lies on the critical path for an accepted change, then investigate why that operation waits.

Cost accounting should include rejected and abandoned work. A system may serve enormous amounts of history to agents that never produce an accepted patch. That traffic can still be a worthwhile research cost, but it must be counted. Reporting only the successful tasks makes both efficiency and capacity appear better than the actual bill suggests.

The evaluation must also preserve task quality. A faster workspace that omits important files or uses stale dependencies could increase the number of apparently successful edits while reducing review acceptance. Our comparison of coding-agent workflows discusses the wider environment around a coding model. Infrastructure metrics should connect to those workflow outcomes rather than become a separate competition.

A sensible first intervention is therefore diagnostic. Identify whether the dominant wait is coordination, preparation, transfer, checkout or subsequent build setup. Change the narrowest responsible component. Then repeat the same representative tasks under the same starting conditions and report both infrastructure and completed-work outcomes.

The decision to rebuild needs its own evidence

An internal backend can be rational at one organisation’s scale and an expensive distraction elsewhere. The cost includes design, migration, monitoring, recovery and continued compatibility work. A team considering a replacement should compare that continuing obligation with the recurring cost of the measured bottleneck. The decision is an engineering investment, rather than a reward for having sophisticated agents.

An especially useful counterfactual is to remove avoidable demand first. Can evaluation workers share a prepared base safely? Can unnecessary duplicate jobs be eliminated? Can a narrow task begin with an appropriate repository scope? Can the controller wait for a meaningful checkpoint before pushing another speculative edit? The answers may change the required server capacity substantially.

If those improvements leave a hard coordination limit, the team has a stronger case for architectural work. It can state the limiting operation, the workload that exposes it and the semantics that must survive the change. That specification is more actionable than “make Git scale for AI”, and it creates a fair basis for comparing a managed offering with a custom design.

Pando’s significance is that source control has become visible as part of AI development infrastructure. The practical response is to make the entire handoff visible in your own system: a model’s edit, a safely published revision, a prepared environment and a completed evaluation. Optimise the part that makes accepted work wait.