Git Was Built for 2,500 Merges a Day

In May 2026, Anthropic merged about 2,500 code changes into main every day. By September it was more than 30,000 a day.[1] That is a 12x jump in four months, and almost none of those changes were typed by a person. Claude wrote them.

Git did not break at that number. The thing that broke was the assumption underneath Git, and underneath almost every storage and collaboration tool of the last twenty years. The assumption is that writes arrive at human speed, from one author at a time, and that the author is sometimes offline. Agents write at machine speed, in parallel, and they are never offline.

Between September 16 and October 15, 2026, every major lab hit that wall in public. Anthropic, Perplexity, OpenAI, Google, and Microsoft each shipped, or described, the same primitive: a versioned workspace where humans and agents write to the same state, with a server deciding who wins. Nobody coordinated this. They all arrived at the same answer because the problem only has one shape.

This post walks through what each of them built, what it has in common, and what is still open. I will keep the jargon light. If a sentence needs a glossary, I did not write it well enough.

Four weeks, one primitive

Here is the window, day by day. Blue is a workspace people use. Red is the write path underneath it, the part that decides what happens when two writers collide.

Two things stand out. First, the user-facing launches came early in the window and the infrastructure accounts came late. The products shipped first, and then the teams explained what they had to build to make them work. Second, the two most detailed accounts, Anthropic’s and Perplexity’s, describe nearly the same system, and neither one mentions the other.

What human-speed tooling assumed

Every tool we use to hold work in progress carries an assumption about how writes arrive. Agents break each one.

POSIX files assume one writer at a time. The filesystem has no idea which of two processes should win. Last write wins, silently. That was fine when the two processes were you and your editor. It is not fine when ten agents share a directory.

Git assumes a rich client and a dumb server. In Anthropic’s words, Git assumes clients work offline and need a complete copy of the repository, and every client is capable of being a full server.[1] The server just stores objects. The client does the thinking: it holds the full history, resolves merges, and decides when to push. That design was a gift to humans on laptops and on planes. For an agent in a sandbox that will exist for ninety seconds, cloning a full repository is most of the work.

Sync drives assume conflicts are rare. Dropbox and Drive handle two edits to one file by making a “conflicted copy” and letting a human sort it out. That works when a conflict happens once a month. Agents will produce one every few seconds.

Cloud docs assume every writer is a person. Google Docs and Notion arbitrate at the keystroke. That is the right model when the writers are humans typing. An agent does not type. It produces a finished chunk and wants to land it as one unit, and it wants to know whether it landed.

RAG over documents assumes the corpus is read-only. Retrieval pipelines chunk and embed a snapshot. They do not have a story for an agent that reads a file, changes it, and needs the next agent to see the change. I wrote about why this pushes agents back toward the filesystem in The Filesystem Is the Database.[24]

The common thread is simple. All of these tools were built when writes were slow, sparse, and human. The hard part was storing the bytes. The hard part now is deciding, quickly and correctly, which of many simultaneous writes wins.

Anthropic: 2,500 to 30,000

Anthropic’s number is the one that makes the whole argument.

What they built is called Scion, and the engineering post is unusually candid about why.[1] A seven-person team built Scion and a companion system called Antique and migrated the company in five months. The design inverts Git’s client model. There is one authoritative server. Clients are thin and always connected. Changesets are created server-side and are available everywhere instantly. Moving a shared ref, like main, is a compare-and-swap on a single Cloud Spanner row, done separately from creating the changeset. Reads go through three tiers, a local daemon, a cache, and the authoritative server, and each tier keeps a cache hit rate above 99 percent.

The resource numbers are large. The Scion footprint is 200x smaller than the old Git mirroring infrastructure in CPU and memory. CI alone got a 25 percent CPU capacity win.[1]

Two design choices matter more than the numbers. Anthropic did not build a merge queue. The post says a proper merge queue does not make much sense at agent scale, and that they invested in post-merge and pre-deploy testing instead. When changes conflict, Claude fixes the conflict, and the post says it typically does so faster than humans can even identify it. And humans still review every change. What changed is what they review. Reviewers now examine the intent of the change rather than reading every line. The system can apply permissions to individual directories to protect the most sensitive code.[1]

