Ollama 0.40 on Mac: MLX by Default, Disk Space Doubled

Ollama 0.40 sends supported models to Apple's MLX runtime on Apple Silicon automatically, and from 0.40.0 it also rewrites older GGUF models in the background the first time you load them, keeping the original beside the converted copy. If you update and run your usual models on a Mac with a small SSD, expect each migrated model to cost roughly double its size until you clean up. The maintainers merged a pause for that migration on October 9, but as of this writing it has not shipped in a tagged release.

This is a "check your disk this afternoon" post, not a speed benchmark. I did not run Ollama for this piece, so every command below comes from Ollama's release notes or issue threads and is labelled as such.

What 0.40 changed#

Two separate things landed in the same release line, and the community has been conflating them.

MLX by default. The v0.40.0 release notes say that on Apple Silicon, "model architectures supported by the MLX runtime will automatically run on MLX." Their examples are ollama pull qwen3.8 and ollama run qwen3.8, with gemma4, qwen3.6 and qwen3.5 listed as additional models. MLX also gained an embedding model, embeddinggemma-2, which our embeddinggemma-2 guide covers. There is no new flag to learn: the scheduler picks the runtime. Ollama publishes no benchmark in those notes, so treat any speedup number you see as unverified until you measure your own model.

Lazy model conversion. Ollama's llama.cpp-based runner needed a compatibility layer for some model tensor shapes. A project collaborator explained on issue #18830 that the layer was always meant to be temporary, and that 0.40.0 started rewriting those models so they run natively. Maintainer dhiltgen added on issue #18870 that the conversion is lazy, happens only when you load a model, and that "dormant models are left as is." To support downgrades, the old copy stays behind a manifest list, which is why ollama list briefly showed duplicate rows and strange llamacpp:<sha> tags.

The v0.40.2 release notes state the consequence directly: upgraded models are "temporarily kept on disk" as backups.

What it costs#

One user on issue #18830 measured it on an M1 Max with Ollama 0.40.1. The migration log budgeted twice the model size, and the extra disk across four loaded models was about 20.6 GB, of which gpt-oss:20b alone accounted for 13.8 GB. That is one machine, reported by one user, but the mechanism (original blob kept, converted blob written beside it) is confirmed by the maintainers' own explanation.

Two details make it worse than a plain duplicate:

• Deleting the llamacpp:<sha> tag does not reclaim space. The same reporter found it is recreated on the next load.
• The tag's digest changes after migration. If your tooling treats a changed digest in /api/tags as "this model was updated", every migrated model looks updated.

What is already fixed, and what is not#

• Duplicate rows in ollama list: fixed in 0.40.2 via PR #18874, per the release notes. The model is still two manifests on disk. ollama show <model> lists the available runners, which dhiltgen says you can pass to run, rm and cp.
• The migration itself: PR #18908 was merged on October 9 and "temporarily removes the background model migration until a future release," citing per-request overhead and GC pressure for high-volume cases such as embedding models. It is on main. The latest tagged release on the releases page when I checked was still 0.40.2, which predates it.

So if you updated to 0.40.0 through 0.40.2 and have loaded models since, you may already have the backups. Models you have not loaded since updating are untouched.

What to do on Monday#

1. Check where you stand. ollama --version, then compare du -sh ~/.ollama/models (the default model directory on macOS) with your free space. If you are not tight on disk, you can stop here and wait for the next release.
2. If you are tight, use Ollama's own cleanup. The 0.40.2 notes include this loop, copied verbatim, which needs jq and deletes only the backups:

curl -s localhost:11434/api/tags | jq -r '.models[].name' | while read -r m; do
  curl -s localhost:11434/api/show -d "{\"model\":\"$m\"}" | jq -r \
    'select(any(.manifests[]?; .runner == "llamacpp")) | .manifests[] | select(.runner == "ggml") | .digest'
done | sort -u | xargs -n1 ollama rm

