Cursor Details Continuity, an S3-Backed Git Storage Engine Built to Outrun Spokes' Consensus Bottleneck

Overview

Cursor has published a detailed technical account of Continuity, the storage engine underpinning its Origin code-hosting platform, describing an architecture that replaces the three-phase-commit consensus model long used to scale Git hosting with a write-ahead log stored in S3-compatible object storage. The post, written by Cursor principal systems engineer Vicent Martí and published August 18, 2026, was covered days later by The Register, which credited Martí, who The Register said had worked “at GitHub through much of the last decade,” with explaining “how the SpaceX subsidiary worked through its scaling issues with the notoriously fickly Git distributed version control system.”

What We Know

Martí frames the problem as a paradox baked into Git’s design: “a distributed version control system means that all instances of a repository are identical,” according to Cursor’s blog post, yet companies running Git at scale need centralized, highly available servers rather than fully peer-to-peer copies. Every object in a Git repository — blobs, trees, commits — is “keyed by the SHA-1 of their contents,” and the overall layout of a repository forms a directed acyclic graph, or DAG, according to the same post.

The industry-standard approach to scaling Git hosting, which Cursor’s post associates with the architecture GitHub calls Spokes, keeps repositories on local NVMe disks and synchronizes replicas using three-phase commit, a consensus algorithm that “ensures that all nodes on a system agree to either commit or rollback a transaction” across three round-trips, per Cursor’s post. The post argues this model has a structural weakness: because it is a consensus algorithm, “the latency of every step is bound by the slowest of all the servers in the cluster.” That architecture also forces operators to treat individual repositories as “pets, not cattle,” the post says, meaning each one needs individual tracking and management rather than being freely interchangeable.

Continuity’s alternative treats an S3-compatible write-ahead log, not the local disk copy, as the source of truth for every repository. “We never acknowledge a push until it has been fully persisted,” Martí wrote. Local NVMe copies become disposable: “Where does every repository live? The answer is ‘anywhere’. It doesn’t matter! We treat repositories like a warm cache on disk, but the source of truth is always the write-ahead log,” according to Cursor’s blog — a description The Register reproduced in its own coverage. Rather than a quorum vote among replicas, Continuity relies on atomic operations against S3 to order and confirm pushes; Martí told The Register that “with the only requirement of having to synchronize the reference transaction with a single local repository instead of a quorum of replicas, we have a system that can ingest pushes as fast as our disk allows.”

Cursor’s post reports specific throughput figures from its own testing: using S3 Standard, Continuity can “sustain up to 120 pushes/s while compacting and replicating the compacted data to all other nodes,” and switching to S3 Express One Zone lets it “ingest more than 300 pushes/s,” at which point the bottleneck shifts to “the speed at which Git can compact the on-disk data,” according to Cursor’s blog post. Checking whether a replica’s local cache is current is designed to be near-instant — the post describes a metadata-only check returning “a 304 response with no body” in “less than 10ms on average.” Cursor says it has run “synthetic stress tests with up to 100 replicas and seen consistent linear scaling for reads, without any regressions in push throughput,” a contrast with the older architecture, where the post says “three replicas per repository was the sweet spot.”

Martí ties the redesign directly to AI coding agents’ effect on Git load. “Agents have fundamentally changed the way we work with software, and in many ways they’ve made this situation worse. More code, more PRs, more CI runs,” he wrote in the post, a line also quoted by The Register. For scale context on the incumbent Cursor is positioning Origin against, The Register noted that GitHub operates at a scale where the company must provide its service for “over 400 million repositories.”

Continuity is the engine behind Origin, the GitHub-competing code-hosting platform Cursor began rolling out in beta on paid plans on August 17, as previously reported — a launch that coincided with a roughly six-hour GitHub outage. “A beta of the service is available with paid Cursor plans,” The Register confirmed. Cursor’s post describes Origin as a mature effort rather than a trial run: “Origin is not an experiment; it is the result of many decades of experience building these same systems, from people who deeply understand the magnitude of the challenges involved.”

What We Don’t Know

Cursor’s post does not disclose the hardware specifications, cluster size, or cost of running Continuity in production, nor does it say how the 120 and 300+ pushes-per-second figures compare to real-world Origin traffic rather than synthetic benchmarks. Neither source specifies how many repositories or organizations Continuity currently serves, or whether the architecture has been tested at anything close to GitHub’s reported scale of over 400 million repositories.

Analysis

The post positions Continuity as a rebuttal to the assumption that Git hosting must trade consistency for scale through consensus protocols like three-phase commit. By moving the durability guarantee into an object-storage write-ahead log and treating local disk state as disposable cache, Cursor is betting it can sidestep the operational overhead — the “pets, not cattle” problem — that has constrained rivals built on the Spokes-style model. Whether that bet pays off in practice will depend on how Continuity performs once it carries production traffic at a scale approaching the incumbent it is built to challenge, a test the published benchmarks do not yet address.