Cursor has made its choice: Spokes is out, Continuity takes its place.
The first is a consensus-based distributed storage system. Born in the early 2010s, it has become the substrate for many Git hosting services.
The second is an attempt to address its limits – both in scalability and in maintaining coherence. Its architecture centers on a concept intrinsic to S3: the Write-Ahead Logs (WAL). In broad strokes, these involve storing several objects in a single file sequentially.
On this basis, Cursor developed a forge that it called Origin. In mid-August, it began granting access to it, in beta, for subscribers on its paid plans.
On the surface, there are for now no functional specifications that set it apart from the competition. There are, above all, far fewer integrations: the catalog is limited to Vercel, Depot and Buildkite.
Cursor has worked on the bridges with GitHub, but not everything is yet synchronized (issues and CI workflows, for example). It promises, in the short term, connectors with its agents.
Repeated outages for GitHub, victim of “agentic overload”
The announcement of Origin came on the same day GitHub experienced its latest major outage to date. At peak, web and API error rates hovered around 20% (50% for archiving and file downloads). The cause was network saturation on load balancers in the United States. The problem stemmed from a poorly configured autoscaling policy, resulting in an Istio pod hitting its concurrency limits.
GitHub has suffered other major outages in recent weeks. Notably in CI. On July 9, the degradation of a hosted-executor provisioning service prevented some workloads from being acquired. Ten days later, an SSL certificate expiration caused some runners to lose connectivity. In early August, following a routing deployment to an internal event-processing and job-creation service, up to 70% of CI flows failed. Another disruption occurred at the end of the month, due to saturation of writes to a database used by triggers.
These recent months, the platform has more broadly suffered from a clear uptick in load within the agent development context. The problem is not so much about GitHub as about Git. Thus Cursor did not merely design Origin, but also Continuity.
Addressing Spokes’ scalability limits
Git does not cope well with eventual coherence. It is preferable to keep coherence continuously. To achieve this, Spokes accepts a very high cost of complexity.
At launch, three replicas per repository represented the ideal compromise, according to Cursor. Today, things have changed: repositories have become massively large.
Once you start adding replicas, a long-tail latency problem emerges, with the latency of each step determined by the slowest server in the cluster. This scalability constraint also applies in the other direction. When agents work on a monorepo, they often operate on the outside, creating a large number of small repositories. So as many replicas to maintain to fully guarantee coherence.
Cursor underscores another shortcoming of Spokes: since the on-disk repositories remain the source of truth for the consensus, every copy matters. You must know exactly where each repository resides. That adds a dependency on an external routing table.
No consensus nor state
To guarantee fully horizontally scalable coherence, Continuity’s central component is therefore the Write-Ahead Log. Each push is stored there as a distinct object. The packfile (Git’s binary serialization format) is both written to disk and uploaded to S3. A push only becomes visible after the reference transaction is prepared on a local copy of the repository and a pointer to the WAL entry is recorded in the index file. Taken together, this guarantees that all pushes are linearizable, Cursor explains.
Since all that matters is synchronizing the reference transaction with a single local repository rather than with a quorum of replicas, the system can ingest pushes as fast as the disk allows.
Continuity also eliminates the need to track the location of each repository on every server. The source of truth remains the Write-Ahead Log. The system is stateless and does not require routing tables or a relational database. If a repository is absent from the local disk when accessed on a host, it is materialized from the WAL.
There is also no consensus: any server can be the primary. The WAL synchronization is performed by an atomic compare-and-swap operation on S3. It is therefore always safe that any instance of a repository receives a push, claims Cursor.
Up to 300 pushes per second
Continuity performs optimistic replication by sending UDP gossip packets within the cluster. Each replica knows the ETag (entity tag) of the latest version of the WAL index it has caught up to. Read operations on a replica consist of conditional GETs with the expected ETag. Having S3 as the source of truth avoids issues when the UDP packet is lost or lands on the wrong server. The system scales in both directions, so each repository has the right number of replicas, according to Cursor. And the throughput of Git read operations (clone, fetch, etc.) increases linearly.
Continuity also amortizes the cost of compaction. Only the primary node performs it. The result applies to both the repository on disk and the WAL. Since all replicas follow the WAL, they also follow the compaction events.
The throughput of pushes in a cluster depends on the WAL update latency. With S3 Standard, Cursor manages to sustain 120 pushes per second. With Express One Zone, it reaches 300 pushes/s. The limiting factor is the speed with which Git can compact data on disk. Cursor says it is working on data organization methods to reduce the impact of compaction.
