Slotstream Runs a 104GB Model on a 48GB Mac and It Would Not Build on Ours

Slotstream was created on 28 August. When we pulled the GitHub API on 2 September it had 218 stars, 12 forks, 2 open issues and exactly one watcher. Five days, 81 commits, 12 tagged releases, all of it from one person.

The pitch is the kind that usually turns out to be nonsense: run Qwen3.8-Flash-Next, a 125 billion parameter mixture of experts that occupies 103.8GB on disk at 4-bit, on a Mac that cannot hold it, by streaming the experts off the SSD as the router asks for them. One Swift binary, no Python, speaking the Ollama and OpenAI chat APIs so existing tools keep working. It went to 220 points on Hacker News on its third attempt at a Show HN. The first two got 2 and 3 points.

What it actually is

8,646 lines of Swift under Sources, split across an engine, a planner, an expert store, an n-gram store and an Ollama-compatible server. The largest file is the server at 896 lines, the second largest is the planner at 733. Eleven resolved dependencies, of which three are direct: mlx-swift, swift-transformers and swift-argument-parser. MIT licensed.

The trick is in the model shape rather than any new maths. Of the 103.8GB, the routed experts are 67.9GB and an n-gram store is another 32.0GB. What is left, the part that has to be resident, is 3.8GB. So the engine loads that trunk, keeps a pool of expert slots in memory, and pages the rest in from disk per token.

slotstream doctor          # what your machine can do, before downloading anything
slotstream pull            # the 103.8GB, resumable, sha256 checked
slotstream serve           # port 11434, Ollama and OpenAI clients work unchanged

We tried to build it, and could not

The README says Command Line Tools are enough and no Xcode is needed. On our M4 Pro with Swift 6.2.4 from the Command Line Tools, make build died 17.8 seconds in:

error: Dependencies could not be resolved because 'mlx-swift' >= 0.31.5
contains incompatible tools version (6.3.0) and root depends on
'mlx-swift' 0.31.6..<0.32.0.

The dependency needs a Swift 6.3 toolchain. The project's own MEASUREMENTS.md records the dev machine as running Swift 6.3.3, so the requirement is real and simply not written down anywhere a new user would see it. That is a one line README fix, and it is currently the difference between the advertised path working and not.

The release path is in much better shape. We fetched the v0.2.1 tarball published at 03:43 UTC that morning, 51.0MB, and the sha256 matched the digest published beside it. It unpacks to a 37.6MB binary plus a 131MB Metal shader library, so 169MB installed. The binary is small. The metallib is not.

What the planner said about our machine

slotstream doctor needs no weights, which means we could run the interesting part without a 103.8GB download. It read our hardware correctly, reported an applegpu_g16s device with 52GB of RAM and a 40.2GB Metal working set, then refused to be optimistic about it.

Claim in the README	What we got
One command install from a signed release	51.0MB, sha256 matched, worked
Command Line Tools are enough to build main	Failed in 17.8s, needs Swift 6.3
48GB tier gets 33GB and ~12 tok/s	Live plan fell to the 8.1GB floor, ~3 tok/s
Reproducible via doctor --sim-ram	Simulated 48GB gave 33GB, 152/512 experts, ~12 tok/s
Governor policy is tested	20 assertions passed in 0.012s

That third row is the one to sit with. The headline number assumes a Mac that is doing nothing else. With our normal working set open, only 8.9GB of 52GB was reclaimable, so the planner took the floor and printed its own warning: "only 8.9 GB of 52 GB RAM is reclaimable right now, running at the 8.1 GB floor anyway, expect heavy paging until other apps release memory". Simulating an idle 48GB machine reproduced the README table exactly. Both things are true, and only one of them is on the front page.

We did not download the weights, so we have measured no tokens per second at all. Every throughput figure here is the project's, and to its credit the tool labels them that way in its own output, as estimates from measured M5 Pro anchors.

What it does not do

• Tools, images, JSON schema output and logprobs are not supported. The server returns a 400 rather than ignoring them, which is the right call.
• The Ollama CLI itself is not supported yet, only the API subset that clients and SDKs use.
• One model. Qwen3.8-Flash-Next at 4-bit, with the file hashes compiled into the binary.
• Apple Silicon and macOS 14 or later only, and you need about 110GB free. A 512GB Mac is the realistic floor, and disk runs out before memory does.
• swift test needs Xcode, so the acceptance battery in Tools/verify.sh is the real test suite.

Who made it, and what that costs you

Every one of the 81 commits is authored by Carlos Galarza. Twelve releases shipped in six days, the most recent one hours before we looked, and the tarball on the latest tag had been downloaded 41 times. This is one person moving very fast in public.

What makes us take it seriously anyway is MEASUREMENTS.md. It accounts for the model byte by byte from the safetensors headers, read over HTTP range requests across 11 shards and 3,215 tensors without downloading the file, landing on 103.770GB. More importantly it records where the author's own plan was wrong: the n-gram store was predicted at 28.8GB and measured 32.0GB, and the note says so, in the file, under a heading reading "plan was structurally wrong". Vendor benchmark pages do not do that.

Verdict

Adopt today if you have an Apple Silicon Mac with 110GB free, you specifically want this model locally, and you are comfortable pinning a release from a one person project. The install is honest, the planner tells you the truth about your hardware before you spend two hours downloading, and the safety rails around resizing are tested.

Wait if you want a general local model runner. This is one model with one build target, and llama.cpp or Ollama will keep being the boring correct answer for everything else. What would change our mind is a second committer and a second model, in that order.