Aspen : le serveur Git open source pour agents atteint 567 pushs par seconde

Si vous avez déjà lancé plusieurs agents de développement sur un même dépôt, vous connaissez le problème : ils effectuent des pushs fréquemment, en parallèle et sans la moindre discipline. Un serveur Git classique a été conçu pour des humains qui réalisent quelques commits par heure. Les agents, eux, peuvent en effectuer chacun des dizaines par minute, transformant le serveur en goulet d’étranglement. La startup Reason Machines (YC F26) propose une solution : Aspen, un serveur Git open source spécialement conçu pour ce type de charge.

Ce qui est annoncé

Les auteurs mettent en avant un chiffre principal : une seule machine à 8 cœurs supporte 567 pushs par seconde vers un seul et même dépôt. La seconde partie de l’annonce est tout aussi importante : chaque push est enregistré avant que git n’affiche « ok ». Autrement dit, la vitesse n’est pas obtenue au détriment de la fiabilité : si le client reçoit une confirmation, les données ont déjà été écrites.

Le troisième point est sans doute le plus pratique : le client reste un git standard. Il n’y a rien à installer, ni plug-in propriétaire, ni SDK distinct, ni protocole personnalisé. L’agent continue d’exécuter git push, simplement vers une autre adresse.

Pourquoi cela compte particulièrement pour les agents

Imaginez une architecture d’agents typique : un orchestrateur lance 50 workers en parallèle. Chacun prend une tâche, modifie le code et pousse une branche ou un état intermédiaire. Les humains n’interviennent presque pas dans ce schéma ; Git sert de journal et de point de synchronisation. La concurrence autour d’un même dépôt entraîne des verrouillages lors de la mise à jour des références, de l’écriture des objets et des contrôles d’intégrité. À grande échelle, toutes ces opérations finissent par plafonner le débit.

Pour l’instant, nous ne disposons que d’une annonce publiée dans un post, mais l’orientation est claire : utiliser Git comme mémoire de travail des agents exige une architecture serveur différente de celle de Git comme outil de développement collaboratif.

Limites et réserves

À ce stade, nous n’avons essentiellement qu’un post sur X et une seule métrique. On ignore les modalités exactes du test : taille des pushs, types de disques, nombre de clients simultanés ou présence de conflits sur les mêmes branches. Atteindre 567 pushs par seconde avec des commits vides ou minuscules et obtenir ce résultat avec de véritables modifications dans un monorepo sont deux choses très différentes. On ignore également comment Aspen gère les hooks, les droits d’accès, la revue de code et les intégrations auxquelles les utilisateurs de GitHub et GitLab sont habitués. Le projet est jeune ; il est trop tôt pour attendre une maturité produit.

Que faire concrètement

Si vous construisez un système multi-agents et que Git constitue votre facteur limitant, consacrez une soirée à déployer Aspen, à lui soumettre votre charge réelle et à le comparer à votre serveur actuel. Ne vous focalisez pas sur le débit maximal, mais sur la latence des pushs avec votre profil de charge, le comportement en cas de conflits et la reprise après une panne. Si vous commercialisez une plateforme d’agents, observez aussi la tendance de fond : l’infrastructure qui entoure les agents commence à être réécrite en fonction de leurs modes de fonctionnement, et l’hébergement Git destiné aux machines deviendra probablement une niche à part entière.

Comme le client reste standard, le coût de l’expérimentation est faible : modifier le remote prend une minute, et revenir en arrière est tout aussi rapide.