Cursor has abandoned Spokes in favor of Continuity, a new architecture meant to address the scaling and consistency limits of its earlier Git storage system. Spokes, introduced in the early 2010s, is a distributed storage layer based on consensus and has become the foundation of many Git hosting services. Cursor says that model no longer fits today’s workloads, especially as repositories have grown larger and agent-driven development has multiplied the number of operations and small repos to manage.

On top of Continuity, Cursor has built its own forge, called Origin, which opened in beta in mid-August to paying subscribers. Functionally, Origin is not yet differentiated from competitors, but it currently offers far fewer integrations: only Vercel, Depot and Buildkite are supported. Cursor has worked on GitHub interoperability, though synchronization is still incomplete — issues and CI workflows, for example, are not yet fully mirrored. The company says short-term integrations with its agents are coming.

The announcement landed on the same day as GitHub’s latest major outage. At peak, web and API error rates reached nearly 20%, and file archiving and downloads hit 50% errors. GitHub said the incident was caused by network saturation on U.S. load balancers, itself the result of a misconfigured autoscaling policy that led an Istio pod to hit concurrency limits. It was only the latest in a series of disruptions: on July 9, a provisioning service failure prevented some workloads from obtaining hosted runners; ten days later, an SSL certificate expiration cut connectivity for some runners; in early August, a routine deployment to an internal event-processing and job-creation service caused up to 70% of CI flows to fail; and at the end of the month, writes to a database used by triggers became saturated. More broadly, GitHub has been under increasing load in the era of agentic development — though Cursor argues the deeper issue is Git itself, not GitHub.

Cursor’s critique of Spokes is that Git does not handle eventual consistency well, and keeping consistency continuously comes at a high complexity cost. When Spokes launched, three replicas per repository was considered the ideal trade-off, but repositories have since become much larger. Adding replicas creates a long-tail latency problem, since each step is limited by the slowest server in the cluster. The same scaling issue appears in reverse for monorepos broken into many small repos by agents: each one must still be replicated to preserve full consistency. Cursor also notes that because on-disk repositories remain the source of truth for consensus, every copy matters, which forces the system to maintain an external routing table to know where each repository lives.

Continuity removes both consensus and state from the core path. Its central component is a write-ahead log built around S3. Each push is stored as a separate object; the Git packfile is written to disk and uploaded to S3. A push only becomes visible after a reference transaction is prepared on a local copy of the repository and a pointer to the WAL entry is written into the index file. Cursor says this makes all pushes linearizable. Because the system only needs to synchronize the reference transaction with one local repository rather than a quorum of replicas, it can ingest pushes as fast as the disk allows.

The design also eliminates the need to track where every repository lives on every server. The WAL is the source of truth, so the system is stateless and does not require routing tables or a relational database. If a repository is missing from local disk when accessed on a host, it can be materialized from the WAL. There is no consensus layer either: any server can act as primary. WAL synchronization relies on an atomic compare-and-swap operation on S3, which Cursor says makes it safe for any repository instance to accept a push.

For replication, Continuity uses optimistic gossip over UDP packets. Each replica knows the ETag of the latest WAL index version it has caught up to, and reads are performed through conditional GET requests using the expected ETag. Because S3 is the source of truth, lost UDP packets or packets arriving at the wrong server do not break correctness. Cursor says the system scales in both directions, giving each repository the right number of replicas and increasing read-only Git throughput — clone, fetch and similar operations — linearly.

Compaction is also handled differently: only the primary node performs it, and the result applies both to the on-disk repository and the WAL. Since all replicas follow the WAL, they also follow compaction events. Push throughput depends on WAL update latency: Cursor says it can sustain 120 pushes per second with S3 Standard and 300 pushes per second with Express One Zone. The current bottleneck is Git’s own ability to compact data on disk, and Cursor says it is working on data-layout methods to reduce that overhead.

Cursor a fait son choix : exit Spokes, place à Continuity.

Le premier est un système de stockage distribué fondé sur le consensus. Né au début des années 2010, il est devenu le substrat de nombreux services d’hébergement Git.

Le second est une tentative d’en pallier les limites – tant en matière de scalabilité que de maintien de la cohérence. Son architecture est centrée sur un concept propre à S3 : les journaux d’écriture anticipée (WAL, Write-Ahead Logs). Lesquels consistent, dans les grands lignes, à stocker plusieurs objets dans un même fichier de manière séquentielle.

Sur cette base, Cursor a développé une forge qu’il a appelée Origin. Mi-août, il a commencé à y donner accès, en bêta, pour les abonnés à ses forfaits payants.

En façade, il n’y a pour le moment pas de spécificités fonctionnelles par rapport à la concurrence. Il y a surtout beaucoup moins d’intégrations : le catalogue se limite à Vercel, Depot et Buildkite.

Cursor a soigné les passerelles avec GitHub, mais tout n’est pas encore synchronisé (issues et workflows CI, par exemple). Il promet notamment, sur le court terme, des jonctions avec ses agents.

Pannes répétées pour GitHub, victime de « surcharge agentique »

