comparison · qm alternative
QM alternative: Muster, the same scope instinct with a receipted edit trail.
QM is the closest thing to Muster that exists. Both refuse a single shared memory blob, both drive other coding backends behind one core, both are MIT. QM is further along on sharing. Muster is further along on proving what the agent actually did.
Side by side
Two projects that agree on the problem.
QM figures were read from the Y Combinator repository during the Muster strategy review on 2026-08-27. Muster publishes no star count of its own.
| Dimension | QM (Y Combinator) | Muster |
|---|---|---|
| License / first release | MIT, July 2026 | MIT |
| Scale (2026-08-27) | 14.3k stars, 185 commits | Young project, no star claim made |
| Scope model | Per-person and per-room scopes, each with its own memory, files, keychain, permissions and crons | Tenant, workspace, user, role and session memory lanes with leakage tests |
| Sharing | Skills shareable by grant, admin-gated promotion to org scope | Grants with audience, purpose, expiry and revocation — designed, not yet shipped |
| Skill distribution | Skill packs imported from git | Capability packs — 34 declared, 2 substantial |
| Backends driven | Pi, OpenCode, Codex, Claude Code behind one core | Native, Codex, Claude Code, Cursor SDK, OpenHands, Pi behind one contract |
| Isolation | Durable sandbox per scope; Postgres-backed | Local-first store; sandboxing is not Muster's differentiator |
| File-change record | Reported by the driven backend | Observed from git + filesystem, sha256 before/after |
| Audit receipts | Not a stated design goal | Deterministic receiptHash — reproducible off-machine |
| Token accounting | Provider-side | Local ledger with replay-waste flags |
The honest read
The nearest neighbour, and the one comparison where Muster is not outgunned on breadth.
Most agent-framework comparisons are Muster against something an order of magnitude larger. QM is not that. It shipped in July 2026 with 185 commits, and it arrived at several of the same conclusions Muster did, independently: that a single global memory is wrong, that scopes need to own their own files and permissions rather than share a namespace, and that the right architecture drives existing coding backends rather than writing another one.
Where QM is clearly ahead is sharing. QM skills are owned by a scope and shareable by explicit grant, with admin-gated promotion into the organisation. That is a complete answer to a question Muster has specified but not yet shipped. Muster's own strategy document is blunt about it: shared memory will not ship as a shared folder — it ships as grants carrying audience, purpose, expiry and revocation, or it does not ship. Until that lands, QM's grant model is the working implementation and Muster's is a design.
QM's durable per-scope sandbox is also a real advantage. If your requirement is that each person's or room's agent runs in its own isolated, persistent environment with its own keychain and crons, QM does that today and it is a well-chosen primitive.
Where Muster is ahead: the edit trail
QM's core drives Pi, OpenCode, Codex and Claude Code. That is the same inversion Muster makes — good architecture, and it means QM inherits the same blind spot every backend-driving harness inherits: the file-change record is whatever the driven backend reports.
Muster measured what that costs. Across five live runs against the Codex app-server protocol — three protocol probes and two full head-to-head recordings — Codex's structured file-change notification fired zero times out of five while every edit landed on disk, and both head-to-head runs recorded zero turn/diff/updated notifications as well. A harness driving Codex and trusting its patch stream would have logged an empty change set for real work, and would have had no way to notice.
Muster's workspace observer derives the change set instead of receiving it. It pins a git revision when the run starts and re-derives the full diff from git plus the filesystem each cycle, hashing every file before and after, with watch events used only as a trigger to re-derive. It is strictly read-only against your repo and its git index. In the two head-to-head runs it caught the edit in 86ms and 75ms against a 1000ms budget, with the diff verified by git apply. Two observer processes in different temporary directories, roughly forty minutes apart, produced a byte-identical receiptHash for the same logical change — which is what makes it a citable artifact rather than a local log line.
Where Muster is ahead: cost visibility and gated learning
Muster keeps a local token ledger per run, including a replay-waste flag when a run resends far more history than it needed to. On a deterministic five-scenario benchmark of 170 turns, a naive replay-everything harness sends 875.8k tokens where Muster sends 355.2k — a 59.4% reduction, reproducible with muster benchmark and with no model calls involved.
Learning is gated the same way. Feedback becomes a test fixture before it is promoted into durable behaviour, so every behavioural change carries a check that it still does what it was supposed to do.
Choose QM when
- Per-person and per-room isolation with a durable sandbox is the core requirement.
- You need skill sharing by grant, with org-level promotion, working today.
- You want Postgres-backed infrastructure and git-imported skill packs.
Choose Muster when
- The file-change record has to be derived from the workspace, not from the backend's self-report.
- You need deterministic receipts that reproduce on a machine that was not there.
- Token spend and replay waste need to be visible in your own ledger.
- Frappe or ERPNext is the system of record.
If you are evaluating both, the deciding question is narrow: does anyone downstream need to verify the agent's edits independently of the agent? If yes, that is the gap Muster closes. If no, QM's sharing and sandboxing are further along.
Compare against OpenClaw → Compare against Hermes Agent → Read the docs →