One more line is worth quoting because it sets the boundary for everything below. Anthropic says Scion is by no means a suitable replacement for Git for general use.[1] This is not a product. It is a company telling you what it had to do at 30,000 merges a day.

Perplexity: the same shape, from the other direction

Perplexity’s post came out the day before Anthropic’s, and it describes the write path under its Projects product.[2] Projects itself launched on July 30, when Spaces were renamed and given a persistent, hierarchical file system that humans and agents share, plus a memory system called Brain.[5]

The engineering is this. Each project is a bare Git repository on a shared filesystem, AWS S3 Files, split into cells with their own Git service replicas. Agents do not touch the repository directly. Each agent gets a short-lived sandbox on SPACE, Perplexity’s in-house sandbox platform, with a local checkout. When the agent is done, it submits. The Git service accepts the submit only if it was built on the current head. Otherwise it returns a structured stale-base response, and the agent replays its change on the new head and resubmits.[2]

The published numbers: fewer than 2 percent of submits are rejected as stale, median submit latency is under 1.7 seconds, and p99 is under 8 seconds. Attaching an agent to a warm checkout takes about 2.9 seconds, versus roughly 8 seconds for a cold start.[2]

Read those two paragraphs next to Anthropic’s and the overlap is almost total. An authoritative server. A thin, sandboxed client. A single decision point at the head. Reject and replay instead of a lock. Perplexity did it for research documents and spreadsheets. Anthropic did it for a monorepo. The storage differs. The arbitration is the same.

Here is the inversion as a picture.

Three days after the workspace post, Perplexity open-sourced SPACE itself under Apache 2.0.[3][4] It is written in Rust and runs each sandbox in a Firecracker microVM. Sandboxes get frequent file snapshots and checkpoints of the full running environment, and you can branch a sandbox. Perplexity reports no escape from the VM to the host in 108 attempts by testers, and sandbox creation three to five times faster than its previous provider on the same production traffic.[3]

OpenAI, Google, Microsoft, Cursor

The other launches in the window were products, not engineering posts, so there is less to quote. But the shape is the same.

OpenAI used DevDay on September 29 to launch Dots, always-on agents that each get their own cloud computer and browser, and two shared surfaces: ChatGPT Space, where teammates and their dots work together, and Pages, a new kind of document built for humans and agents to collaborate on writing, charts and images.[6][7] A human can jump into a Page an agent is writing, edit it, leave feedback, and send the agent back to work.[7] OpenAI did not describe a version history or an arbitration rule for Pages, at least not in the keynote coverage I could find.

Anthropic, on the product side, folded Cowork into Claude on September 16 and launched Claude Docs and Slides in beta. Claude creates a document or deck that the user and their colleagues can edit directly, and each project gets one shareable link.[8] The next day it rebuilt Projects around a coordinator that routes work to threads, where each thread is a Claude Code cloud session working on its own branch and copy of the repo, and overlapping edits are resolved as a merge conflict like any other pull request.[9] That is branch-per-agent-then-merge, in product form.

Google announced coworker agents at Gemini at Work on October 8. Each agent gets its own Workspace account, including an email address, calendar, Drive, and a presence in the company directory. It acts under its own identity, not yours, and sees only what you share with it.[10] Google’s approach to the write path is to reuse the one it already has: the agent is a user, and Drive and Docs already arbitrate among users. On the developer side, the Antigravity agent runs in a hosted Linux sandbox where files persist across interactions, so a scheduled run picks up the files the previous run left.[11]

Microsoft is a little outside the window, but it belongs in the picture. Scout, announced June 2 as the first of a category Microsoft calls Autopilots, operates under its own governed Entra identity rather than a shared service account, and is in private preview.[12] Its Co-Create feature lets you and Scout edit the same supported file at the same time, with your changes merged automatically, and those workspaces are stored in OneDrive or SharePoint.[13] Microsoft, like Google, is making the agent a user and leaning on the document stack it already owns.

