Several Macs, one engine

faxl runs on one Mac via MLX. It also runs across several Apple-silicon machines using exo — the open-source software from exo labs that connects your devices into an AI cluster — as the execution engine. Same product, same licence key: there is no separate faxl edition for it.

Why

Three reasons to use more than one machine

Models that don't fit. A 700 GB model does not run on one Mac. Across a cluster it does, and that is the only practical way to run one on Apple silicon.

Speed, not just capacity. exo shards a model across devices, and reports up to 1.8× on two devices and 3.2× on four. With RDMA over Thunderbolt 5 it claims a 99% cut in latency between machines — so adding hardware lets you run better models with lower latency. Those are exo's published figures, not ours.

Machines you already own. A Mac Studio under a desk, an M4 mini on a shelf, a laptop idle overnight — one inference server rather than three underused computers. exo discovers them automatically and works out how to split the model itself.

The division of labour

Call faxl, and reach our enhanced exo backend

You point your client at faxl, exactly as you would on one machine. Behind it, exo clusters your Apple-silicon Macs and runs the model across them, while faxl keeps everything it already owns: the chat template, the lookup, byte-for-byte verification, checkpoint placement, the store, the console and the licence.

We customised exo, replacing its internal cache technology with ours. The faxl caching engine is designed for maximum token reuse, including in the edge cases where ordinary prefix caching gives up.

Better caching

Complex models, complex prompts, and cheap disk

Hybrid architectures, serviced intelligently. Hybrid models are harder to cache than conventional ones, and faxl lowers the cost of running them — KDA with gated MLA, MoE-wrapped KDA with DeepSeek-style MLA, and bailing_hybrid models like Ling 3.0.

It is not only complex models — it is complex prompts. Take image work. Your prompt might carry example images with example outputs, teaching the model how to handle the user's image. faxl caches the prompt and its examples, and processes only the new image as new tokens. The teaching material is paid for once.

Caches live on cheap disk, so they are still there next week. This is the part that changes what is possible. faxl parks its cache on local disk or a cheap NAS instead of holding it in RAM, so long-running, infrequent agentic workflows get the benefit of caching without racing an eviction policy.

Ad-hoc reporting against your own databases is the clearest example. Every question reads in the database schema — thousands of lines — and then turns your question into twenty lines of SQL. Pin that schema on disk and time to first token drops from minutes to seconds, even when you only ask once a fortnight.

The point

The cache survives a machine leaving

exo's cache lives in RAM, per node, and is never written to disk. Any change to the cluster — a node failing, a node joining, work being placed differently — takes the runner processes down and the cache with them.

That is exactly where clusters live. Machines come and go: someone closes a laptop, a cable is pulled, a box reboots. On a large model a cold re-prefill after every such event is ruinous.

faxl's store is on disk and outlives the runners. When the cluster reshapes, the session resumes warm instead of starting from nothing. That gap is the reason to put faxl in front of exo rather than using exo alone.

What you need

Requirements

Machines

Two or more Apple-silicon Macs. They may be different models and different memory sizes.

Network

Thunderbolt between the machines. exo runs over ordinary networking too, but the state moved between nodes is large and the link is what you will feel.

For RDMA (optional, fastest)

Thunderbolt 5 and macOS 26.2. exo lists it as working on the M4 Pro Mac mini, M4 Max Mac Studio, M4 Max MacBook Pro and M3 Ultra Mac Studio. It is enabled once per machine from Recovery mode, the cables must support TB5, and every node must be connected to every other. exo's README has the steps and the caveats.

Memory

Enough combined unified memory to hold the model. This is what decides which models a given set of machines can run.

Toolchain

Full Xcode 26, plus xcodebuild -downloadComponent MetalToolchain. The Command Line Tools do not ship a Metal compiler at any version, which is the single most common reason a cluster build fails.

Python

3.12, as on a single machine.

Licence

The same free key as the single-machine install. Paste it into the console on the machine running faxl.

Before you start

Installation notes

Install exo first, from its own instructions. exo is a separate open-source project and its README is the authority on setting it up — including enabling RDMA, which is a one-time step in Recovery mode and has caveats worth reading before you start. Get a cluster answering on its own before putting faxl in front of it.

exo needs its own pinned dependencies. It does not run on stock mlx-lm, and on macOS it expects its own fork of mlx. Install it in its own environment and do not substitute the stock packages — faxl is built and tested against the versions exo pins.

Turn exo's prefix cache off. Set EXO_PREFIX_CACHE=0. Two caches in one path is not twice as fast; it is two answers to the same question, and only one of them is verified.

Start with one machine. Get faxl working on a single Mac first and confirm you are getting hits in the console. A cluster adds placement, transport and topology to anything that is already wrong, and every one of them looks like a cache problem.

Check the console, not the clock. A miss that quietly falls back to local prefill returns a correct answer and, on a fast machine, can look like a hit. The console reports what actually happened — trust it over a stopwatch.

Status

Where this is today

Single-machine faxl is what ships in the wheel today, and it is what the install page covers. Cluster support is being finished now: the engine work is done and proven, and it is being wrapped into the build.

If you have several Macs and want to be early, tell us what you have — machine models, memory, and the model you want to run. Real hardware descriptions are what decide the order this work lands in.