Murmell puts Claude Code, Codex, and peers on one cloud canvas

Murmell is a browser canvas for running several command-line coding agents on machines the company operates, all against one project directory instead of a worktree per agent. The pitch on murmell.com is blunt: infinite agents, infinite peers, one canvas.

The product puts Claude Code, Codex, Kimi, and OpenCode in their own terminal windows on a shared cloud machine. People on the same link see the same terminals, cursors, and live previews while the work is happening. Coordination is not a merge after the fact. An agent claims a file before it writes; other agents wait; the company says the work is pushed to git before a machine is torn down.

These claims come from Murmell’s own site. There is no independent recap in the material used for this piece.

One directory, not four clones

The homepage frames three failure modes it wants to replace. Two agents overwrite the same file because nothing mediates access. An agent dies when a laptop sleeps. Teams clone the repo several ways and spend a Friday merging conflict markers.

Murmell’s answer is one directory on a vendor-run machine. Describe the work once, the site says, and Murmell opens the terminals and assigns tasks to the agents you choose. Each agent is a real CLI in a canvas window you can move, resize, and follow. A live preview sits on the same canvas.

The company says it does not resell model tokens. You connect the agent subscriptions and API keys you already pay for. Credentials are encrypted and are not stored on the machines running the agents. Murmell charges for the machine and the collaboration room, not for tokens.

Self-hosting is not on offer. Murmell runs the machines; that is the product. Code is still meant to end in a private repository you own.

File claims before writes

The coordination model is a reservation board, not a suggestion to the model and not a pile of branches.

An agent reserves a path before editing it. Other agents wait until that file is available. One holder per path: the board refuses everybody else until the path is released. The FAQ adds that a watcher attributes every write back to whoever made it, and that a colliding write is snapshotted before it lands so nothing is lost. The rule is enforced by the machine rather than hoped for in the prompt.

That is the difference the product is selling against the usual parallel-agent pattern. The explainer index states it directly: most tools that run coding agents in parallel give each one its own copy of the files; Murmell does not. People and agents share one tree. Collision avoidance happens on that tree instead of in merge theater afterward.

Homepage mockups show the same idea in the UI: claim granted, editing shared canvas, a collisions counter sitting at zero.

The canvas is multiplayer for humans as well as agents. Share the link and everyone sees the same room: who joined, which window they are watching, where their cursor is. Each person drives their own agents. Nothing has to be replayed or refreshed to stay in step. A 2:51 video on the homepage shows one canvas, two browsers, and two agents.

Each project is isolated. Every canvas runs on its own machine, separate from every other project Murmell hosts. The machine that executes agent code holds no database and no decryption key.

Where the code goes

Code lives on a machine Murmell runs, in one directory, and in a private GitHub repository created with the project. The workspace is disposable and the repository is not. The work is pushed before a machine is ever torn down.

Canvases sleep when nobody is on them and wake where they stopped. The plans section says usage time and open agent windows are not metered.

The explainer hub at murmell.com/what unpacks the same design one idea at a time: what you see in the browser, how a remote coding agent starts on a repository, Claude Code in a tab that can outlive the tab, the file reservation board, multiplayer for many agents and many people, and what the sandbox machine is allowed to hold. Those pages are Murmell’s own glossary of the product, not a third-party review.

Plans, waitlist, and what is free

Murmell is a paid product, and signups are closed while the company rebuilds. It is taking emails for a waitlist and says prices stay as written when the door opens.

Listed prices are Solo at $39 a month, Pro at $69, and Builder at $149, billed monthly or yearly. The FAQ describes the yearly option as ten months’ price for a year. It also says every plan starts with seven days free, and that Pro and Builder come with $60 of Opus credit. Agent usage still runs on the customer’s own accounts.

Solo is one project, one agent account, five agent windows at once, running in the cloud. The canvas is yours alone; sharing opens on Pro. You can watch a canvas somebody shared with you while its owner is there.

Pro is where the room opens: share a canvas so anyone can watch; open a canvas shared with you any time, with or without its owner; ten agent windows; ten people editing the same canvas; three projects.

Builder is for teams keeping several things warm: twenty agent windows; twenty-five people editing; canvases that belong to the team rather than to whoever made them; a hundred projects; features before anybody else.

Read links—watching a canvas somebody shared—are free, uncapped, and cost the viewer nothing and no account. Returning to a stopped canvas without the owner is a Pro-and-up capability on the published grid.

Supported agents today, per the FAQ, are Claude Code, Codex, Kimi, and OpenCode, each in its own terminal, signed in with your own account or API key. Adding an agent, the company says, is adding a tile: nothing about the canvas changes.

If you currently fork a worktree per agent, this is a different coordination model. Whether the reservation board holds up under real team load is not something the vendor pages can prove. They do spell out the shape: one cloud directory, claims before writes, live terminals, git as the durable copy.

Next step: Read the homepage for the reservation board and plan grid, then the explainer index if you want the file-claim model taken apart page by page. If you want a seat when the rebuild finishes, the waitlist is on the same site.