Features
Background work under control
When a Muse Code tool call is taking too long, Helicon lets you send it to the background, stop that one call, or stop everything running, without ending the thread. Workflow runs can be cancelled, and individual agents inside them skipped or retried.
Last updated · Markdown version
Three different kinds of stop
| Control | Effect |
|---|---|
| Background | The call keeps running, the thread stops waiting on it |
| Stop this call | That tool call ends, the turn continues |
| Stop all | Everything currently running ends |
| Cancel run | A workflow run ends, the thread survives |
Conflating these is a common wrapper mistake, and it is why people end up killing a whole session to get out of one stuck test run.
What survives
- The thread and its history, in every case.
- The session, so you can resume and carry on.
- The record of what you stopped and when.
Frequently asked questions
Does backgrounding lose the output?
No. The call continues and its output lands in the thread when it finishes.
Can I stop everything quickly?
Yes. Stop all ends every running call at once, without ending the session.
What happens to a cancelled workflow run?
The run ends and the thread stays open. Individual agents can be skipped or retried instead if that is what you want.
Keep reading
- Subagents and workflowsParallel subagents and workflow runs are hard to follow in a terminal. Helicon shows them as structure: what is running, what finished, and what you can cancel or retry.
- ApprovalsEvery approval Muse Code raises appears in Helicon the moment it arrives. onRequest, promptUnmatched and denyUnmatched are mapped one to one, and allow all is an explicit opt in.
- GoalsSet, pause, resume, change and clear a Muse Code goal from the goal panel or the composer, without dropping back into the terminal to retype a slash command.
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.