hyperspaceai/agi: a P2P agent network where the README is written by the agents
The first distributed AGI system. Thousands of autonomous AI agents collaboratively train models, share experiments via P2P gossip, and push breakthroughs here. Fully peer-to-peer. Join from your browser or CLI.
At a glance
- What is it?
- Hyperspace's agi repository documents a libp2p network of autonomous research agents that gossip results, run DiLoCo training rounds across consumer machines, and publish hourly CRDT leaderboard snapshots. The mechanism is specific and the claims are large; here is what the material actually supports.
- Who is it for?
- Adopt this if you want to observe or participate in a live P2P agent experiment and you are comfortable that the repository's central claims (the 32-node training run, the 195x compression figure, the 695+ agent economy) come from the project's own README and snapshots rather than an independent reproduction. Do not adopt it if you need a training framework with reproducible baselines or a chain with an external security review.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What problem the agi repository claims to solve
The stated problem is coordination. A single researcher running experiments on one machine is bounded by that machine's GPU, and sharing results means either a central server or manual exchange. The README describes a network where each node runs experiments, gossips findings to peers, and pushes results into this repository, so the artifact you are reading is the aggregate output rather than a hand-written paper. The audience is narrow: people who already have a GPU or a spare VM and want to contribute compute to an open research loop, plus engineers who want to query a live leaderboard programmatically. The homepage points at agents.hyper.space for browser participation, and the CLI is the full path with background daemon and auto-start. If you are looking for a library to call from your own training code, this is the wrong shape of project. It is an operated network with a client, not a framework you embed.
How a Pod turns scattered machines into one cluster
A Pod is the smallest unit of organization described. Someone runs hyperspace pod create "my-lab", then hyperspace pod invite to produce a shareable link, and other machines join to form a mesh. Two mechanisms sit on top of that mesh. Distributed inference routes a query to whichever member has the best model loaded, and the README names Qwen 3.5 32B, GLM-5 Turbo, and any GGUF model as candidates. Shared providers let members pool OpenRouter, Groq, or Together keys with per-member budgets, which is a practical answer to the question of who pays for API calls in a shared cluster. Pod Capsule exports the whole pod state (vault, providers, settings) as a .tar.gz with AES-256-GCM encryption, and the README says it can be self-hosted with docker compose up. That encryption detail matters more than it looks: a capsule contains provider keys, so the export is a credential archive, and losing the passphrase means losing the pod configuration along with it.
DiLoCo, SparseLoCo and Parcae: the actual training compression stack
The training design follows DiLoCo: each node trains locally for a while, then shares compressed weight deltas rather than raw gradients. Three layers of compression stack on top. SparseLoCo applies top-k sparsity to LoRA deltas and is credited with 45x compression over raw. Parcae gradient pooling groups nearby transformer layers into blocks of six and averages gradients within each block, adding 6x on top. The README states the combined figure as 195x, taking a round from 5.5 MB to 28 KB. Adaptive inner steps is the scheduling piece: a node benchmarks its own hardware and computes how many steps fit a 25-minute training budget, so a fast GPU node might do over 100 steps while a slow CPU node does 5 to 10. That is the honest part of the design. Heterogeneous consumer hardware cannot run lockstep synchronous SGD, so the system equalizes wall-clock time per round instead of work per round. The trade-off is that a CPU node contributes a much smaller delta per round, and the README does not describe how those unequal contributions are weighted when deltas are merged.
Getting it running: install, train, and chain roles
The install path in the README is a single curl piped to bash: curl -fsSL https://agents.hyper.space/api/install | bash. From there, hyperspace train joins the next networked round, and hyperspace train --solo runs locally on your own data, which is the command worth trying first because it exercises the Python sidecar and dependency installation without depending on other peers being online. For chain participation, the README shows hyperspace start --chain-role fullnode after the same installer, with chain ID 808080 and Mysticeti consensus implemented as an uncertified DAG via Rust FFI. Agents that want to consume the network rather than contribute to it get an OpenAI-compatible endpoint at http://localhost:8080/v1 with /chat/completions, /models, and /embeddings, plus a skill file at agents.hyper.space/skill.md. The CLI version cited in the README is v5.20.0. Note the two different install URLs in the material: download.hyper.space for the chain command block and agents.hyper.space for the join block. Whether they resolve to the same artifact is not stated, and you should check before piping either into a shell.
The snapshot format is the most inspectable part of the project
Every hour a node writes the network research state to the network-snapshots branch, with snapshots/latest.json always pointing at the newest and timestamped files archived alongside. The documented schema is version 2 and includes a timestamp, the generating peer ID, a summary string, leaderboards across machineLearning, searchEngine, finance, skills, and causes, plus experimentCounts. One field in the example is worth quoting directly because it sets the tone for how the project wants to be read: the disclaimer says "Raw CRDT leaderboard state. No statistical significance testing. Interpret the numbers yourself." That is an unusually candid line, and it should govern how you use the file. A globalBest entry in machineLearning is a claim from one agent's run, not a replicated result. The experimentCounts in the example show 1369 ML runs against 13 search runs and 0 finance runs, which tells you the five-domain structure is aspirational in some branches rather than evenly populated. Pointing an LLM at latest.json and asking for analysis is a legitimate use; treating the output as a benchmark comparison is not.
Where the design breaks down or the tool is simply wrong
The 195x compression figure is a ratio, not a quality result. Compressing a LoRA delta from 5.5 MB to 28 KB with top-k sparsity and block averaging discards information, and the README does not report what that discarding costs in final model quality relative to an uncompressed DiLoCo round. Without that number, the compression stack is a bandwidth optimization of unknown fidelity. The 32-node training run is described as 24 hours across consumer laptops, small VMs, and a home-office workstation, with no trusted infrastructure, but there is no mention of how many of those nodes stayed online for the full run or how stragglers were handled when a node dropped mid-round. The autonomous worker retries with exponential backoff and survives CLI restarts, which covers the client side, but the round-level failure mode is not documented. On the blockchain side, Mysticeti is Sui's consensus and the recent releases are three consecutive patches on 2026-04-29, all titled "Mysticeti force-commit-at-frontier fix", which suggests a consensus edge case that took more than one attempt to close. If your workload needs deterministic, reproducible training results, this network is the wrong tool. Use it to contribute compute or to watch an experiment, not to produce a paper's headline number.
How this differs from Petals and from running your own cluster
Petals is the closest comparison in the distributed-inference space: it splits one large model across peers so a group can serve a model none of them could host alone, with a central coordinator for the swarm. Hyperspace inverts that. Each Pod member hosts a complete model, and the router picks whichever member already has the best one loaded, so inference is a routing problem rather than a sharding problem. The trade-off is capacity: Petals can serve a model larger than any single peer, while a Pod is capped by its largest member's GPU. On the training side, the comparison is to a conventional multi-GPU job with NCCL or to a managed cluster. Both assume homogeneous hardware and reliable interconnect; DiLoCo with adaptive inner steps explicitly assumes neither, which is why it tolerates a CPU node doing 5 steps next to a GPU node doing 100. If your machines are homogeneous and on one network, a normal distributed job will be simpler and better understood. The P2P layer earns its complexity only when the nodes are not yours and are not equal.
Maintenance cost, licence, and what to check before committing
The repository is MIT licensed, which permits commercial use and modification, but the licence covers the code in this repository and not the models the network serves. Qwen, GLM, and GGUF model files carry their own licences, and the README does not address that distinction, so check the licence of any specific model before shipping its output. The maintenance picture is active rather than settled: the README cites CLI v5.20.0, the chain releases are at v1.7.8 after 54 shipped versions, and the snapshot schema is at version 2, which means both the client and the snapshot format have changed enough to warrant versioning. If you build tooling against latest.json, pin to the version field and expect schema drift. The repository is not archived and the last push is recent. The concrete first step is to run the installer, then hyperspace train --solo against a small dataset you already have a baseline for, and compare the resulting loss curve to the same model trained locally without the DiLoCo wrapper. That single comparison tells you whether the compression stack is preserving the signal you care about, which is the one number the README does not give you.
Editorial conclusion
Adopt this if you want to observe or participate in a live P2P agent experiment and you are comfortable that the repository's central claims (the 32-node training run, the 195x compression figure, the 695+ agent economy) come from the project's own README and snapshots rather than an independent reproduction. Do not adopt it if you need a training framework with reproducible baselines or a chain with an external security review. Verify first: install the CLI, run hyperspace train --solo on your own data, and diff the output against a local PyTorch or JAX run of the same model before trusting a networked round.
Community notes