Reason Machines 开源面向 AI Agent 的 Git 服务器 Aspen
Reason Machines 开源 Git 服务器 Aspen，采用 Apache 2.0 许可，面向数百个 Agent 同时推送的仓库流量，独立实现了 OpenAI 描述的 Pando 设计。
MarkTechPost· Asif Razzaq·2026-11-09 16:20· 3 小时前AI 评分60
Reason Machines Open-Sources Aspen, a Git Server Built for AI Agents
AI 导读
Reason Machines 发布开源 Git 服务器 Aspen，面向数百个 Agent 同时推送的仓库流量，独立实现了 OpenAI 描述的 Pando 设计，采用 Apache 2.0 许可。
正文 · 原文
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
mainruns 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.
How fast is Aspen?
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-packon 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?
| Feature | Aspen | Cursor Origin | OpenAI Pando | GitHub Spokes |
|---|---|---|---|---|
| Availability | Open source, self-hosted | Commercial Cursor platform | Internal to OpenAI | Internal to GitHub |
| License | Apache 2.0 | Not disclosed | Not disclosed | Not disclosed |
| Push ordering | Per branch (compare-and-swap) | Per repository (write-ahead log in S3) | Per branch | Three-phase commit across replicas |
| Ref storage | PostgreSQL or SQLite | WAL index in S3, no relational DB | Metadata store | Git repos on NVMe |
| Fetch serving | Stored packs, stitched or via URIs | Local Git repo cache on NVMe | Reused stored packs | Git repo replicas |
| Published push rate | 567/s, S3 Standard, 1 server (self-reported) | 120/s S3 Standard; 300+/s S3 Express | Not disclosed | Not disclosed |
| Other published result | p99 push 314 ms | Linear read scaling to 100 replicas | Median push latency cut nearly 5x | Not disclosed |
How do you deploy Aspen?
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
gitworks over HTTPS and SSH.
Check out the GitHub repo and the launch post. Also, feel free to follow us on Twitter and don’t forget to join our 150k+ML SubReddit and Subscribe to our Newsletter. Wait! are you on telegram? now you can join us on telegram as well.
Need to partner with us for promoting your GitHub Repo OR Hugging Face Page OR Product Release OR Webinar etc.? Connect with us
The post Reason Machines Open-Sources Aspen, a Git Server Built for AI Agents appeared first on MarkTechPost.
来源：MarkTechPost · marktechpost.com
来源：RadarAI · aihot.news