MassGen's two dependency files disagree, and one badge points at another account
🚀 MassGen is an open-source multi-agent scaling system that runs in your terminal, autonomously orchestrating frontier models and agents to collaborate, reason, and produce high-quality results. | Join us on Discord: discord.massgen.ai
At a glance
- What is it?
- MassGen is a multi-agent framework that runs frontier agents on the same problem until they vote. Its header badge links to a different GitHub account than the repository it lives in, its requirements file and its package metadata require different versions of the same SDK and list different packages entirely, and the Textual interface it ships as the default is missing from the metadata.
- Who is it for?
- MassGen fits a team that wants to compare several frontier models on the same task rather than pick one up front, and that is willing to install a broad set of provider SDKs to do it. It is a poor fit if you need to know exactly which dependencies you are pulling, because the two manifests in the repository do not agree, and it is a poor fit if you want the permission defaults to be tight without reading them.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 113 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 3, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The header badge links to a different GitHub account
The badge row under the logo links to the PyPI project, the documentation site, the Python download page, a licence file, and one GitHub repository. That repository is not the one you are reading.
The link points at an account named Leezekun, while the repository itself lives under the massgen organisation. So the project's own front page sends readers to a personal repository rather than to the canonical one, and the search results reflect it: one of the phrases people type for this project is the personal account name rather than the project name.
The other outbound links are consistent. The documentation is at docs.massgen.ai, the contributor handbook is hosted separately at a GitHub Pages address, and there are Discord, LinkedIn and X links alongside it.
There is a second distribution channel as well, which is worth separating from the Python package. A skills repository exists under the same organisation, installed with `npx skills add massgen/skills --all`, and the README says that after that you invoke the skill in Claude Code, Cursor, Copilot, or 40 or more other agents.
So there are two ways in, a Python package and an agent skill, and the header of the Python package's repository points at neither of the two correct GitHub locations.
The two dependency files disagree about the same SDK
This repository carries a package manifest and a requirements file, and they are not the same list.
The package metadata is the stricter of the two on one dependency and the looser on others. It declares the agent SDK with both bounds:
"anthropic>=0.61.0",
"claude-agent-sdk>=0.1.44,<0.1.49",The requirements file declares the same package with a much lower floor and no ceiling:
claude-agent-sdk>=0.0.22So installing from one file admits SDK versions the other file forbids. The gap runs from the 0.0 series up to 0.1.44, which is more than twenty releases of a package whose API carries no stability promise across that range.
The difference is not limited to versions. The package metadata declares dependencies that the requirements file does not mention at all, including an audio SDK, two agent frameworks, a cloud AI platform client, an interactive prompt library and the pytest runner. The requirements file declares packages the metadata does not list, among them a terminal UI toolkit, a websocket client, an audio editor library and a prompt-optimisation library.
Which file you install from therefore determines which agents work. That is the single most consequential thing to check before installing this project.
textual ships as the default interface and is not in the metadata
The feature table names the default display: an interactive terminal UI with a timeline, agent cards and vote tracking, with a web UI and a Rich-based display offered as alternatives.
The terminal UI toolkit is `textual`, and it appears in the requirements file at a floor of 0.47.0. It is not in the package metadata's dependency list.
That is the same divergence as the previous section seen from the other side, and it has a concrete effect: the documented default interface depends on a package the distribution does not declare. A fresh install of the published package may therefore arrive without the library its default renderer needs, while a developer who followed the requirements file gets it.
The package metadata also carries tooling that is not runtime. The pytest runner and two Sphinx themes appear among its dependencies, alongside the providers. So the install list mixes provider SDKs, a test runner and documentation themes in one array, and the requirements file takes the opposite approach by segregating its own documentation block under a comment.
The classification is Beta, the Python floor is 3.11, and the version field is dynamic rather than written down, with the three most recent tags being v0.1.95, v0.1.96 and v0.1.97 in four days.
The permission engine ships an allow-all policy
The newest release is the interesting one, and it is a response to the obvious failure mode of an agent that runs shell commands on your machine.
The application-layer permission engine is opt-in through a `permissions:` block. Every tool call passes through a non-overridable floor that blocks whole categories of destructive command outright, then declarative allow, ask and deny rules over a small algebra of an action and a target, where deny wins over everything else. On top of that sits a blast-radius risk classifier which is described as auto-allowing reads and edits inside the workspace, and asking only about the dangerous tail: egress, force-push, publishing, and privilege.
The approval mechanism has three named policies, `risk-based`, `deny-all` and `allow-all`, and a separate file request and response path for headless or remote approval, with a Slack bot and an approve command given as examples. The design is described as fail-closed.
Two things to check rather than assume. The presence of an `allow-all` policy in the same block as the classifier is the thing to notice, because the classification logic is worthless if the policy short-circuits it. And the engine is opt-in, so a run with no `permissions:` block has none of these controls, whatever the classifier would have decided.
A feature marked NEW in v0.0.21 is still labelled NEW
The quick start section of the table of contents lists five ways to run the system: single agent, multi-agent collaboration, Model Context Protocol, file system operations, and project integration.
The fifth carries the parenthetical that it is new in v0.0.21.
The project is at v0.1.97. Counting patch increments from 0.0.21 to 0.1.97 puts that feature roughly seventy-six releases back, and the same table of contents separately advertises a features section for v0.1.96 and a recent achievements section for v0.1.97.
So the document is current in some places and frozen in others, which is a fair description of a README that has been extended rather than rewritten. The effects compound: a reader who works from the table of contents is pointed at an old quick-start section for a feature that has had a year of releases to change.
There is a separate road map file per release at the repository root, one for the current line and one for the next, so the planning information is versioned more carefully than the README is.
Three release artefacts are also committed as dated files at the root, alongside a release automation summary, two draft pull request descriptions, an openspec directory and a specs directory.
PyPI shows a different readme than GitHub does
The package metadata sets its long description to a file called `README_PYPI.md` with Markdown content type, and that file is not the one on the repository's front page.
So the README a person reads on GitHub and the description a person reads on the package index are two different documents, maintained separately, with no stated relationship between them.
This is a common pattern for packages that want a shorter description on an index, and it is also a way for the two to drift without anybody noticing, because a diff of the front page does not show you what the index says.
The rest of the metadata is conventional. The version is dynamic rather than literal, the licence is declared as text rather than as a file reference, the author is a team with a contact address, and the classifiers claim Beta status, two intended audiences, OS independence, Python 3.11, and topics in artificial intelligence and Python modules.
The repository metadata reports no recognised licence identifier at all, while the manifest declares Apache-2.0 and a licence file sits at the root. Two sources agree and one is silent, so the licence is not in doubt, but the empty field is what a package index will show.
Every agent solves the whole problem, then they vote
The architectural choice is worth stating plainly because it is not the usual one.
Rather than decomposing a task and assigning pieces, MassGen has every agent tackle the full problem. They observe each other's work, critique it, and build on it, across cycles of refinement and restarts. When the agents judge that there is a strong enough answer, they vote, and the best collectively validated answer wins.
That is redundancy rather than division of labour, and it has an obvious cost profile: you are paying for N agents to do the work of one, and the token cost scales with the agent count rather than with the task decomposition. What you buy is a cross-check that does not depend on any single agent's first answer being right.
The system design section names the supporting pieces as parallel processing, real-time collaboration, convergence detection and adaptive coordination. Convergence detection is the load-bearing one, since a redundancy design needs a stopping condition and the vote is described as what supplies it.
The project's lineage is stated too. It started from the threads-of-thought and iterative-refinement ideas in AG2's reasoning write-up, extends the classic multi-agent conversation idea from the same project, and was presented at the Berkeley Agentic AI Summit in 2025.
Editorial conclusion
MassGen fits a team that wants to compare several frontier models on the same task rather than pick one up front, and that is willing to install a broad set of provider SDKs to do it. It is a poor fit if you need to know exactly which dependencies you are pulling, because the two manifests in the repository do not agree, and it is a poor fit if you want the permission defaults to be tight without reading them. Before you adopt it, settle three things. Decide which manifest you install from, since the requirements file allows a lower SDK floor than the package metadata and omits several agents the metadata declares. Read the permission policies before enabling automation, because the same engine that auto-allows in-workspace edits also ships an allow-all policy. And confirm your Python is 3.11 or newer. The last push to main was on 2026-06-12 and the newest release is v0.1.97, classified as Beta.
Frequently asked questions
Is MassGen related to Mass General?
No. MassGen is a multi-agent framework that coordinates AI agents from a terminal, and its documentation is at docs.massgen.ai with the repository under the massgen organisation. Search results carrying that name are about a hospital and have nothing to do with this project.
How does MassGen pick the answer it returns?
Every agent works the full problem, observing and critiquing each other's output across cycles of refinement and restarts. When the agents judge there is a strong enough answer they vote, and the best collectively validated answer wins, with convergence detection named as the supporting mechanism.
What does the MassGen permission engine do?
An opt-in `permissions:` block routes every tool call through a non-overridable floor that blocks destructive command categories, declarative allow, ask and deny rules over an action and target algebra where deny wins, and a blast-radius classifier that auto-allows reads and in-workspace edits while asking about egress, force-push, publish and privilege. Approvals resolve through a risk-based, deny-all or allow-all policy, or a file handshake for headless runs.
Which Python version and dependencies does MassGen need?
Python 3.11 or newer. The package metadata pins some dependencies exactly, including datasets 3.2.0, openai 2.2.0, rich 14.1.0, the xAI SDK, the Cerebras SDK and the LM Studio client, and ranges others. It also lists pytest and two Sphinx themes among its runtime dependencies.
Can I use MassGen without installing the Python package?
There is a skills distribution under the massgen organisation, installed with `npx skills add massgen/skills --all`, and the README says it then works in Claude Code, Cursor, Copilot and 40 or more other agents. The Python package is published on PyPI as massgen, and contributor policies live in a separate handbook.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/massgen-massgen)