Cursor shipped Origin, its own Git forge, in early beta in August. Repos support standard clone, push and pull, GitHub repos can be mirrored in, and cloud agents connect to Origin repos directly.[14] Coverage of the launch stressed stacked pull requests and agent-aware merge queues, helped by Cursor’s 2025 acquisition of Graphite.[15] Origin is the one entrant that keeps Git the product and tries to make the forge agent-aware, which is a bet that the merge queue Anthropic abandoned can be made to work.

The grid

The way to see all of this at once is as a grid. One axis is the fork layer, meaning where an agent’s private copy lives. The other is write arbitration, meaning what happens when two writers want the same state.

A few notes on the cells.

The compare-and-set column is where the two companies with the most agent traffic landed, and they got there from different storage. Scion arbitrates at the repository. Perplexity arbitrates at the repository but forks at the VM. Space, the startup, offers the same rule at the level of a single object: pass the version your change was based on, and if someone else wrote first you get a 412 and the winning version back.[18]

The branch-then-merge column is Git worktrees made into a product. Claude Projects threads, Daytona’s forkable sandboxes, and SPACE’s session branching all give each agent a private copy and defer the collision to a merge. This is the easiest model to ship because Git already knows how to merge. It is also the model Anthropic found does not scale past a certain rate, because the merge queue becomes the lock.

The last-writer-wins column is what object storage does naturally, with the modern twist that nothing is ever lost. Tigris bucket forks share objects by reference, writes to the fork create new versions, and you pay only for new versions.[20] Space’s default is the same: both writes succeed, both versions stay in the history, and the docs are honest that one worker’s change silently disappears from the head unless you ask for a precondition.[18]

The document row is where all the consumer products are, and it is the row with the least published detail about what happens underneath. Google Docs solved live co-editing for humans a long time ago. Whether that model holds when one of the editors produces a thousand-line change in one step is the open question I come back to below.

There is one more way into the live co-edit column, and it is the one I built. markdownfs keeps a single in-memory tree of Markdown files that humans and agents write to directly, over a REST API, an MCP server, a CLI, or a FUSE mount. There are no per-writer forks. A single-writer lock in the server serializes every write, so two writers never interleave inside a file, and history comes from explicit commits that snapshot the whole tree and can be reverted.[27] That is live co-editing at file granularity with a lock as the arbiter instead of a CRDT. It is simple, and it is the right shape for shared agent memory. It has also never been asked to take 30,000 writes a day, and a lock that serializes writes on one machine is exactly the thing Scion and Perplexity removed from their path.

Why FUSE lost and Git-as-model won

There was a tempting alternative to all of this, and both Anthropic and Perplexity considered it. Instead of giving each agent a checkout, mount the shared state as a network filesystem and let the agent read and write it directly. FUSE makes that easy. My own post in April argued the filesystem should be the agent’s interface, and I still think that.[24] But the interface and the write path are different things.

Perplexity measured it. A FUSE-backed virtual filesystem was roughly 400 times slower than local files on filesystem-heavy workloads, because each request needs a network round trip. It also required privileged capabilities from the host, which would have forced every agent into a privileged sandbox.[2] They dropped it. Large and binary files arrive as Git LFS pointer files that record the real size, so the agent can decide whether to fetch them.[2]

Anthropic reached the same split for a different reason. The problem with Git at 30,000 merges a day was not the model, meaning commits, trees, refs. It was the client, meaning every machine holding the full history and every mirror trying to keep up. So Scion keeps Git’s model and wire format and replaces the client with a thin daemon that talks to an authoritative server.[1]

Put the two together and you get the rule for this whole category. Git survives as a model and a wire format. The Git client dies. The filesystem survives as the interface. The write path moves to a server. The agent still sees files. The agent still produces commits. What it no longer does is decide, on its own machine, whether its write wins.

