Cursor began an early beta rollout of its code hosting service "Origin" on August 17, 2026. In a technical document published the following day, the company described its core Git storage system as "Continuity." While a standard Git repository lives on local NVMe, pushed pack files are also saved to a write-ahead log (WAL) on S3-compatible storage. The remote WAL is the source of truth; the local Git copy is a warm cache for low-latency processing. Without breaking Git compatibility, Cursor has restructured the relationship between replica count and write latency.
Not Replacing Git, But Relocating the Source of Truth
Git's core data is stored and transferred as pack files. Objects such as commits and trees, which represent history, and blobs, which hold content, form a DAG. Reaching a file from a given commit requires following pointers one at a time. Objects may also be compressed in delta form relative to other objects, so traversing the logical DAG involves layered disk reads. Placing this on a network file system introduces small round-trip delays into that chain.
Continuity preserves Git's data format. On push, pack files are written to local NVMe while simultaneously being uploaded to S3 as individual WAL entries. However, the change isn't published the moment the upload finishes. The server prepares the Git reference transaction locally, records a reference to that entry in the WAL index, and only then makes it visible. Cursor returns success to the client only after the push has been persisted to the WAL.
Here, local NVMe stops being the source of truth. The Git repository on NVMe becomes a copy that speeds up reads, one that can be reconstructed from the WAL if lost. DAG traversal, pack generation, delta expansion, and repacking all remain. What Continuity changes isn't the Git protocol itself but where durability and ordering are guaranteed. Latency-sensitive Git processing stays on local NVMe, while the full history needed for recovery is consolidated in the WAL.
The Floor of Three Replicas and the Ceiling of Giant Monorepos
In 2016, GitHub published a repository storage system called DGit. Later known as Spokes, this approach places a standard Git repository on three local SSDs. Writes are sent synchronously to all three, and a commit succeeds once at least two return matching results. This preserved the local disk access Git excels at while allowing reads and writes to continue even if one node failed.
Quorum-based replication becomes more sensitive to the slowest node as replicas increase. Adding replicas to boost read capacity means the same nodes also become synchronization partners for writes. In scenarios where CI triggers massive clone and fetch traffic against a giant monorepo, horizontal scaling for reads and push latency move in opposite directions.
Agents create the opposite problem. According to Cursor, environments where agents operate spawn large numbers of small, short-lived repositories, most of which see little use. Maintaining three permanent copies of each repository wastes capacity and operational overhead. Continuity assigns hundreds of replicas to giant monorepos while handling small repositories with a single copy. Dormant copies can be deleted from local disk and restored from the WAL on next access, the company says.
The scope where Cursor says "there is no consensus" concerns quorums and primary election among Git replicas — it doesn't mean the point of ordering has disappeared. Continuity updates the WAL index on S3 using an atomic compare-and-swap (CAS), making this CAS the serialization point for pushes. Rather than eliminating consensus, the design shifts the job of determining correct order from a group of replicas to a single update on object storage.
The Division of Labor Between UDP Notifications and ETag Verification
CAS on the WAL index requires a mechanism that allows only one of two conflicting updates to succeed. Taking AWS S3's conditional writes as an example, a PUT with an If-Match header succeeds if the specified ETag matches the current object's ETag, and returns 412 if it doesn't. Cursor explains that it updates the WAL index via atomic CAS, but doesn't specify the exact API or header names used. What is confirmed is that regardless of which server receives a push, updates are serialized through CAS, and a server whose update conflicts must re-fetch the newer index.
Under normal conditions, the node hosting a repository is determined by rendezvous hashing based on the repository ID and the set of healthy nodes. This calculation doesn't require a massive routing table mapping every repository to every server. If a node goes down and the assignment changes, the next candidate reconstructs the repository from the WAL. Rather than repairing a broken copy back to the source of truth, the system can simply discard and rebuild it.
Update notifications use UDP gossip. Since UDP packets can be lost, Continuity doesn't treat these notifications as a basis for correctness. When reading, a replica sends a conditional GET to S3 using the ETag of its own WAL index. A 304 response means it's current, and it responds directly to the clone or fetch request. A 200 response means a newer index is available, which it fetches and applies any missing WAL entries before responding.
According to Cursor, the 304 response confirming metadata averaged under 10 milliseconds. Gossip serves as a fast signal to catch up quickly, while S3 verification ensures stale state is never returned. It's a division of labor: an untrusted notification channel is used for performance gains, while consistency is guaranteed through a separate path.
Why Compaction Can Be Consolidated to a Single Node
As each push adds a new pack file, Git must search through numerous indexes to find target objects. Multi-pack indexes and incremental recompression reduce search costs, but compaction — the process of consolidating packs — itself remains unavoidable. In a Spokes-style setup where local Git on each replica serves as the source of truth, compaction must either run on every replica or compression results must be strictly synchronized across them.
In Continuity, only the primary runs compaction, and its result is also recorded to the WAL. Other replicas download the already-compressed pack from S3. Instead of repeating the same CPU load across every replica, the result of a single computation is distributed via network bandwidth. This makes it easier to decouple read capacity from push performance, since increasing replica count doesn't proportionally increase the number of compaction runs.
Git-derived work still remains, though. In Cursor's own testing, once push performance exceeded 300 operations per second on S3 Express One Zone, local Git compaction became the bottleneck. Even after shifting the source of truth to the WAL, the CPU time needed to rebuild packs doesn't disappear. The advantage lies in consolidating heavy processing into a single run and reusing that result.
Meanwhile, the size of the WAL index and how it's partitioned haven't been disclosed. It's also unclear how much CAS retry increases for repositories under heavy write concentration, or which operations can continue during an S3 outage. Whether the load reduced by consolidating compaction has simply shifted to contention over WAL index updates needs to be verified in production.
Reading the Numbers: 100 Replicas, 120 and 300 Pushes Per Second
In Cursor's synthetic benchmarks, read performance scaled linearly up to 100 replicas without degrading push performance, according to the company. On S3 Standard, the system sustained up to 120 pushes per second while performing compaction and replication simultaneously. On S3 Express One Zone, it exceeded 300 pushes per second, after which local Git compaction became the limiting factor.
However, these two figures can't be directly compared as measurements under equivalent fault-tolerance conditions. AWS classifies S3 Standard as a class stored across multiple Availability Zones (AZs), while S3 Express One Zone is confined to a single AZ. The gap between 120 and over 300 pushes per second reflects different storage failure domains. It's also unclear whether the Express One Zone test included a separate durability layer spanning AZs or regions.
The published materials don't include repository size, object counts, or push sizes. Concurrency levels, server configuration, number of trials, and latency distributions are also not shown. The figures of 100 replicas, 120 and 300+ pushes per second, and sub-10-millisecond responses are all Cursor's own measurements; no third-party reproduction results or public code for Continuity have been confirmed.
Origin remains in early beta, and there's no published SLA, operational failure history, or independent durability audit to draw on yet. Measuring CAS failure rates and recovery time under concentrated write load, and confirming procedures during S3 outages along with cross-AZ durability, would allow the design's core promise — how far Git copies can be reduced — to be evaluated against real-world results.