Using darkmux

Two ways to drive it

Every page here shows the commands. Run them yourself at a terminal, or hand the page to an agent: Claude Code and any harness that reads CLAUDE.md or AGENTS.md can follow the same steps, and darkmux init installs the skills that make that smooth. Nothing in the guide requires an agent in the loop; the mission, review, and crawl workflows also run from the command line and from CI. Where a page shows output, it was captured from a real run and says so.

Where to go from here

darkmux doctor's output is the canonical troubleshooting surface.

Want the precise model rather than a walkthrough: role families, the mission/phase schema, telemetry, the flow record? See the concepts reference, the canonical reference for what darkmux is made of.

Who does what

Local models do the work. You, or your agent, decide what runs.

darkmux keeps a crew of local models resident on your Apple Silicon and hands them bounded work: implementation, review, crawling, structuring. A small utility model handles the routine internal jobs (compaction, routing for the radio) so the specialists do not have to. Above that sits whoever holds the intent: you at a terminal, a CI job with a config, or a frontier agent such as Claude Code that reads the docs and proposes the commands. darkmux surfaces, suggests, and records; it never substitutes its judgment for yours.

• Local specialists (coder, reviewer, analyst, crawler): the judgment-bearing work, on your hardware.
• Local utility model: compaction and structured output. Small, fast, dispatched internally; you rarely address it directly.
• You, a config, or an agent: pick the work, name the intent, sign off at the gates. A frontier agent is the most capable version of this seat, not a requirement for it.

darkmux doctor's output is the canonical troubleshooting surface. For the precise model rather than a walkthrough (role families, the mission and phase schema, telemetry, the flow record), see the concepts reference.