Why OpenAI kept Git for its agents and Anthropic replaced it

On November 2, OpenAI described Pando, the repository backend now running its monorepo. Engineers and agents kept using Git. Three weeks earlier, Anthropic described migrating its monorepo to Scion, a custom version-control system with much more work performed on the server.

Pando and Scion address repository traffic. Cursor Origin offers a new Git host. Entire adds review context to its native Git hosting and to GitHub mirrors. Delta adds it alongside an existing host, such as GitHub.

A different forge is one option. Smaller clones and separate working directories can address task setup and interference, while tools such as Delta add review context alongside an existing host. The final section shows how to tell which of these problems you have.

What changes when agents use source control?

An agent's task can be small while its repository overhead is large. It needs files, may inspect history, makes changes and triggers validation. Repeating that process in fresh environments makes the cost of acquiring repository data part of every task.

GitHub's account of its infrastructure rebuild, published October 6 and updated October 26, describes several pressures. Agents repeatedly checkpoint their work, creating sustained writes across branches. Changes then converge on the branch where they must be merged. Each write also generates reads as CI and code-scanning jobs acquire the new state.

Serving more readers can make writes harder in the architecture GitHub describes. Its existing system keeps full repository copies on several fileservers. Those copies provide durability and read capacity, but participate in coordinating writes. Adding replicas to serve more reads adds coordination to the write path.

Checkout time is one cost to measure alongside push latency, validation and merge queues. Two agent tasks editing the same checkout also risk overwriting each other's work. A reviewer receiving a diff without the original requirements faces a separate handoff problem.

Which parts of source control are being rebuilt?

Git's client, its network protocol and a hosting service's storage backend can evolve separately. A forge adds collaboration around the repository, including reviews, checks and permissions. Keeping Git commands working leaves considerable room to change how the server stores and serves data.

Conceptual paths, not a combined deployment. A product can change more than one part of the workflow.

Pando keeps Git commands working while rebuilding the server for concurrent branch pushes and high read throughput. OpenAI retained Git's client and protocol to preserve existing workflows and contribute improvements upstream. Updates to an individual branch are serialized, but a client reading several branches cannot assume they all describe one point in time. Automation coordinating changes across branches needs to account for that behavior.

By default, Pando advertises only trunk as the base for a new feature-branch push. Repeated or stacked branch pushes therefore resend objects outside trunk, trading extra client bandwidth for reusable packs.

OpenAI reports that reliability sometimes fell below 90% on its previous infrastructure. Pando reduced median push latency nearly 80%. The project reached production ten weeks after kickoff, and migration meant adapting hundreds of integrations. OpenAI also shipped its own Git build and used a CLI wrapper during the move. OpenAI's November post describes an internal deployment and exploratory plans to share the technology.

Anthropic reports about 2,500 daily merges in May and over 30,000 by September, alongside roughly 25 million CI checkouts a day. Nearly all its clients were always-online agents and jobs, so it designed Scion around on-demand access to a reachable server. Its several hundred Git mirrors had become difficult to operate as the merge rate grew.

Scion moves commits, rebases and merges onto the server. Jobs query history and diffs through APIs. Sparse checkouts contain requested directories; virtualized checkouts materialize files on demand. Anthropic reports a 200-fold reduction in CPU and memory requirements compared with its previous Git-mirroring setup, plus a 25% CI CPU capacity win. It says CI and research checkouts fell from minutes to seconds.

Anthropic explicitly says Scion is unsuitable as a general-purpose Git replacement. Migration requires changing code review, search and CI. A seven-person team built Scion and its companion systems and completed the migration within five months. The post credits Google's Piper and Meta's Sapling as prior art. Its proposed path for other organizations is to bring server-side RPCs and better sparse/shallow behavior into Git platforms. Anthropic forecasts that similar pressures will spread over six to twelve months.

Cursor offers a publicly accessible hosting product with a different adoption path. Origin began rolling out in early beta on August 17, and its current documentation retains that beta label. A team can host a repository on Origin or mirror one from GitHub. In the mirrored setup, GitHub remains the source of truth.

Origin runs on Cursor's Continuity storage system, which records pushes in a write-ahead log stored in S3-compatible object storage. The durable log allows local Git repository copies to act as recoverable caches. Cursor can recreate a missing local copy from that record, reducing its dependence on a particular fileserver's repository copy. Standard Git clients continue to connect to the service.

Hosting also requires the surrounding development workflow. Cursor's October 13 marketplace update listed over 20 apps across deployments, CI, code review, security, monitoring and project management, and opened public submissions. Confirm that required checks, permissions and webhooks work before moving a repository.

Established platforms are making related changes. GitHub's October 21 follow-up describes moving copies of repositories to Azure, narrowing write coordination to individual references and separating reads through object storage. The architecture transition is ongoing. GitLab's next-gen SCM remains in private beta, combining Git compatibility with redesigned storage and agent-facing interfaces. Its proposed architecture includes S3-compatible storage that customers control, including in air-gapped data centers.

What should be preserved beyond the diff?

A diff shows the resulting code changes. Reviewing an agent's work can also require the original request, constraints discovered along the way and evidence behind a design choice. Reconstructing that context in a new session creates another task for the reviewer.

Entire and Delta approach that problem differently. Entire's October 26 forge announcement combines Git-compatible hosting with Trails, a review workflow where agents return findings, scores and explanations on code pushes. Repository gates can enforce human approvals and passing CI checks as well as rules for agent findings. Trails also work on GitHub pull requests through repository mirroring.

Entire's Continuous Memory connects recorded sessions with a code graph, letting agents retrieve past decisions for later tasks and exposing that context during review. Validate a recorded decision against the code and tests before reusing it.

