Developer workflows
Pando at OpenAI: Git Scaling and an Agent Repository Checklist
OpenAI describes an internal Git-compatible backend built for concurrent agents. Here is what is established, what remains unavailable, and what smaller teams can apply today.
Pando is the Git repository backend described in OpenAI’s November 2, 2026 engineering article. The company says it serves its monorepo while preserving Git client and protocol compatibility. This is a source-control infrastructure story; the announcement does not offer a Pando model endpoint, public installation package or general customer signup.
For a team building an AI media application, the useful question is where parallel development creates waiting or conflicting work. You can investigate that with ordinary Git and a small integration rehearsal. The checklist below is our proposed workflow, not a reconstruction of Pando or a benchmark of SJolt.
What the engineering announcement establishes
OpenAI describes scaling writes with causal consistency and scaling reads by reusing packfiles. It reports an almost fivefold reduction in median push latency and nearly a petabyte of Git data served daily. These are company-reported results for its environment, not speedups that an unrelated repository should expect. The article says OpenAI is exploring ways to share the technology; contributions to Git and public availability of the entire backend are separate questions.
Start your own decision with a symptom. A slow clone, a queued test job, and a difficult merge can all delay a developer, but replacing the repository server will not necessarily fix the latter two. Give each symptom an owner and a measurement before choosing infrastructure.
November 4 follow-up: Pierre is a separate acquisition announcement
OpenAI announced that it will acquire Pierre, the company behind Code Storage and the Trees and Diffs libraries used in Codex. The announcement connects that work to Pando’s source-control direction, but states that closing remains subject to conditions including regulatory approvals. Until closing, the companies remain independent. It also says Pierre’s open-source projects will stay open-source and Code Storage customers can continue using the service after closing.
For an infrastructure decision, keep three questions separate: which repository backend you can use today, which review tools your team already uses, and what a future combined offering might provide. The announcement does not supply a public Pando migration contract. Do not replace a working remote on the assumption that Code Storage, Codex and Pando now have interchangeable APIs or account access.
Measure the path from a change to an accepted build
| Stage | Record | A useful diagnostic |
|---|---|---|
| Fetch or clone | Elapsed time and transferred bytes | Compare an empty checkout with a warm local copy |
| Push | Changed bytes, branch and elapsed time | Separate large assets from small code changes |
| CI queue | Wait before the job starts | Compare queue time with actual execution time |
| Integration | Conflicting files and review time | Check whether agents repeatedly edit the same contract |
| Delivery | Accepted commit and artifact | Confirm the tested code is the code being shipped |
Take observations over several ordinary changes before staging a load experiment. Include failed attempts and retries. Record the repository revision and client version so a later optimization has a comparable baseline. If a transfer stalls only on one network, investigate that path before attributing the problem to the backend.
For media projects, inventory generated files separately. A large video committed by mistake changes the transfer workload dramatically. Keep a manifest of owned assets and their intended storage location; use your project’s artifact storage for large outputs when that is its established design. Do not delete history merely because a new tool promises faster clones.
Give concurrent work an explicit integration boundary
Git worktrees let one repository support multiple working directories. Use a distinct branch and directory for each independent change, and reserve shared contract files for deliberate coordination. The Git documentation explains the shared repository data and per-worktree state; separate directories do not make two edits to the same API contract compatible.
Task: add an image status panel
Base commit: record the full commit ID
Owned files: status panel and its focused UI fixture
Shared contract: task status values and error shape
Integration owner: one reviewer
Acceptance: running, success and failure render correctly
Artifact: tested commit plus screenshotsBefore a task begins, write the smallest result the reviewer can accept. A second task might improve upload validation without touching the status panel. When both need a shared type, agree on the change first and have one branch introduce it. This reduces ambiguity about which version each task was tested against.
When integrating, inspect each diff and run the combined checks. Two individually valid branches may fail together because an import changed or an error field was renamed. Record the integrated commit, not only the branch names, beside the validation result.
Rehearse recovery before moving repository infrastructure
Git bundles can package objects and references for offline transfer. A bundle is useful for a recovery exercise, but it does not include uncommitted files, issue discussions, hosted checks or your deployment configuration. Inventory those separately before calling any export a complete backup.
In a disposable repository, restore a selected bundle into a new directory and run a small build from the recorded commit. Confirm the expected branches and tags, then compare a representative file hash. Keep this exercise separate from a production remote migration. A successful local restore tests object recovery; it does not prove permissions, hooks or CI integrations will survive a hosting change.
Choose a rollback trigger in advance: missing refs, a changed authorization result, or an integration that cannot fetch its pinned revision. Make the person responsible for reversing the migration explicit. These criteria turn a successful demonstration into an operational decision.
Apply the checklist to one SJolt-backed application
An application using SJolt’s documented media task API is a suitable small fixture. Put the request builder, task-status display and acceptance checks in your own repository. Keep credentials outside version control and use saved synthetic responses while developing the UI. The media API is the dependency being integrated; it is unrelated to Pando’s repository service.
For one test, preserve the same request shape while exercising running, success and failure states. Verify that an accepted task is not presented as a finished image, and that a failed task does not leave a permanent spinner. Review the generated asset separately from the code that displays it. A correct frontend cannot guarantee that a creative output meets the brief.
The outcome to aim for is a traceable change: one commit, one checked contract, one reviewable artifact and a known recovery path. Adopt a different Git backend only when your measurements show that repository serving is the limiting step. No Pando deployment or throughput test was performed for this article.
Sources & further reading
Take the next idea into production.
Explore the models, test a workflow in the playground, and use the same request in your application.