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.

Lire aussi : Build 2026 : ce que Microsoft met dans sa « plate-forme agentique » 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.

Lire aussi : GitHub Copilot passe (essentiellement) à la facturation à l'usage 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