Reason Machines lançou o Aspen, um servidor Git de código aberto para tráfego de agentes de IA. Ele foi projetado para repositórios que recebem centenas de pushs simultâneos. O Aspen implementa de forma independente o design descrito pela OpenAI para o Pando.
TL;DR
- Tamanho: Um único binário em Rust. Branches ficam no PostgreSQL (ou SQLite), pacotes ficam em armazenamento de objetos.
- Funciona em: um laptop (aspen dev), um host via Docker Compose, ou Helm e Terraform em nuvem.
- Desempenho: pushes para branches diferentes nunca esperam uns pelos outros, e fetches reutilizam pacotes armazenados.
- Melhor: 567 pushes por segundo sustentados por 5 minutos em um servidor de 8 núcleos (autorreportado).
- Pior: landing no main gira em torno de 4 por segundo, e o projeto está em pré‑alpha.
Resumo: Melhor – gravações por branch removem o teto de pushes por repositório. Pior – sem releases, sem UI web, e a barreira de durabilidade de 24h não é atingida.
O que é o Aspen?
Aspen é um servidor Git auto‑hospedável da Reason Machines que escala gravações por branch, não por repositório. Ele fala Git puro sobre HTTPS e SSH. Pacotes vão para armazenamento de objetos compatível com S3; histórico de branches vai para PostgreSQL.
Por que servidores Git clássicos têm dificuldade com agentes de IA?
Um agente faz push a cada poucos minutos, e CI faz fetch após cada push. De acordo com a Reason Machines, um servidor clássico enfileira todos os pushes para um repositório juntos e também cria um novo pacote para cada fetch. O trabalho do servidor cresce com os clientes, não com o novo código. A OpenAI atingiu essa barreira e construiu o Pando, que reduziu a latência de push mediana quase 5× e serve quase um petabyte por dia.
Como o Aspen funciona?
O Aspen segue o Pando e abandona duas reivindicações que a maioria dos servidores Git mantém.
- Comparação‑e‑troca por branch
Cada branch é uma cadeia de versões em uma única linha do PostgreSQL. Um push faz upload do seu pacote e então move o branch com uma única operação de compare‑and‑swap. Pushes para branches diferentes nunca esperam uns pelos outros. Se dois pushes competirem por um branch, um vence; o outro recebe o erro típico do Git “fetch first”.
- O custo: os branches podem ser lidos em momentos ligeiramente diferentes.
- Pacotes armazenados em vez de pacotes por cliente
Aspen
Fonte: MarkTechPost
Publicado em 2026-11-09