Skip to content

Use cases

Muse Code in a large monorepo

A monorepo makes two things harder: keeping parallel agents from colliding, and running a test suite a laptop cannot hold. Helicon answers both by treating isolated git worktrees as separate projects and by letting the daemon live on the machine with the CPU while you watch from a browser.

Last updated · Markdown version

Isolation inside one repository

In a monorepo the temptation is to run several agents on one checkout because it is one repository. It is still one working directory, and they will still collide. Worktrees give each task a directory of its own while sharing the object store, which keeps the disk cost sane even when the repository is large.

Put the daemon on the big machine

  • Test suites and builds run where the CPU is.
  • The checkout stays on the machine that can hold it.
  • Long runs continue while your laptop sleeps.
  • The UI is the same in a browser as on the desktop.

Reading changes in a big tree

Diffs appear inline at the turn that produced them, and the file viewer beside the thread opens any path the agent mentions. In a repository with thousands of files, being handed the path rather than searching for it is most of the work.

Frequently asked questions

Does Helicon index my monorepo?

No. It indexes sessions, not source. Reading files is on demand through the viewer.

One project per package or one for the repo?

Whatever directory the agent works in is the project. For parallel work, a worktree per task is the cleaner shape.

Can the daemon run on a build server?

Yes. That is the remote daemon setup, with the UI in a browser.

Same Muse Code. Same subscription. Better interface. 

Free and MIT licensed. Signed Windows installer, universal macOS DMG, and a web build against a daemon you run.