Entire's October 30 regional update lists Brazil alongside the US, EU, UK, India, Australia and Singapore. Those locations can host native repositories or regional GitHub mirrors. A mirror serves clones and fetches from Entire, while normal pushes still return to GitHub; native hosting also moves that write path to Entire.

Delta entered public beta on September 16. Built by Zed Industries, it lets collaborators join a thread containing agent conversations and unfinished code changes. Review can happen within that shared context, with a reviewer exploring a separate copy of the work before incorporating fixes.

DeltaDB, its underlying versioning system, retains edits between Git commits alongside the conversation. A commit remains a checkpoint that can be pushed, pulled and built. The additional history lets collaboration proceed while work is still in progress. Existing GitHub workflows can remain in use alongside Delta threads.

An October 27 beta integration extends that approach to Claude Code. A teammate can join a shared conversation and worktree from their own Claude Code session. With Delta's plugin installed, run /delta share in a Git checkout with a remote and choose the people allowed to see it. If several remotes exist, one must be named origin. A teammate with the plugin joins using /delta join <shared-link>.

The beta plugin requires Claude Code 2.1.303 or newer and Delta 0.22.0 or newer. Claude Code cloud sessions, print mode and SDK sessions are unsupported.

Sharing includes messages and Claude's thinking, tool calls with their inputs and outputs, images, and staged, unstaged and untracked checkout files. Git-ignored files and local Git branches are excluded. Check untracked files and tool output for secrets before choosing recipients. Joined checkouts are temporary: on exit, Delta uploads changes and deletes those checkouts, including ignored files and local branches.

Delta's October 29 architecture account describes a graph of edits and conversation state built with conflict-free replicated data types. Parallel timelines can be synchronized and merged without first making Git commits. The deployment uses one Cloudflare Durable Object per thread, with multi-tenant and single-tenant options. CRDT convergence concerns synchronized edits; test the merged result for behavioral conflicts.

The five systems therefore change different parts of development:

Availability checked November 5, 2026. Origin's current docs exclude Free and Plus plans, prohibit namespace renaming during beta, and require teams to leave legacy privacy mode before enabling Origin. Delta's current pricing lists Personal at $0 with your own API keys or external agents, and Pro at $10/month with $5 of tokens included each month plus usage billing beyond that.

Do the benchmarks tell us which is faster?

Entire's October announcement reports 418 pushes/second for Entire, 65 for Cursor and 4.7 for GitHub. Its hosting page attributes these figures to ForgeMark, Entire's open-source tool for benchmarking Git hosting services. ForgeMark sends concurrent pushes and clones to a host and records throughput and latency.

It supports branch-push, clone and mixed-session workloads. Its default push references use refs/forgemark/, avoiding the usual branch-triggered CI, search and webhook work. Entire's post doesn't state which settings produced its chart.

ForgeMark warns that GitHub.com applies secondary rate limits to high-volume writes and recommends low concurrency. For higher-volume comparisons, its README recommends a GitHub Enterprise Server you control. A result against GitHub.com can reflect those limits; the chart does not say whether throttling occurred. Entire mirror mode also routes writes through GitHub, so testing a mirror measures that sync path rather than Entire's native hosting alone.

The Cursor figure is 65 pushes/second in Entire's test. Cursor's own post reports sustaining up to 120 pushes/second on S3 Standard while compacting and replicating, and more than 300 on S3 Express One Zone, where Git compaction limits throughput. Request the workload, concurrency, repository size, region and rate-limit settings behind any proposed advantage, then measure review and CI time alongside push throughput.

Does your source-control setup need to change?

If repository operations are reliable, task setup is fast and reviewers have the context they need, keep the current system. OpenAI and Anthropic rebuilt after their workloads strained their infrastructure.

Where problems do appear, trace a representative task through acquiring the repository, running the implementation, executing checks, waiting for review and landing the change. Repeat that measurement with the concurrency the team expects to operate.

If repository acquisition dominates, partial clones defer downloading file contents, while sparse checkout restricts the working tree. For a repository with a services/billing directory:

git clone --filter=blob:none --sparse <repository-url> agent-repo
cd agent-repo
git sparse-checkout set services/billing

Replace the URL and directory with the actual repository and required paths. The server must support filtering. A separate choice, git clone --depth=1 <repository-url>, truncates history; history-dependent tools may need a deeper fetch. Include build configuration and shared dependencies when selecting sparse paths.

If tasks interfere in a shared checkout, Git worktrees can give each task its own branch and working directory:

git worktree add -b agent/billing ../billing-task

Worktrees share repository data. Credentials, processes and external services need separate isolation controls. Our coding-harness explainer distinguishes tool-policy checks from sandbox isolation.

If pushes or merges are the bottleneck, test the host under your own load. Record concurrent writers, p50 and p95 push latency, failed operations and recovery time on the same repository. Use observed task delays and failures to set the acceptance criteria for that test.

If missing task context slows review, preserve the original task and decisions for a bounded set of changes, then measure whether reviewers find the relevant evidence faster and whether defects still escape. Include unsuccessful approaches when they explain why the final implementation took its current form. Compare review time and escaped defects against similar changes using the current workflow.

Before approving a hosting migration, weigh the measured gain against the work of moving review discussions, CI configuration, permissions and agent conversations. Have another person continue a representative task using exported code and context to check what survives the move.

Anthropic's October post says it does not expect many organizations to face its source-control pressures in the very near term. It proposes bringing Scion's server-side ideas into Git platforms. OpenAI's Pando shows how the backend can change while keeping Git's interface. Ask your existing forge what it can deliver before replacing the version-control model.