Editorial illustration for Reason Machines Open-Sources Aspen, a Git Server for AI Agent Pushes
Reason Machines Open-Sources Aspen Git Server for AI Agents
Reason Machines pushed Aspen to open source this week, a Git server built for a problem that barely existed two years ago: hundreds of AI agents hammering the same repository with commits every few minutes. The company built it as a single Rust binary, with branch history stored in PostgreSQL or SQLite and pack files sitting in S3-compatible object storage. You can run it with one command on a laptop, through Docker Compose on a single host, or deploy it across a cloud with Helm and Terraform.
The core design choice is scaling writes per branch instead of per repository, which Reason Machines says removes the queuing bottleneck that chokes traditional Git servers once dozens of clients start pushing at once. In self-reported benchmarks, Aspen sustained 567 pushes per second over five minutes on an 8-core server, though landing changes on main drops to roughly 4 per second. The project is pre-alpha: no tagged releases, no web interface, and it hasn't yet cleared a 24-hour durability test.
Reason Machines says Aspen arrived at its architecture independently, without seeing OpenAI's internal design for a similar tool called Pando.
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 this matters
Aspen is a bet that Git's old bottleneck, one queue per repo, one pack per fetch, breaks down the moment the "developer" is a swarm of agents pushing every few minutes instead of a human pushing a few times a day. Reason Machines didn't wait for OpenAI to ship Pando; they built to the published design and open-sourced it first. For teams already running agent fleets against shared repos, that's worth testing now rather than later: a single Rust binary with Postgres-backed branches and object-storage packs is cheap to spin up on a laptop before you commit to it in production.
The real signal here is architectural, not just competitive. If per-branch pushes genuinely stop blocking each other, CI pipelines built around hundreds of concurrent agent commits stop fighting their own infrastructure. We'd want to see independent benchmarks against Pando once that ships, and some scrutiny of how Aspen behaves under real agent load, not synthetic tests. But the underlying diagnosis, that server work scales with client count rather than code size, is the right question for anyone building agent-heavy dev workflows to be asking about their own Git infrastructure right now.
Related Reading
Open Source Study: 6.7% of Deepfake Requests on Hugging Face Targeted Children
Open Source D&B rebuilds 642 million‑business database after AI agents hit limits
Open Source Axiom Math raises USD 200M Series A led by Menlo to keep AI slop out of math
From Archives 0sec Labs Open-Sources 0 AI Security Harness With Account-Free Browser Console
From Archives Apple is racing to make Siri more agentic with third-party app control
Common Questions Answered
What problem does Aspen solve that traditional Git servers cannot handle?
Aspen addresses the challenge of hundreds of AI agents making commits to the same repository every few minutes, a problem that barely existed two years ago. Traditional Git servers have bottlenecks designed for human developers who push code a few times a day, not for swarms of agents pushing continuously. Aspen scales writes per branch rather than per repository, allowing it to handle this high-frequency commit pattern efficiently.
What are the deployment options available for Aspen?
Aspen can be deployed in multiple ways depending on your needs: as a single Rust binary that runs on a laptop, through Docker Compose on a single host, or across a cloud infrastructure using Helm and Terraform. This flexibility allows teams to start with a simple local setup and scale to production deployments as needed. The single binary approach makes it particularly easy to get started quickly without complex configuration.
How does Aspen store branch history and pack files?
Aspen stores branch history in either PostgreSQL or SQLite databases, depending on your deployment preference, while pack files are stored in S3-compatible object storage. This architecture separates the metadata (branch history) from the actual file data (pack files), allowing for flexible scaling and management. The use of S3-compatible storage makes it compatible with various cloud providers and self-hosted solutions.
What Git protocols does Aspen support?
Aspen speaks plain Git over both HTTPS and SSH protocols, making it compatible with standard Git clients and workflows. This ensures that existing tools and scripts that work with traditional Git servers will work seamlessly with Aspen without requiring modifications. The support for standard protocols is crucial for maintaining compatibility with AI agent frameworks and developer tools.
Why did Reason Machines open-source Aspen instead of waiting for competitors?
Reason Machines built Aspen based on published design specifications and chose to open-source it first rather than waiting for competitors like OpenAI to release similar solutions such as Pando. This proactive approach allows teams already running agent fleets against shared repositories to test and adopt Aspen immediately. By releasing early, Reason Machines positioned Aspen as the first available solution for this emerging infrastructure need.
Further Reading
- Aspen: scaling agentic commits beyond what Git was built for - Reason Machines
- Aspen: Self-hostable Git server for agent-scale traffic - TechBytes
- Coding agents: news, evidence and what practitioners say - Models at Work
- What broke while up to 30 AI agents built my coding agent, and the rule each failure produced - DEV Community
