89 packages coordinate hardware that one process cannot
Our Python environment installed 89 packages and used 274 MB, a modest software footprint for exo's hardware ambition. exo discovers nearby nodes, measures their topology, and splits models across combined memory and compute. Each node exposes a dashboard and several familiar API shapes. This can turn a shelf of Apple Silicon machines into one inference cluster for models too large for a single Mac. It also introduces distributed state, network discovery, model placement, and failure recovery into what would otherwise be one local process.
The clearest reason to use exo is memory capacity, not convenience. The README shows clusters of recent Mac Studios running large quantized models and describes pipeline plus tensor parallel placement. Those are project examples, not our benchmarks. We had 1 unprivileged container with 3 CPUs and 8 GB of RAM, so our run did not test automatic discovery, Thunderbolt networking, Apple GPUs, model loading, token speed, or scaling. Any performance claim on this page must stay with the project's cited material.
What happened when we ran it
In our 3 CPU, 8 GB Python 3.12 container, installation succeeded in 340 seconds. It added 89 packages and occupied 274 MB. The build then succeeded in 5 seconds. The checkout contained 883 files, about 89,617 lines of source, 2 CI workflow files, and a tests directory. There was no Dockerfile. pip-audit reported 0 known vulnerabilities for the installed Python environment, which is useful but separate from application security.
Pytest stopped after 8 seconds with exit code 4. While loading tests/conftest.py, Python raised ModuleNotFoundError: No module named 'exo_tools'. The summary therefore recorded 0 passed and 0 failed out of 0. The log does not say why that module was unavailable, so we will not assign a cause. It shows that the repository's test entry point did not run in our fresh environment, leaving cluster behavior and model correctness unverified.
Apple Silicon gets the complete hardware story
The macOS route has the features that make exo unusual. MLX supplies inference, recent Apple hardware can use GPUs, and supported Macs can connect through RDMA over Thunderbolt 5. The packaged app requires macOS Tahoe 26.2 or later, asks permission to install a network profile, and offers a cluster namespace. Source builds add Xcode, uv, Node, nightly Rust, and a pinned revision of macmon; the README warns that the Homebrew 0.6.1 build crashes on Apple M5.
RDMA is an enthusiast setup. Each participating Mac must connect to every other node, cables must support Thunderbolt 5, one Mac Studio port is excluded, and OS versions must match exactly. Enabling the feature requires entering macOS Recovery and running a system command. That may be worthwhile for a dedicated cluster. It is far too much ceremony when a model fits one machine, especially because our 5-second build says nothing about RDMA stability or distributed output quality.
Linux currently gives up GPU acceleration
Linux installation uses uv, Node 18 or newer, and nightly Rust, with MLX extras selected for the intended backend. The README then states that exo currently runs on CPU on Linux and that GPU support is under development. That restriction changes the buying decision for anyone with NVIDIA hardware. A multi-node CPU cluster may be interesting for compatibility work, but vLLM or another GPU server is the practical route when throughput on existing accelerators is the objective.
The API compatibility is still useful. exo accepts OpenAI Chat Completions, Anthropic Messages, OpenAI Responses, and Ollama-shaped calls at port 52415. Model instance creation is asynchronous, and clients can wait on an event stream until placement is ready. Custom Hugging Face models are supported, while remote model code is disabled by default and must be explicitly trusted. Our 89-package install did not download a model or send any of these requests.
commit b5375f8 should not be network reachable
Open issue #2267 is directly tied to commit b5375f8, the exact revision in our lab block. The report says the model deletion route fails to contain a parent-directory component, allowing deletion of the parent of a writable model directory. On the default layout, that parent holds exo's persistent application data. The issue also says the control API binds to all interfaces without authentication, which can make the deletion reachable to another host on the network.
That report is scoped and serious. It does not claim arbitrary deletion anywhere on the filesystem; it describes deletion of each configured model directory's parent. A cluster namespace changes discovery membership, but the report says it does not authenticate HTTP callers. Until maintainers close the issue and users verify the fix, firewall port 52415 to loopback or a tightly controlled host set and avoid commit b5375f8. pip-audit's 0 known vulnerabilities does not cover this application logic flaw.
Current pushes do not replace a security release
GitHub showed 47,043 stars, a last push on August 25, 2026, and 344 open issues and pull requests combined. That is current source activity. The latest tagged release, v1.0.71, dates to April 23 and included fixes for M5 Macs, RDMA, model parsing, and prefix caching. A stale tag alone would not establish abandonment, especially with recent pushes and issue updates. It does mean users need to identify which source revision contains a security fix rather than assuming the latest tag does.
exo is an interesting answer to a narrow question: how can several modern Macs run one model locally? It is not the default local AI runner. The 340-second install, 0 executed tests, hardware-specific network setup, and open deletion report make this a lab project for experienced operators today. Wait for issue #2267 to close, verify the containing commit, run the full suite, and test output across 2 isolated nodes before adding more hardware or exposing a compatible API to applications.