To see what it would remove first, I would replace the final xargs -n1 ollama rm with xargs -n1 echo. That edit is mine and I have not run it against a live install. 3. Know the cost of cleaning. The release notes warn that if you later downgrade below 0.40, you must re-pull those models. Do not run the loop if you rely on rolling back. 4. Keep large models you do not use out of the loop. Since conversion happens on load, a 70B you only try once a month will not grow until you load it. 5. If you use ollama launch claude, 0.40.2 now has it use the model's full context length (PR #18855). A bigger context window also means more KV-cache memory, so watch RAM on a smaller Mac. Our Copilot CLI and Ollama guide covers the same context-length trap for another agent.

Who wins and who loses#

The winner is the Mac user running one or two mainstream models, who gets MLX without touching a setting. The loser is anyone who treats ~/.ollama as a stable artifact: laptop users on 256 GB drives, teams that bake models into images, and tools that watch /api/tags digests. The second-order effect is that runtime selection is now invisible, so reproducibility moves from "which flag did I pass" to "which Ollama version and which manifest runner". If you compare local runtimes, our Ollama vs LM Studio vs vLLM vs llama.cpp guide is the place to weigh that trade, and the best local coding models covers which weights are worth the disk in the first place.

What people are actually saying#

• Bug-report mode, mostly about the surprise. On issue #18870 a collaborator asked why "a significant structural change" was not announced, and what happens when different Ollama versions share storage. The maintainer apologised for the confusion and promised a tidy-up.
• Measured pain. The M1 Max report on issue #18830 is the most useful practitioner data point because it lists per-model sizes. A later commenter reported the same behaviour with qwen3.5 and Gemma models, and said removing and re-pulling the affected models ended the duplicates for them.
• The counter-case. The maintainers' position is that the backup exists so downgrades work, which is a reasonable default for a tool installed on millions of machines. One commenter argued the rollback copy should be opt-in or pruned after several successful loads. And the pause in PR #18908 suggests the team agrees the first design was too heavy.
• Confusion about MLX-only models. Two r/ollama threads, one and two, ask whether embeddinggemma-2 only works on Macs. The answers I could see in search excerpts disagree on how strictly it is MLX-only, so check the model's tags with ollama show before pulling it on Linux or Windows. I could not open Reddit directly, so this is secondhand from the excerpts.

FAQ#

Does Ollama use MLX on Apple Silicon by default?#

Yes, from 0.40.0, for model architectures the MLX runtime supports. The release notes list qwen3.8, gemma4, qwen3.6 and qwen3.5 as examples, plus an MLX embedding model, embeddinggemma-2.

Why did Ollama double my model disk usage?#

From 0.40.0, loading an older GGUF model triggers a background conversion that keeps the original copy as a rollback backup. The 0.40.2 release notes confirm the backups stay on disk until removed. A migration pause was merged to main on October 9 but had not shipped in a tagged release when I checked.

Is it safe to delete the llamacpp: tag?#

Removing the llamacpp:<sha> tag alone does not help: one reporter found it is recreated on the next load. Use the cleanup loop from the 0.40.2 release notes instead, and remember it forces a re-pull if you later downgrade below 0.40.

Sources#

Checked October 10, 2026. Nothing here was run against a live Ollama install.

Last updated: October 10, 2026

Continue Reading#

• Ollama vs LM Studio vs vLLM vs llama.cpp: Picking a Local Runtime for Coding Agents - when Ollama is the right local server and when it is not.
• The Best Local Coding LLMs in 2026 - which open weights are worth the disk.
• embeddinggemma-2: Local Multimodal Embeddings Guide - the MLX embedding model from the 0.40.0 notes.
• GitHub Copilot CLI With Ollama: Local Models and the New Sandbox - the context-length trap for local models in agents.
• Run Kolibri Locally: GGUF and MLX - the GGUF versus MLX trade-off on a Mac.