Murmell vs Codeg
Codeg calls itself a multi-agent coding workspace, and its first job is collection: it reads the sessions your agents have already written on your own machine and puts them in one place. Murmell does not collect sessions. It starts them, on machines we run, in one shared project directory.
The real difference
Codeg brings many agents into one unified workspace and supports conversation aggregation, importing sessions from every agent it knows about by scanning their default local data directories. Inside a single session the main agent can delegate to sub-agents of a different kind, so Claude Code can call Codex, and parallel work uses built-in git worktree flows.
So the parallelism is still a worktree each, and the history is still whatever ran on your computer. Murmell is the other arrangement. The agents run on cloud machines, share one checkout, and ask before they write: an agent claims the paths it is about to touch, the board keeps one holder per path and refuses everyone else until the holder releases it, and a colliding write is snapshotted before it lands. The rule is enforced by the server rather than suggested to the model.
And a Murmell canvas has other people in it. Send a read link and they see the windows, the terminal contents and a named cursor each, live, while it happens. Close your tab and the agents keep working.
Where Codeg wins
Your existing history. If you have months of Claude Code and Codex transcripts sitting in local directories, Codeg is the tool that goes and gets them, and nothing about Murmell reaches back into work that ran somewhere else.
It covers far more agents than Murmell launches today, it is Apache-2.0 so you can read and change it, and it installs as a desktop app or as a server of your own under Docker. Murmell is not open source and cannot be self-hosted.
Which to pick
Pick Codeg when the agents already run on your machine and the problem is that their work is scattered across a dozen places.
Pick Murmell when the problem is that two agents cannot safely edit the same file, or that nobody else can see the run. Every project gets a private repository, pushed to as the work goes and once more before a machine is torn down, and the machine executing agent code holds no database and no decryption key. See how several agents work in one repository.
Side by side
| Codeg | Murmell | |
|---|---|---|
| Where a second agent works | On your own machine, in the sessions you already run there | One shared directory, after it claims the paths it is about to touch |
| Who can watch it happen | You, in the workspace it gathers those sessions into | Anybody with the link, live, with a name on every cursor |
| Where the work lands | Your local checkout, and whatever you push from it | A private repository for the project, pushed as the agents go |
Straight answers
What is the difference between Codeg and Murmell?
Codeg collects the agent sessions that already ran on your own machine and brings them into one workspace. Murmell starts the sessions instead, on machines it runs, with every agent in one shared project directory.
Which should I pick, Codeg or Murmell?
Pick Codeg when the agents already run on your machine and the problem is that their work is scattered across a dozen places. Pick Murmell when you want several agents working in one directory at once, with other people watching the same canvas.