Aspen: servidor Git open source para agentes processa 567 pushes por segundo

Se voce ja executou varios agentes de programacao no mesmo repositorio, conhece bem o problema: eles fazem push com frequencia, em paralelo e sem qualquer disciplina. Os servidores Git convencionais foram projetados para pessoas que fazem commits algumas vezes por hora. Os agentes, por sua vez, podem fazer isso dezenas de vezes por minuto cada um, transformando o servidor em um gargalo. A startup Reason Machines (YC F26) propoe uma solucao: o Aspen, um servidor Git open source desenvolvido especificamente para esse tipo de carga.

O que esta sendo anunciado

Os autores destacam um numero principal: uma unica maquina de 8 nucleos suporta 567 pushes por segundo no mesmo repositorio. A segunda parte da afirmacao tambem e importante: cada push e salvo antes de o git exibir "ok". Em outras palavras, a velocidade nao foi obtida em detrimento da confiabilidade: se o cliente recebeu a confirmacao, os dados ja foram gravados.

O terceiro ponto talvez seja o mais pratico: o cliente continua sendo o git padrao. Nao e preciso instalar nada — nenhum plugin proprietario, SDK separado ou protocolo personalizado. O agente continua executando git push, apenas para outro endereco.

Por que isso e importante especificamente para agentes

Imagine uma arquitetura tipica de agentes: um orquestrador inicia 50 workers em paralelo; cada um assume uma tarefa, altera o codigo e faz push de uma branch ou de um estado intermediario. As pessoas quase nao participam desse fluxo, enquanto o Git funciona como registro e ponto de sincronizacao. A concorrencia pelo mesmo repositorio envolve bloqueios para atualizar referencias, gravar objetos e executar verificacoes de integridade. Em grandes volumes, tudo isso se transforma em um teto de throughput.

Por enquanto, temos apenas uma afirmacao publicada em um post, mas a direcao esta clara: o Git usado como memoria de trabalho dos agentes exige uma arquitetura de servidor diferente daquela usada pelo Git como ferramenta de desenvolvimento colaborativo.

Limitacoes e ressalvas

Por enquanto, essencialmente temos apenas um post no X com uma unica metrica. Nao se sabe exatamente como o teste foi configurado: o tamanho dos pushes, os discos utilizados, o numero de clientes simultaneos ou se havia conflitos entre pushes para as mesmas branches. Alcancar 567 pushes por segundo com commits vazios ou minimos e muito diferente de obter o mesmo numero com alteracoes reais em um monorepositorio. Tambem nao esta claro como o Aspen lida com hooks, permissoes de acesso, code review e as integracoes com as quais usuarios do GitHub e do GitLab estao acostumados. O projeto e jovem, e ainda e cedo para esperar maturidade de produto.

O que fazer na pratica

Se voce esta desenvolvendo um sistema multiagente e o Git se tornou um gargalo, vale a pena reservar uma noite para colocar o Aspen em funcionamento, executar sua carga real e compara-lo com o servidor atual. Nao observe apenas o pico de desempenho: meca a latencia dos pushes com o seu perfil de carga, o comportamento em conflitos e a recuperacao depois de uma falha. Se voce desenvolve uma plataforma de agentes, preste atencao a tendencia mais ampla: a infraestrutura ao redor dos agentes esta comecando a ser reescrita de acordo com seus padroes de uso, e a hospedagem Git para maquinas provavelmente se tornara um nicho independente.

Como o cliente continua sendo padrao, o custo do experimento e baixo: mudar o remote leva um minuto, e reverter a alteracao e igualmente rapido.