Mega

Mega's pitch is narrow and clear: it is an open implementation of the Piper model — a monorepo engine — retargeted at AI agents. Piper is the system Google built because Git could not carry its monorepo, and Mega borrows that framing while adding the piece Piper never had: vector representations produced natively for every commit, queryable semantically through the CLI. That combination is the reason to care. A conventional Git server gives an agent a working tree and diffs; Mega also gives it a semantic index it can query, which is a different substrate for agent context. On strengths: the FUSE virtual file system is the practical unlock. When files load on demand, a million-file repository opens in milliseconds rather than requiring a clone, which matters both for CI containers and for agents that only need a slice of the tree. The distributed design matters because it spreads graph state across a connected mesh network and, per the project, eliminates the single point of failure. Rust as the implementation language is a reasonable signal for a systems tool where latency and memory behavior are the product. Git compatibility means you are not asking your team to relearn version control, and Docker Compose makes a demo cheap to stand up. On weaknesses: the homepage is written primarily in Chinese and functions more as a documentation shell than a product page — the "core capabilities" block is four items (distributed, Git-compatible, virtual file system, agent-oriented) and the counters for stars, forks and versions render as empty placeholders in the fetched page. There is no visible managed hosting, no commercial support tier described on the page, and no release history surfaced in what we could reach. That means a team adopting Mega owns the operational burden of a distributed monorepo engine themselves. Committing to it is a platform-engineering project, not a procurement decision. Where it fits: organizations that already think in monorepos and are now building agent infrastructure on top of them, especially teams whose repos have crossed into the hundreds of thousands or millions of files. Where it does not: small projects, teams that deliberately run multi-repo, and anyone who needs a support contract attached to their version control layer. If your real need is code intelligence over ordinary Git rather than a new engine, look at Sourcegraph; if your problem is large binaries specifically, Git LFS addresses that without replacing the engine.