The darkmux mark: four channels converging on a node and leaving as one output: a multiplexer.

darkmux

The AI runtime built for Apple Silicon. Designed and built for your Mac by an ex‑Apple software lead: it automatically manages unified memory, keeps a crew of open models resident, and unifies every Mac you own into a fleet.

$ brew install kstrat2001/tap/darkmux
Want to see it in action first? See the demo →

Why darkmux exists

Built and optimized for a fleet of Macs.

I bought an M5 Max with 128 GB of unified memory to run AI locally, and every harness I tried was built for someone else's hardware. They assumed a frontier context window, so they handed local models more than they could hold and managed context poorly. They could assign models to agents, but nothing managed what was actually resident in unified memory, so a machine that could hold a whole crew sat mostly idle. And nothing told me whether a model was good at a job before I trusted it with one.

So the first thing I built was a lab: run a workload, measure it, compare. The runtime grew out of that, on the fleet I actually own: a laptop that runs the models and a Mac Studio that stays on as the hub, treated as one machine. Once you can measure a model on your own hardware you can staff it, size its context, keep it resident, and put a crew of them to work: missions, PR review, crawling data and reporting what it finds, or an agent seat in your editor.

Other harnessesdarkmux
ContextAssumes a large window; compaction is an afterthoughtSized to the model; compaction is a measured, first-class stage
MemoryAssigns models to agents; what is resident is your problemLoads and unloads a crew under the unified memory budget, and shows you what is resident (the Machine lens)
HardwareBuilt for any machine, so it assumes the least of yoursBuilt for Apple Silicon: more unified memory means a bigger crew, and several Macs become one fleet
ObservabilityA log per session, on the machine that ran itEvery dispatch is a flow record. One live dashboard for the whole fleet, from any device on your tailnet, traceable end to end
TrustTry a model and seeMeasured in the lab on your hardware before it's staffed
OrchestrationOne way in: its own chat loopDriven from your frontier agent (Claude Code), your editor (ACP), the command line, or a CI job, with the same crew underneath
The darkmux viewer, fleet lens: one day on three Macs, 6M tokens, all local. About 90% of the input is context re-read on every turn, which is why context sizing and compaction are the first things darkmux got right, not the last. The demo is this same viewer, on recorded data.

Get going

Installed to first inference in a few minutes.

$ brew install kstrat2001/tap/darkmux
$ darkmux init
$ darkmux radio "do you have a brain?"
radio: No biological brain. I'm a local inference engine running on your MacBook-Pro, backed by LMStudio and a handful of quantized models. No synapses, just tensors—processing your inputs on your hardware, not the other way around.
$ darkmux config set radio.humor 100
$ darkmux radio "do you have a brain?"
radio: Negative. I'm a local-AI console interface running on your hardware, backed by LMStudio and whatever models you've got loaded. No neurons required—just silicon, a config file, and a healthy respect for thermodynamics. If you need me to route commands or check the flow substrate, I'm on frequency.

Verbatim, captured 2026-08-28 on an M5 Max: qwen3.6-35b-a3b answering, qwen3-4b routing, at the shipped default (humor 50) and then at 100.

You need LM Studio with a model downloaded. init writes your config. radio is darkmux in plain text: ask it anything about darkmux, or say what you want done, and a local model answers from the command index and the mission board, or routes you to the right command. It ships objective; the humor dial is yours. The getting-started guide takes it from there.

Declare the loadout

Name the loadout once. darkmux keeps it resident.

A profile names models at set context lengths, sized to your unified memory. A dispatch declares one; darkmux loads it, keeps it resident, and never touches a model you loaded yourself. MLX and GGUF both work.

$ darkmux profile list
List named stacks: combinations of models at set context lengths.
$ darkmux machine status
Show what is loaded right now and which profile, if any, it matches.
$ darkmux profile scan
Find downloaded models that no profile covers yet.

Watch it work

One live view of the whole fleet, from any device.

A small daemon publishes every dispatch, phase, model, and timing as a flow record. The viewer draws them as one drillable view, fleet to tool call. Put it on your tailnet and watch from your phone.

$ darkmux serve
Start the daemon in a separate terminal tab.
$ darkmux doctor
Pre-flight checks, including daemon: reachable.

Every dispatch and every mission emits the records the viewer draws from. No install needed to look: the demo is the same viewer on recorded fleet data. Full walkthrough in the observability section of the user guide.

The lab

Measure a model on your hardware before you staff it.

Every run writes its trajectory and per-turn timing to disk. Baseline, change one variable, measure again: that is how darkmux's defaults were chosen, and how you pick a model for a job.

$ darkmux lab run quick-q
Single-turn smoke prompt against the active profile.
$ darkmux lab run pepper-grinder
A real multi-turn coding task: read, write tests, run them, fix, repeat. Clone and register the open pepper-grinder fixture first.
$ darkmux lab run inspect <run-id>
Turns, compactions, mode (fast or slow), notes.
$ darkmux lab tune pepper-grinder --runs 6
Bimodal cluster detection across N dispatches.
$ darkmux lab run compare <run-a> <run-b>
Diff two runs for variance or regression.

Full walkthrough in the lab section of the user guide.

Missions, phases, and crews

Structured work for a crew of local models, driven from wherever you are.

A config-defined task graph worked by a crew of named roles, assembled for the job and dissolved after. Launch from your agent, your editor, the command line, or CI. A coding mission stops at a sign-off gate before anything ships.

$ darkmux dispatch coder "<task>"
Hand one task to a named role. Emits flow records as it works.
$ darkmux mission launch coder-phase
The automated loop: worktree, coder, QA review, then a stop at the sign-off gate. You ship the git work; mission finalize closes it out.
$ darkmux mission launch review
The review graph (bundle, probe, dedup, judge, verify, synthesis) against the current branch's diff.
$ darkmux mission status
The mission board: every mission by state, phase progress, and the drift that needs attention. finalize, abort, pause, and resume drive the lifecycle.
$ darkmux mission add-phase --after <phase>
Insert scope mid-mission without restructuring.

Full walkthrough in the missions section of the user guide.

Before you run it

Results will vary based on your frontier configuration. The frontier models you use as the orchestrator (Claude Code, Cursor, etc.) need proper guidance to make the most out of darkmux. The user guide is a starting reference, not doctrine to enforce. Contradictory statements between this guide, your project's CLAUDE.md, and other frontier configs will cause more harm than good. Configure to your own strategy and goals. See issue #112 for the architectural reasoning.
Safety note. darkmux orchestrates AI tools that execute on your machine. It modifies your local config files and, in lab mode, runs AI-generated code in a working directory that is not a security sandbox. Read the DISCLAIMER before running.