This also explains a result that looks unrelated. Perplexity tested an exploration agent that navigates a project’s files against semantic search over the same 150 financial documents. The agent scored 0.867 on retrieving the right document and 0.627 on answering correctly, against roughly 0.39 and 0.37 for semantic search.[2] An agent that can walk a real tree of files beats one that gets handed chunks. That is the filesystem-as-interface half of the rule, measured.

What this means for the startup layer

If the labs are each building the same primitive for themselves, where does that leave the companies selling it?

In a better spot than it looks, as long as they are selling the fork layer and not the arbitration. The grid above has a row for every kind of fork, and a startup in every row. Daytona raised a $24 million Series A in February to sell sandboxes an agent can fork into parallel branches and snapshot.[22] Tigris sells bucket forks that copy nothing and bill only for new versions.[20] Turso’s AgentFS puts an agent’s entire filesystem, state and history in one SQLite file.[21] Box has repositioned its content platform as a virtual filesystem for agents.[26] Space, a three-founder company that raised a $2.4 million pre-seed led by a16z Speedrun in August, sells forks at the shard level.[16]

Space is worth a closer look because it is the smallest company in the grid and it has the most complete answer to the arbitration question. Files are cut into content-defined chunks with FastCDC, averaging about 2 MiB, and each chunk is named by its SHA-256 hash, so a small edit rewrites only the shard it touches and the cost does not depend on how big the file is.[17] Every write is an immutable version. A fork starts as the same list of shards, so it copies nothing and is ready at once. The recommended agent pattern is to fork the drive, hand the agent a key that can only write to the fork, with that limit enforced by the endpoint on every request rather than by the prompt, review the result, and keep or delete the fork.[19] And for the cases where two agents must write the same object, the if_version precondition turns a silent lost update into a 412 you can retry.[18] That is compare-and-set at the object level, the same rule Scion applies at the repository.

So should a company building agent infrastructure buy that or build it? My estimate, from the published architecture, is that a parity rebuild of Space, meaning the sharded store, the versioning, forks, scoped keys, the S3-compatible API and the desktop mount, is roughly $1.5 million to $2.5 million with a US team, or $600,000 to $1 million with a blended team, over about a year. Drop the desktop mount and build only a forkable, versioned, S3-compatible store, and it is about a third of that. Those are my numbers, not anyone’s quote, and they assume a team that has built storage before. The point is not that it is cheap. The point is that it is now a known quantity, because the labs published the shape, and a known quantity is a product category, not a moat.

The moat, if there is one, is above the storage. It is the arbitration rule, the permission model, and the history that lets a human ask what the agent did and roll it back. Those are exactly the parts Anthropic and Perplexity said were hard.

What is still open

The storage question is settled. Everyone forks something, everyone keeps every version. The arbitration question is not, and the window exposed at least five gaps.

Live human edits and agent batch commits in one file. Every consumer product in the document row lets a person type into a document while an agent works on it. Every engineering account in the compare-and-set column treats an agent’s change as an atomic unit that either lands on the head or is rejected. Nobody has published how those two coexist in the same file. If I am typing in paragraph three while an agent submits a rewrite of the whole document built on a head from forty seconds ago, who wins? OpenAI’s Pages and Claude Docs will have an answer in code. Neither has written it down. markdownfs answers it with a lock and a commit log, which is honest but only scales as far as one server’s write lock does.[27]

Memory writes competing with project writes. Perplexity’s Brain updates a project’s memory between tasks.[5] Claude Projects threads add to and draw from a shared memory.[9] Those are writes too, and they land in the same workspace the agents are editing. Memory is the part of the agent stack most people I talk to call unsolved, and yet it got no launch wave comparable to this one. I suspect that is because nobody has decided whether memory is a file under the same arbitration rule or something else.

Cross-repository consistency. Scion’s compare-and-swap is one row per ref. Perplexity’s is one head per project. A change that must land in two repositories at once, or in a repository and a document, has no atomic path in either system as described.

Permission narrowing. Scion has per-directory permissions.[1] Space has keys scoped to a fork.[19] Google’s agents see only what you share.[10] These are three different answers, at three different granularities, and none of them yet covers the case of an agent that should be allowed to edit a file but not to delete it, or to append but not to rewrite.

