Razones de Máquinas abre el código fuente de Aspen, un servidor Git diseñado para agentes de inteligencia artificial
Reason Machines Open-Sources Aspen, a Git Server Built for AI Agents
Asif Razzaq
Reason Machines ha lanzado Aspen, un servidor Git de código abierto para tráfico de agentes de inteligencia artificial. Está diseñado para repositorios a los que cientos de agentes envían actualizaciones al mismo tiempo. Aspen implementa de forma independiente el diseño que OpenAI describió para Pando.
TL;DR
Tamaño: Un binario de Rust. Las ramas viven en PostgreSQL (o SQLite), y los paquetes viven en almacenamiento de objetos.
Se ejecuta en: Una laptop (aspen dev), un host a través de Docker Compose, o nubes con Helm y Terraform.
Rendimiento: Los envíos a ramas diferentes nunca esperan entre sí, y las recuperaciones reutilizan paquetes almacenados.
Mejor: 567 envíos por segundo sostenidos durante 5 minutos en un servidor de 8 núcleos (autoinformado).
Peor: Aterrizando en main se ejecuta a unos 4 por segundo, y el proyecto es pre-alfa.
Resumen: Mejor: las escrituras por rama eliminan el límite de envíos por repositorio. Peor: no hay lanzamientos, no hay interfaz de usuario web, y no se cumple la puerta de durabilidad de 24 horas.
¿Qué es Aspen?
Aspen es un servidor Git autohospedable de Reason Machines que escala escrituras por rama, no por repositorio. Habla Git plano sobre HTTPS y SSH. Los paquetes van a almacenamiento de objetos compatible con S3; la historia de la rama va a PostgreSQL.
¿Por qué los servidores Git clásicos luchan con agentes de inteligencia artificial?
Un agente envía actualizaciones cada pocos minutos, y CI recupera después de cada envío. Según Reason Machines, un servidor clásico coloca en cola cada envío a un repositorio junto con los demás. También construye un paquete fresco para cada recuperación. El trabajo del servidor crece con los clientes, no con el nuevo código.
OpenAI llegó a este límite y construyó Pando. Redujo la latencia media de envío en casi 5 veces y sirve casi un petabyte diariamente.
¿Cómo funciona Aspen?
Aspen sigue a Pando y descarta 2 afirmaciones que la mayoría de los servidores Git mantienen.
Comparación y sustitución por rama
Cada rama es una cadena de versiones en una fila de Postgres. Un push sube su paquete, luego mueve la rama con una comparación y cambio. Los push a ramas diferentes nunca esperan uno al otro. Si 2 push compiten en una rama, uno gana. El otro obtiene el error habitual de Git "fetch first". El costo: las ramas pueden leerse en momentos ligeramente diferentes.
Paquetes almacenados en lugar de paquetes por cliente
Aspen nunca desempaca un push. Verifica el paquete, completa las bases que faltan y lo almacena tal como está. Un fetch transmite paquetes almacenados que el cliente carece, recomprimiendo nada. Las URLs firmadas pueden servir paquetes desde una CDN.
Publicidad y compactación solo de tronco
Un push solo ve la rama del tronco, por lo que la negociación permanece pequeña con un millón de ramas. La compactación en segundo plano fusiona paquetes 16 a la vez, en niveles como un árbol de fusión estructurado como un log. Un cliente que está muy atrasado obtiene unos pocos decenas de paquetes, no miles. Las fetch de CI de profundidad 1 obtienen un paquete de punta construido una vez y servido a cada trabajo.
La prueba utilizó un servidor de 8 núcleos, S3 Standard y un Postgres de 4 núcleos. El objetivo era una copia de git.git, aproximadamente 4,500 archivos y 75,000 commits. Aspen sostenido 567 pushes por segundo durante 5 minutos sin errores. Cada push alcanzó S3 y Postgres antes de que Git imprimiera “ok.”
Latencia media de push: 208 ms; percentil 99: 314 ms.
Otro cliente vio cada push 30 ms después del reconocimiento, en la mediana.
Tormenta de fetch de profundidad 1: 1.029x los bytes de stock git upload-pack en git.git.
Cursor informa hasta 120 pushes por segundo para Origin en S3 Standard. En S3 Express One Zone supera los 300. Eso es un clúster replicado en el monorepo de Cursor, por lo que las configuraciones difieren. El README llama a las cifras de Aspen indicativas, no reclamos de rendimiento.
¿Cómo se compara Aspen con otros backends de Git a escala de agente?
Por repositorio (registro de escritura anticipada en S3)
Por rama
Compromiso de tres fases entre réplicas
Almacenamiento de referencias
PostgreSQL o SQLite
Índice WAL en S3, sin base de datos relacional
Tienda de metadatos
Repos de Git en NVMe
Servicio de fetch
Paquetería almacenada, ensamblada o a través de URIs
Cache de repositorio Git local en NVMe
Paquetería almacenada reutilizada
Réplicas de repositorio Git
Tasa de push publicada
567/s, S3 Estándar, 1 servidor (autoinformado)
120/s S3 Estándar; 300+/s S3 Express
No divulgada
No divulgada
Otro resultado publicado
Push p99 314 ms
Escalado lineal de lectura hasta 100 réplicas
Latencia de push media reducida casi 5 veces
No divulgada
¿Cómo se despliega Aspen?
Se construye desde el código fuente con Rust. aspen dev ejecuta todo con SQLite y un directorio local. Los equipos obtienen Docker Compose con PostgreSQL y MinIO, además de un gráfico de Helm. Terraform cubre AWS, Google Cloud, Azure y Hetzner. El modo de espejo fronts GitHub o GitLab, por lo que puede probarlo sin migrar.
La demo en vivo es un lienzo de 64 x 64 píxeles donde cada clic es un commit empujado. Según la empresa, un agente de Reason construyó Aspen desde el primer commit hasta el lanzamiento público en 4 días. Eso tomó 151 PR fusionados.
Puntos clave
Aspen es un servidor Git Apache 2.0 construido para tráfico de push a escala de agente.
Es una implementación independiente y abierta del diseño Pando de OpenAI.
Autoinformado: 567 pushes por segundo en un servidor de 8 núcleos, p99 314 ms.
Los clientes no necesitan cambios; el git de stock funciona sobre HTTPS y SSH.
¿Necesita asociarse con nosotros para promocionar su repositorio de GitHub o su página de Hugging Face o lanzamiento de producto o seminario web, etc.? Conéctese con nosotros
Reason Machines has released Aspen, an open-source Git server for AI agent traffic. It targets repositories that hundreds of agents push to at once. Aspen independently implements the design OpenAI described for Pando.
TL;DR
Size: One Rust binary. Branches live in PostgreSQL (or SQLite), packs live in object storage.
Runs on: A laptop (aspen dev), one host via Docker Compose, or Helm and Terraform clouds.
Performance: Pushes to different branches never wait on each other, and fetches reuse stored packs.
Best: 567 pushes per second sustained for 5 minutes on one 8-core server (self-reported).
Worst: Landing on main runs at about 4 per second, and the project is pre-alpha.
Bottom line: Best: per-branch writes remove the per-repository push ceiling. Worst: no releases, no web UI, and the 24-hour durability gate is not met.
What is Aspen?
Aspen is a self-hostable Git server from Reason Machines that scales writes per branch, not per repository. It speaks plain Git over HTTPS and SSH. Packs go to S3-compatible object storage; branch history goes to PostgreSQL.
Why do classic Git servers struggle with AI agents?
An agent pushes every few minutes, and CI fetches after each push. Per Reason Machines, a classic server queues every push to a repository together. It also builds a fresh pack for every fetch. Server work grows with clients, not with new code.
OpenAI hit this wall and built Pando. It cut median push latency by nearly 5x and serves nearly a petabyte daily.
How does Aspen work?
Aspen follows Pando and drops 2 claims most Git servers keep.
Per-branch compare-and-swap
Each branch is a chain of versions in one Postgres row. A push uploads its pack, then moves the branch with one compare-and-swap. Pushes to different branches never wait for each other. If 2 pushes race on one branch, one wins. The other gets Git’s usual “fetch first” error. The cost: branches may be read at slightly different moments.
Stored packs instead of per-client packs
Aspen never unpacks a push. It checks the pack, completes missing bases and stores it as-is. A fetch streams stored packs the client lacks, recompressing nothing. Signed URLs can serve packs from a CDN.
Trunk-only advertisement and compaction
A push sees only the trunk branch, so negotiation stays small with a million branches. Background compaction merges packs 16 at a time, in levels like a log-structured merge tree. A client far behind gets a few dozen packs, not thousands. Depth-1 CI fetches get a tip pack built once and served to every job.
The test used one 8-core server, S3 Standard and a 4-core Postgres. The target was a copy of git.git, about 4,500 files and 75,000 commits. Aspen sustained 567 pushes per second for 5 minutes with no errors. Each push reached S3 and Postgres before Git printed “ok.”
Median push latency: 208 ms; 99th percentile: 314 ms.
Another client saw each push 30 ms after acknowledgement, at the median.
Depth-1 fetch storm: 1.029x the bytes of stock git upload-pack on git.git.
Cursor reports up to 120 pushes per second for Origin on S3 Standard. On S3 Express One Zone it exceeds 300. That is a replicated cluster on Cursor’s monorepo, so setups differ. The README calls Aspen’s figures indicative, not performance claims.
How does Aspen compare with other agent-scale Git backends?
You build from source with Rust. aspen dev runs everything with SQLite and a local directory. Teams get Docker Compose with PostgreSQL and MinIO, plus a Helm chart. Terraform covers AWS, Google Cloud, Azure and Hetzner. Mirror mode fronts GitHub or GitLab, so you can trial it without migrating.
The live demo is a 64 x 64 pixel canvas where each click is one pushed commit. Per the company, one Reason agent built Aspen from first commit to public in 4 days. That took 151 merged PRs.
Key Takeaways
Aspen is an Apache 2.0 Git server built for agent-scale push traffic.
It is an independent, open implementation of OpenAI’s Pando design.
Self-reported: 567 pushes per second on one 8-core server, p99 314 ms.
Clients need no changes; stock git works over HTTPS and SSH.
Ejecutar 128 escritores</button><button class="b" id="aspReset">Reiniciar</button></div>
<div class="race">
<div class="rc"><h4>Servidor clásico: una cola por repositorio</h4><div class="dots" id="aspD1"></div><div class="ct" id="aspC1">0 / 128 realizado</div></div>
<div class="rc"><h4>Aspen: un CAS por rama</h4><div class="dots" id="aspD2"></div><div class="ct" id="aspC2">0 / 128 realizado</div></div>
</div>
<p class="note">Modelo de juguete, no es una referencia. Ámbar = esperando, azul = realizado. Refleja la simulación ilustrativa en la publicación de lanzamiento de Reason Machines.</p>
</div>
<div class="pane" id="p-bench">
<div class="btns"><span class="sub">Pushes por segundo a un repositorio, cada uno duradero antes de la confirmación</span></div>
<div class="bar"><div class="bl"><span>Cursor Origin, S3 Standard (publicado)</span><span>120</span></div><div class="tr"><div class="fl" data-w="21.2" style="background:#6d6650"></div></div></div>
<div class="bar"><div class="bl"><span>Cursor Origin, S3 Express One Zone (publicado)</span><span>300+</span></div><div class="tr"><div class="fl" data-w="52.9" style="background:#8a8064"></div></div></div>
<div class="bar"><div class="bl"><span>Aspen, S3 Standard (autoinformado)</span><span>567</span></div><div class="tr"><div class="fl" data-w="100" style="background:linear-gradient(90deg,#3690ea,#7cb8f5)"></div></div></div><div class="grid"><div class="st"><div class="n">208 ms</div><div class="l">tiempo medio de push</div></div><div class="st"><div class="n">314 ms</div><div class="l">p99 push</div></div><div class="st"><div class="n">30 ms</div><div class="l">tiempo medio hasta que es visible</div></div><div class="st"><div class="n">~4/s</div><div class="l">aterrizajes en main</div></div><div class="st"><div class="n">1.029x</div><div class="l">bytes de profundidad 1 vs git de stock</div></div><div class="st"><div class="n">5 min</div><div class="l">sostenido, 0 errores</div></div></div>
<p class="note">Aspen: 1 servidor de 8 núcleos, S3 Standard, Postgres de 4 núcleos, git.git (~4,500 archivos, 75k confirmaciones), URL con alcance de rama. Cursor: clúster replicado en su propio monorepo. Las configuraciones difieren; OpenAI no publicó la tasa de push de Pando.</p>
</div>
<div class="pane" id="p-comp">
<div class="bl"><span>El cliente está detrás del tronco por</span><span id="aspBeh">2,000 versiones</span></div>
<input type="range" id="aspSl" min="1" max="4" step="1" value="3">
<svg viewBox="0 0 820 120" id="aspCS"></svg>
<p class="cap" id="aspCC"></p>
</div>
<div class="pane" id="p-lim">
<div class="lim">
<div class="li"><div class="t"><img src="https://s.w.org/images/core/emoji/17.0.2/72x72/26a0.png" alt="⚠" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Pre-alfa, sin lanzamientos</div><div class="d">Construir desde el código fuente. Los formatos de almacenamiento pueden cambiar. La carrera de caos de 24 horas se detuvo después de 11,59 horas limpias.</div></div>
<div class="li"><div class="t"><img src="https://s.w.org/images/core/emoji/17.0.2/72x72/26a0.png" alt="⚠" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Aterrizaje en main ~4/s</div><div class="d">Los aterrizajes separados se ejecutan uno a la vez, limitados por viajes de ida y vuelta. La tasa de cola de combinación no se mide aún.</div></div>
<div class="li"><div class="t"><img src="https://s.w.org/images/core/emoji/17.0.2/72x72/26a0.png" alt="⚠" class="wp-smiley" style="height: 1em; max-height: 1em;" /> Características de Git que faltan</div><div class="d">No hay clonaciones parciales, repositorios SHA-256, interfaz de usuario web o claves SSH RSA (solo Ed25519 y ECDSA).</div></div><div class="li"><div class="t">
Empujar con fuerza necesita -o force</div><div class="d">Debido a que un empujón solo ve el tronco, --force y --delete necesitan un -o force extra, un contrato de arrendamiento o la URL de la rama.</div></div>
<div class="li"><div class="t">