L’annonce d’Origin est tombée le jour même où GitHub a connu sa dernière panne majeure en date. Au pic, les taux d’erreur web et API ont avoisiné 20 % (50 % sur l’archivage et le téléchargement de fichiers). En cause, une saturation réseau sur des load balancers aux États-Unis. Le problème découlait d’une politique d’autoscaling mal configurée, en conséquence de quoi un pod Istio avait atteint ses limites de concurrence.

GitHub a connu d’autres pannes importantes ces dernières semaines. En particulier sur le CI. Le 9 juillet, la dégradation d’un service de provisionnement d’exécuteurs hébergés a empêché certains workloads d’en acquérir. Dix jours plus tard, une expiration de certificat SSL a entraîné une perte de connectivité pour certains runners. Début août, à la suite d’un déploiement de routnie vers un service interne de traitement d’événements et de création de jobs, jusqu’à 70 % des flux CI ont échoué. Une autre perturbation est survenue à la fin du mois, due à une saturation des écritures vers une base de données exploitée par les déclencheurs.

Ces derniers mois, la plate-forme a plus globalement souffert d’un net accroissement de la charge dans le contexte du développement agentique. Le problème n’est toutefois pas tant lié à GitHub qu’à Git. Ainsi Cursor n’a-t-il pas seulement conçu Origin, mais aussi Continuity.

Remédier aux limites de scalabilité de Spokes

Git s’accommode mal de la cohérence éventuelle. Il est préférable de la maintenir en continu. Pour cela, Spokes accepte un coût de complexité très élevé.

À son lancement, trois répliques par dépôt représentaient le compromis idéal, d’après Cursor. Aujourd’hui, les choses ont changé : les repos se sont massifiés.

Dès lors qu’on commence à ajouter des répliques apparaît un problème de la longue traîne, la latence de chaque étape étant déterminée par le serveur le plus lent du cluster. Cette contrainte de scalabilité vaut aussi dans l’autre sens. Lorsque des agents travaillent sur un monorepo, ils opèrent souvent en dehors, créant un grand nombre de petits dépôts. Soit autant de répliques à maintenir pour garantir entièrement la cohérence.

Cursor souligne un autre défaut de Spokes : puisque les dépôts sur disque constituent toujours la source de vérité pour le consensus, chaque copie est importante. Il faut donc savoir exactement où se trouve chaque dépôt. Ce qui ajoute une dépendance envers une table de routage externe.

Pas de consensus ni d’état

Pour garantir une scalabilité horizontale entièrement cohérente, le composant central de Continuity est donc le journal d’écriture anticipée. Chaque push y est stocké sous la forme d’un objet distinct. Le packfile (format de sérialisation binaire de Git) est à la fois envoyé sur disque et téléversé sur S3. Un push ne devient cependant visible qu’après préparation de la transaction de référence sur une copie locale du dépôt et enregistrement d’un pointeur vers l’entrée WAL dans le fichier d’index. L’ensemble garantit que tous les pushs sont linéarisables, explique Cursor.

Comme il suffit de synchroniser la transaction de référence avec un seul dépôt local plutôt qu’avec un quorum de répliques, le système peut ingérer les pushs aussi vite que le permet le disque.

Continuity élimine aussi le besoin de suivre l’emplacement de chaque dépôt sur chaque serveur. La source de vérité reste le journal d’écriture anticipée. Le système est sans état et ne nécessite ni tables de routage, ni base de données relationnel. Si un dépôt est absent du disque local lors d’un accès sur un hôte, on le matérialise à partir du WAL.

Il n’y a pas non plus de consensus : n’importe quel serveur peut être le principal. La synchronisation du WAL se fait par une opération atomique de comparaison et d’échange sur S3. Il est donc toujours sûr que n’importe quelle instance d’un dépôt reçoive un push, prétend Cursor.

Jusqu’à 300 pushs par seconde

Continuity effectue une réplication optimiste en envoyant des paquets UDP de gossip dans le cluster. Chaque réplique connaît l’ETag (entity tag) de la dernière version de l’index WAL qu’elle a rattrapée. Les opérations de lecture sur une réplique consistent en des requêtes GET conditionnelles avec l’ETag attendu. Avoir S3 comme source de vérité évite les problèmes quand le paquet UDP se perd ou arrive sur le mauvais serveur. Le système passant à l’échelle dans les deux directions, chaque dépôt dispose du bon nombre de répliques, selon Cursor. Et le débit des opérations Git en lecture seule (clone, fetch…) augmente linéairement.

Continuity amortit par ailleurs le coût du compactage. Seul le nœud principal l’effectue. Le résultat s’applique à la fois au dépôt sur disque et au WAL. Comme toutes les répliques suivent le WAL, elles suivent aussi les événements de compactage.

Le débit des pushs d’un cluster dépend de la latence de mise à jour du WAL. Avec S3 Standard, Cursor parvient à maintenir 120 pushs par seconde. Avec Express One Zone, il atteint 300 pushs/s. Le facteur limitant est la vitesse à laquelle Git peut compacter les données sur disque. Cursor dit travailler sur des méthodes d’organisation de ces données afin de réduire l’impact du compactage.

Illustration générée par IA

The post Cursor s’appuie sur S3 pour repenser Git… et concurrencer GitHub appeared first on Silicon.fr.