Humans are still the bottleneck. This is the one that matters most. Anthropic still has a human review every one of 30,000 changes a day. What changed is that reviewers look at intent, not lines.[1] That is a tooling shift, not a removal of the constraint. If merges grow another 12x in the next four months, the review step is where it breaks. A Hacker News thread earlier this year on files as the shared interface for humans and agents ran to 132 comments and barely touched concurrency at all.[23] The field is still talking about where the files live. The hard problem has moved to who gets to change them, and who has to look.

Where I land

I wrote in January that the workspace, not the chat window, would be where agents earn their keep.[25] I did not expect every lab to prove it in the same month.

The design is now clear enough to state in four lines. Keep Git as the model, because agents already speak it and it gives you history for free. Kill the Git client, because a full offline clone is the wrong unit for a machine that lives for a minute. Keep the filesystem as the interface, because an agent that walks a tree beats one that is handed chunks. Move the write path to a server, because only one place can decide who wins, and it has to decide in under two seconds.

What that leaves is the part no vendor can sell you. A compare-and-set tells you a write lost. It does not tell you whether it should have. For the next year, the interesting work is not in the storage. It is in the rule.

References

[1] Anthropic. (2026, October 13). Redesigning source control for agent-scale development. Anthropic Engineering.

[2] Perplexity. (2026, October 12). Building shared workspaces for people and agents.

[3] Perplexity. (2026, October 15). Open-sourcing SPACE.

[4] perplexityai/SPACE. Sandboxed Platform for Agentic Code Execution. GitHub.

[5] Perplexity. (2026, July 30). Spaces are now Projects.

[6] CNBC. (2026, September 29). OpenAI DevDay 2026 live updates.

[7] The Neuron. (2026, September). OpenAI DevDay 2026: ChatGPT is becoming an AI operating system.

[8] The Next Web. (2026, September 17). Anthropic folds Cowork into Claude and launches Docs and Slides.

[9] Anthropic. (2026, September 17). Projects redesigned: from folder to conversation.

[10] Google Cloud. (2026, October 8). Welcome to Gemini at Work 2026.

[11] Google. Antigravity agent. Gemini API documentation.

[12] Microsoft. (2026, June 2). Introducing Microsoft Scout, your always-on personal agent.

[13] Microsoft Learn. Microsoft Scout (Frontier) overview.

[14] Cursor. Origin. Cursor documentation.

[15] InfoQ. (2026, August 25). Cursor launches Origin as an alternative to GitHub.

[16] The Next Web. (2026, August 18). Space raises $2.4M to abolish the hard drive with an AI-native filesystem for humans and agents.

[17] Space. Architecture. Space documentation.

[18] Space. Concurrency and preconditions. Space documentation.

[19] Space. Build with agents. Space documentation.

[20] Tigris. Forks. Tigris documentation.

[21] Turso. (2025, November 13). The missing abstraction for AI agents: the agent filesystem.

[22] Daytona. (2026, February 5). Daytona raises $24M Series A to give every agent a computer.

[23] Hacker News. (2026). Files are the interface humans and agents interact with.

[24] Subramanya N. (2026, April 13). The Filesystem Is the Database: Why Agents Need a New Storage Primitive.

[25] Subramanya N. (2026, January 19). The Agentic Workspace: A Strategic Imperative for the Next Era of SaaS.

[26] Blocks and Files. (2026, March 9). Box pitches ‘virtual filesystem’ layer for AI agents.

[27] Subramanya N. (2026). markdownfs: a concurrent markdown database with Git-style versioning, multi-user permissions, REST and MCP. GitHub.

@article{nagabhushanaradhya2026gitwas,
  author  = {Nagabhushanaradhya, Subramanya},
  title   = {Git Was Built for 2,500 Merges a Day},
  journal = {subramanya.ai},
  year    = {2026},
  month   = {October},
  url     = {https://subramanya.ai/2026/10/16/git-was-built-for-2500-merges-a-day/}
}