Verified answers before you evaluate

No. MUON is the governed operating layer around the coding-agent CLIs your team already uses. It plans and routes bounded work, supplies relevant context, monitors execution, records evidence, and holds consequential decisions for review.

Claude Code and Codex are the dispatch-ready implementation lanes. Cursor is a managed read-only lane for scout, reviewer, QA, and architect roles. OpenCode is a managed scout-only lane. Optional loopback Ollama can assist local memory embeddings; it is never a coding worker.

MUON dispatches Cursor under deny-first permissions as a managed read-only lane. It can scout and review; it is not an implementer seat and does not receive write authority through MUON.

MUON does not count provider-native subagents as part of the governed crew. Child workers are created through MUON so lineage, scope, budgets, workspace containment, cancellation, and authority limits remain visible and enforceable.

The Desktop app is free for individual use. Team pricing is available through the enterprise contact form. Your provider subscriptions and model usage remain separate.

Ollama is not a coding lane. When a local loopback Ollama instance is available, MUON may use it only for optional memory embeddings. When it is absent or fails, MUON continues with built-in lexical recall. OpenCode replaced Ollama as the fourth managed agent lane.

OpenCode is a managed scout-only lane. MUON runs it under a deny-first permission table and can inject the governed MUON brain through MCP. It is not an implementer, coordinator, or QA seat.

Yes. Each agent can retain memory for its own work, and MUON also maintains a unified crew memory so agents can understand what others are working on. That shared awareness is what removes the need for a human to orchestrate context between tools. Confirmed, in-scope context is what gets reused.

MUON keeps engineering state local by default in the user's MUON data directory. Confirmed history, approvals, and activity remain available for inspection without requiring a cloud control plane for the core workflow.

No. Provider readiness uses the installed CLI's own read-only status command or selected environment evidence. MUON is designed not to return, log, or persist provider tokens during readiness checks.

No. Merge and ship remain always-ask actions. Review is tied to the exact worktree artifact and current evidence, and stale or unavailable certification fails closed.

No. The current product is a private beta. Automated suites, packaged smokes, and local runtime paths are documented, while public distribution, signing, and final visual or virgin-machine gates remain explicit founder-owned work.