Over the past 30 years, Git has operated on a single architectural assumption: the server is the source of truth. Cursor just deleted that assumption, and most developers haven't noticed the knife.
On the surface, this week's announcement looks like a new code hosting platform. Origin, built by Cursor's parent Anysphere, with an open-sourced core called walgit contributed by Shopify CEO Tobi Lütke. The tech press called it a "GitHub competitor." That framing misses the actual event by roughly 15,000 feet.
What actually happened is far more consequential. Origin inverts the entire Git storage stack by making object storage the source of truth, degrading the Git server to a stateless cache layer. This is not a competitor to GitHub. This is an architectural end-run around it.
Context: The 30-Year-Old Assumption
Git's core design dates to 2005, but its operational assumptions go back to the CVS era: one server, one repository, one authoritative copy. Even GitHub—a company valued at $7.5 billion when Microsoft acquired it—has never questioned this fundamental topology. The server stores everything; clients pull from it; servers replicate to other servers.
This creates a scaling bottleneck that every large engineering organization knows intimately: monorepo clones take hours, distributed teams fight over a single primary node, and storage costs grow superlinearly as repositories accumulate.
The workaround has always been tooling. Git LFS, shallow clones, partial clones, submodules—all patches on the same underlying flaw. None of them address the core problem: the Git server is not horizontally scalable.
Core: Dissecting the walgit Architecture
The architectural surgery here is precise, and it's worth walking through in technical detail.
First, the source of truth moves. In a standard Git system, the server's file system is the final record of history. In walgit's model, the final record is object storage—S3 or GCS. The Git server itself becomes a cache, a thin computational layer that reads and writes blobs to the object store. No local disk state is authoritative.
This is a genuinely bold move. Git was never designed for this. The "code does not lie; people do" principle is embedded in Git's object model: content-addressed, immutable, cryptographically verified. But the transport layer—how blobs travel between client and server—was never designed to be decoupled from the server's local disk.
Second, the WAL (Write-Ahead Log). This is the crucial data integrity mechanism. Every mutation to the repository—a ref update, a push, a branch creation—is first written to a log before it's applied. The WAL ensures ordering and durability. If the server crashes mid-push, the log is replayed to reconstruct the state. This is a standard distributed systems pattern, but it's new to Git servers. It enables the statelessness that makes the entire system horizontally scalable.
Third, CAS (Check and Set) semantics. When multiple agents attempt concurrent updates, the server checks the current state against what the client believes it is. If there's a conflict, the update fails. This is the classic CAS pattern from distributed systems, and it's necessary to maintain consistency across what may be many stateless server instances all pointing to the same object storage bucket.
Fourth, bundle-uri support. This is a relatively new Git protocol feature that allows clients to download repository objects as a single bundle rather than a negotiated protocol exchange. For large repositories, this is a game-changer: instead of thousands of round trips, you get one streaming download. Combined with object storage, this means clone speeds are bounded by S3's transfer speed, not the Git server's CPU.
The cumulative effect is clear: a system where storage and compute are fully decoupled, where servers are disposable, and where the entire platform's cost structure is bounded by S3 pricing rather than dedicated server capacity.
The Business Layer: What This Actually Enables
From a due diligence perspective, the economics are the story.
The marginal cost structure is fundamentally different. A traditional Git server incurs infrastructure costs per repository, per user, per active connection. The object storage model is pure pay-per-use: you pay for what you store and what you transfer. There is no fixed infrastructure cost beyond the stateless compute layer.
This is the difference between owning a fleet of trucks versus paying a freight company per mile. The latter scales infinitely without capital expenditure.
The unit economics shift from fixed to variable. For a platform like Origin, the cost of serving a user is negligible in the S3 model. A competitor's cost is their infrastructure capacity plus idle time. Origin's cost is whatever S3 charges for the bytes the user actually consumes. This difference in unit economics will show up in pricing, and it will show up in margins.
The NRR potential is embedded in the architecture. Once a company has stored its entire codebase in Origin's object storage, switching becomes materially difficult. The data is in Origin's bucket. The migration path is not just code; it's the entire storage topology. This is the same lock-in mechanism that made GitHub sticky, but now it's enforced by the storage layer itself.
What the Bulls Miss: The Collaboration Vacuum
Now the contrarian angle. The optimistic read is: this is a foundational re-architecture of Git, with Shopify's CEO behind it, and the AI-native capabilities of Cursor are going to make this a true GitHub killer.
That view has a data problem.
The PR/Issues/CI layer is missing. The current Origin product has no pull requests, no issues, no CI/CD. For a code hosting platform, this is like a car with no steering wheel. You can have the best engine in the world, but you can't drive it anywhere.
The GitHub network effect is not just storage. GitHub's value is in the collaboration layer: the PR review process, the issue tracking, the CI integration, the massive third-party ecosystem. None of that exists in Origin. The architecture is superior; the product is incomplete.
And then there's the elephant in the room: Git is already fast for most people. The performance gains from bundle-uri and object storage are relevant to monorepo-scale users. For the average developer working on a mid-sized repo, GitHub's current performance is acceptable. The differentiation is marginal for the mass market, meaningful for the extreme user.
The Takeaway: Watch the Adoption Curve, Not the Technology
The architecture is right. The storage-as-truth model is the correct endgame for code hosting. I've seen this pattern before in my 2018 audits of 0x v2, where the protocol's logic was sound but the infrastructure assumption was flawed. The reverse is now true: the infrastructure is sound, but the product layer is unproven.
The critical question is not whether the architecture is better—it is. The critical question is whether Anysphere can build the collaboration layer that makes it usable. That's a product organization problem, not a technical one. A team that built an AI assistant that writes code is not the team that necessarily builds the PR workflow that 10,000 developers use.
One thing is clear: the 30-year monopoly on Git architecture has been broken. Whether Origin can build on top of that break, or whether someone else will, is the next transaction to watch.
High yield is a warning, not a welcome. The yield here is the promise of a new architecture. The warning is that the collaboration layer is missing, and history tells me that the gap between "great architecture" and "great product" is where most platforms die.
Postscript: If you're a developer considering migrating your monorepo, I suggest waiting. The plumbing is right, but the pipeline is empty. Let the beta users debug it. The data will tell us when it's ready.
