Aspen mění Git pro stovky AI agentů, na ostrá data ale nestačí

Git pro práci s mnoha agenty

Git vznikal v době, kdy do repozitáře zapisovali lidé a automatizované nástroje spouštěly hlavně testy nebo nasazení. AI coding agent pracuje jinak. Vytvoří větev, provede několik změn, odešle commit, počká na kontrolu a během několika minut pokračuje dalším pokusem. Když jich běží desítky nebo stovky současně, klasický Git server začne řešit hlavně zámky, fronty a opakované sestavování dat pro klienty.

Aspen tento problém řeší změnou způsobu ukládání historie. Historii větví ukládá do PostgreSQL, případně do SQLite při lokálním vývoji. Samotné Git pack soubory, tedy komprimované balíky objektů repozitáře, ukládá do S3-kompatibilního objektového úložiště. Server tak nemusí při každém stažení znovu skládat stejná data.

Projekt je dostupný na GitHubu pod licencí Apache 2.0. To znamená, že software lze provozovat na vlastním serveru bez licenčního poplatku. Náklady na PostgreSQL, objektové úložiště, provoz serveru a zálohování ale samozřejmě zůstávají na provozovateli.

Zápisy se zamykají po větvích

Nejdůležitější rozdíl oproti běžnému pojetí Git serveru je práce se zámky. Aspen nepoužívá jeden společný zámek pro celý repozitář. Každá větev má vlastní řetězec verzí a zápis se dokončuje operací compare-and-swap. Server ověří, že větev stále ukazuje na očekávaný commit, a potom ji posune na nový.

Pokud dva agenti zapisují do různých větví, navzájem se neblokují. Když se pokusí změnit stejnou větev, jeden zápis vyhraje a druhý dostane běžnou Git chybu vyžadující nové stažení historie. Tohle chování není magie. Aspen pouze přesouvá místo, kde vzniká konflikt, z celého repozitáře na konkrétní větev.

Výsledkem je lepší paralelismus při práci agentů na samostatných úkolech. Neplatí to ovšem stejně pro slučování změn do hlavní větve. Podle dokumentace projektu probíhá zápis do trunku postupně a v testu dosahoval přibližně 4 operací za sekundu. Číslo 567 pushů za sekundu tedy nepopisuje rychlost slučování všech změn do jedné hlavní větve.

Test s 567 pushy za sekundu

Reason Machines testovali Aspen na kopii repozitáře git.git s přibližně 4 500 soubory a 75 000 commity. Infrastrukturu tvořil jeden osmijádrový server, S3 Standard a PostgreSQL se čtyřmi jádry. Aspen po dobu pěti minut udržel 567 pushů za sekundu bez chyb. Každý push byl podle projektu před potvrzením uložený v objektovém úložišti i v PostgreSQL.

Medián latence zápisu byl 208 milisekund a hodnota p99 dosáhla 314 milisekund. Jinými slovy, 99 procent zaznamenaných pushů se vešlo do této hranice. Jde o měření zveřejněné autory projektu, nikoli o nezávislý benchmark. Aspen sám uvádí, že výsledky jsou orientační a zatím nemají sloužit jako obecný výkonnostní příslib.

Pro srovnání lze použít veřejná čísla z jiných systémů určených pro agentní provoz. Cursor u svého backendu Origin uváděl 120 pushů za sekundu při použití S3 Standard a více než 300 pushů za sekundu se S3 Express One Zone. OpenAI u interního systému Pando zveřejnilo zkrácení mediánové latence pushů téměř pětkrát a odbavení téměř jednoho petabajtu dat denně, nikoli však přímé srovnání rychlosti s Aspenem.

Podmínky testů se liší. Cursor měřil replikovaný systém na vlastním monorepu, zatímco Aspen použil jeden server a konkrétní kopii git.git. Čísla proto nelze číst jako žebříček, kde jeden produkt automaticky poráží ostatní.

