How we use Muse to get more done in parallel

A small team building an app has more useful work than one conversation can hold. A code change needs research and tests. Someone wants to know whether their build is still running. The next product decision needs an answer. We want those things to move together.

We use Muse Code, Meta's terminal coding agent, as an implementer behind our main coding conversation. We give it a bounded task and a separate Git worktree, ask it to return a pull request, and keep the main conversation available while it works. Then the main agent reviews the change and sends concrete feedback back to Muse.

That is our approach to saving the main agent's tokens: let the implementation session hold the detailed research, command output, and edit history. Bring back the result and the evidence needed to judge it. Muse still consumes tokens, and independent review still takes context. We have not measured a total token or cost reduction across both agents.

A timer taught us what to decide first

The change started with a simple complaint: the chat looked stuck while an app was still being built. We wanted an elapsed timer at the start of its progress line.

“Add a build timer” left several different behaviors open. Should it start when the request is submitted, when the server acknowledges it, or when the first tool runs? Should a conversational answer show a clock? Does finishing one generation step mean the whole task is finished?

The eventual contract was short:

• Capture the start when the task is submitted.
• Keep the clock hidden until that task uses a tool.
• Reveal the full elapsed time, including the quiet wait before the tool.
• Keep one origin through related generation, validation, and saving.
• Clear it when the task completes or goes idle. The next task starts fresh and hidden.

We arrived at that contract during implementation and review, which meant extra rounds of work. Next time, those are the questions to settle before the first edit. This is a small product discussion: the owner decides what the clock means, and Muse researches where that behavior belongs in the code.

If code research is needed to settle the decision, ask Muse for a brief research pass first. Have it return the relevant locations, a recommendation, and the questions that remain. For a clear task, let it research and implement in the same run. A separate planning ceremony for every change would add another kind of overhead.

Give the work a place to stay

The initial instruction is concrete:

Create an isolated worktree from fresh main. Implement this behavior, follow the repository instructions, run the relevant checks, and open a pull request. Return the PR number and URL, worktree, branch, commit, validation, and any remaining limitations.

A worktree gives the implementation its own checkout and branch. It keeps edits apart while another task moves forward. It does not eliminate integration conflicts or make shared services independent; two changes to the same behavior still need coordination.

We now keep one Muse session per feature or PR, too. Muse's headless documentation describes continuing with exec --session-id. We checked the installed CLI and verified that two separate executions using the same ID retained both turns in one exported session.

sh# Record this ID with the task and keep its worktree for follow-ups.
muse_session=$(uuidgen)
muse exec --session-id "$muse_session" --prompt-file task.txt

# Later, from the same workspace, continue with the review feedback.
muse exec --session-id "$muse_session" --prompt-file review-feedback.txt

The brief asks Muse to create the worktree; its completion report records where it is. Follow-up instructions target that existing PR and worktree. Check muse exec --help for the installed build's native worktree options and use the configured permissions for your environment.

Keeping the session means the next turn can build on its research and decisions. A compact handoff note preserves the behavior contract and test results through compaction. We avoid loading the whole transcript into the main conversation: that would recreate much of the context we delegated.

Parallel work needs clear ownership

During the timer implementation, the main conversation checked the current build status of an app and explored how Muse supports follow-ups. Muse continued working on the code. That is useful parallelism even with just one implementation job running.

For several independent changes, the same pattern can give each job its own session, worktree, and PR. Each needs a specific outcome and a reviewer. Work that depends on another change waits for that dependency; several agents rewriting the same component would create a coordination problem.

We check a running Muse job no more than once every five minutes. Repeatedly asking whether it is done consumes attention without advancing the task. When it finishes, the result gets our attention.

Live messaging depends on the host. In this setup, the session-message command reported that external ingress was unavailable. We carried new instructions into the next execution in the same session. Persistent follow-ups worked without a second writer racing the first.

The PR comes back through review

The main agent personally reads the diff against the requested behavior. It checks the evidence, posts a review comment, and dispatches another Muse execution with that feedback, targeting the same PR. Muse fixes the findings and returns the new commit. The reviewer verifies what changed.

The timer needed this. Review caught a clock that changed origin when work moved between displays, tool-using conversations that were excluded, and a speculative start that initially omitted the local submission interval. Those were observable gaps in the requested behavior. A completed agent run alone would not have caught them all.

The timer PR merged after those fixes and green checks. One limitation remained explicit: a full page reload reconstructs the start from the server timestamp, while an ordinary reconnect retains the local start. Completion reports should make that distinction easy to see.

Where the token savings can come from

There are three opportunities: avoid having both agents repeat the same broad research, retain the implementation session for follow-ups, and bring concise results into the coordinating conversation. Targeted review still reads the code needed to establish correctness.

Our trace showed cached input, but that does not establish an overall saving. A useful comparison would count both agents' input and output, cache treatment, repeated work, and elapsed time. Starting more agents can increase total token use even while it gets independent work done sooner.

For us, the immediate benefit is a main conversation that remains available while implementation proceeds. A clear brief starts the work. A retained session carries it. Independent review brings the result back into the product.

Title-card photograph: Alessandro Leonardi on Unsplash. CLI behavior checked with Muse Code 1.3.0.