Meta's Muse Code CLI is a capable coding agent, but it lives in the terminal. I wanted it in my editor, with the same kind of experience I get from other agents, so I built Muse Spark Code: an unofficial, MIT-licensed coding agent for Meta's Muse Spark.
It just reached version 0.13.0 and is closing in on 1,000 downloads, so this seemed like a good time to explain how it works and how it gets built.
One agent, many editors
Muse Spark Code ships two ways:
- An ACP agent. The Agent Client Protocol lets an editor drive any compatible agent, so Zed, JetBrains IDEs, Neovim, Emacs and other ACP clients can run Muse Spark Code directly.
- An editor extension for Cursor, Windsurf, VSCodium, VS Code and other editors built on the same platform, published on both the Marketplace and Open VSX.
Either way you get the same agent: a chat that streams answers, reads and edits files with reviewable diffs, runs commands behind permission modes, and delegates to subagents.
It runs on your Muse subscription through the Muse Code CLI, or on a Meta Model API key. The API key is never handed to the CLI.
What's new in 0.13.0
Browser checks on your local dev server
After a web change, the agent can open a page on your local dev server in an isolated headless browser, click and type, and read console errors and failed network requests. On the Model API backend it also receives the page's screenshot. The browser runtime is verified and downloaded once, on your request.
This closes a loop that coding agents usually leave open: the agent can now see that its change broke the page instead of assuming it worked.
A Muse Gadgets skill for hardware
Meta recently released Muse Gadgets, an SDK for building ESP32 devices that work with Muse. Muse Spark Code now bundles a skill that walks the model through ESP32 build, flash and bounded serial monitoring. A command that times out still returns its captured output and leaves no process behind on Windows, macOS and Linux.
Secret handling
Detected tokens are redacted, a prompt that contains a secret pauses for your decision, and a shell approval that would expose one only offers one-time consent. Diagnostic notices redact known secret shapes too.
Subagents you can watch
When Muse Code delegates work, each subagent shows up as a row, and an agent map lists every agent with its role, status, token use and its own transcript. You can follow and steer them while they run instead of waiting for a final answer.
Built by a fleet of agents
The part people ask about most is how a solo developer ships several releases a day. The answer is that most of the implementation is done by agents, with a lot of structure around them:
- Claude orchestrates. It plans each milestone and splits it into small, independent lanes.
- Codex and Muse agents build. Lanes are dispatched across several machines: my PC, a Kubuntu VM, a Mac mini and a Windows VM with a GPU.
- Every lane is checked every 30 minutes: is it alive, committing, and on its ETA? A lane that crashes restarts from its worktree and keeps its uncommitted work.
- A different agent reviews every finished lane before it can merge. A failed review starts a fix round immediately, and a third failed round means the part is redesigned rather than patched again.
- Work lands in batches: one merge, one full quality check, one pull request and one CI run per release.
The lesson for me has been that the coding agents are not the hard part. The scheduling and review discipline around them is what makes the output trustworthy.
The rest
- No telemetry and no hosted server of its own
- 15 languages
- Checked against WCAG 2.2 AA in every default theme
- Free and MIT licensed
Try it
The source, docs and full release notes are on GitHub:
https://github.com/RandyNorthrup/muse-spark-code
If you use an ACP client other than Zed, I'd especially like to hear how it works for you. Issues, pull requests and stars are all welcome.
Muse Spark Code is unofficial and not affiliated with or endorsed by Meta. "Muse Spark" and "Muse Code" are Meta trademarks.
Top comments (0)