Jak Aspen ukládá data

Při pushi Aspen přijatý balík ověří, doplní chybějící základní objekty a uloží jej jako samostatný pack do objektového úložiště. Při následném fetchi vybírá balíky, které klient potřebuje, a může je poslat přímo nebo přes URL určené pro CDN. Server tak nemusí pro každého klienta znovu provádět stejnou kompresi.

Menší balíky se následně slučují na pozadí. Dokumentace tento postup přirovnává k log-structured merge tree, což je způsob organizace dat známý z databází. Smyslem je, aby klient, který je několik tisíc změn pozadu, nestahoval tisíce malých balíků.

Aspen také pracuje s tím, že push standardně vidí pouze hlavní větev. Díky tomu nemusí při každém zápisu procházet seznam milionů dalších větví. Cena za tuto volbu je odlišný model konzistence. Čtenář může při práci s více větvemi vidět jejich stav z mírně odlišných okamžiků.

Nasazení v Česku a Evropské unii

Aspen nemá vlastní cloudovou službu ani placený tarif. Projekt se sestavuje ze zdrojového kódu v Rustu. Pro lokální zkoušení slouží příkaz aspen dev, který spustí server s SQLite a lokálním adresářem. Pro týmové nasazení jsou připravené Docker Compose, Helm chart a Terraform moduly pro AWS, Google Cloud, Azure a Hetzner.

Podpora běžných Git klientů probíhá přes HTTPS a SSH, takže vývojáři nemusí instalovat upravenou verzi Gitu. Aspen lze také nasadit v režimu mirror před existující repozitáře na GitHubu nebo GitLabu. To dovoluje testování bez okamžité migrace celého projektu.

Pro české a evropské týmy je důležité, že software lze provozovat ve vlastní infrastruktuře nebo v regionu vybraného cloudového poskytovatele. Aspen sám neposkytuje českou lokalizaci ani evropský hosting. Dostupnost v Česku tedy závisí na tom, kde si jej tým nasadí a jak nastaví přístup, zálohy a ochranu dat.

Pre-alpha má konkrétní omezení

Největší problém není licence ani základní kompatibilita s Gitem. Je to stav projektu. Aspen je stále ve fázi pre-alpha a zatím nemá zveřejněné žádné hotové release balíčky, takže se musí sestavovat ze zdrojového kódu. Chybí také webové rozhraní.

Projekt navíc zatím nesplnil 24hodinový test odolnosti (durability gate). U Git serveru je přitom dlouhodobá spolehlivost zásadní vlastností, bez které nelze software bezpečně nasadit na kritická produkční data.

Uváděné výkonnostní benchmarky jsou navíc self-reported výsledky z interního testu na jediném serveru. Sami autoři v README na GitHubu výslovně upozorňují, že tato čísla jsou orientační, nikoli garantovaný výkonnostní závazek.

Projekt vytvořený autonomním agentem

Aspen má ještě jednu zajímavou vlastnost. Podle Reason Machines jej vlastní autonomní agent naprogramoval od prvního commitu po veřejné vydání za čtyři dny. Projekt uvádí 151 sloučených pull requestů. Neznamená to, že agent pracoval bez kontroly. Z veřejné dokumentace vyplývá, že změny byly organizované do samostatných úkolů a následně procházely kontrolou a slučováním.

Právě zde se kruh uzavírá. AI agenti vytvářejí více změn, než na jaké byly klasické týmové workflow původně stavěné. Aspen je současně software, který má takový provoz obsloužit, a projekt vytvořený stejným typem automatizace. Na praktické nasazení do produkce je zatím brzy. K 9. listopadu 2026 jde o otevřený technický experiment s použitelnou architekturou, měřitelnými výsledky a dlouhým seznamem věcí, které ještě čekají na ověření.

FAQ

Zdrojové informace a oznámení, zdrojový kód Aspen, technický popis od Reason Machines a popis systému Pando od OpenAI.