TL;DR: Ollama v0.40.0 started silently rewriting your downloaded models into a new on-disk format the first time you run them, keeping the original as a backup — so every migrated model exists twice on disk, and on v0.40.0/v0.40.1 the upgraded copy leaks into ollama list as a duplicate row plus a llamacpp:<sha> tag. Update to v0.40.3 (October 11, 2026), which pauses the migration, then reclaim the space with the official one-liner below. Do not just ollama rm the weird tag — it comes back.

What you’ll be able to do:

• Tell whether the duplicate rows in ollama list are the migration (harmless display bug) or genuinely duplicated downloads
• Reclaim the backup copies’ disk space with the official cleanup command — safely, knowing exactly what you give up (downgrades below 0.40)
• Stop the background upgrade from eating disk, bandwidth, and per-request latency until Ollama re-enables it in a finished form

Honest take: the migration itself is a reasonable idea shipped too quietly. Ollama’s own team paused it within two weeks because it added per-request overhead, and the backups it leaves behind are pure dead weight once you’re staying on 0.40+. Update, run the cleanup, move on.

The symptom: one model, three rows

You pulled one embedding model. ollama list shows this:

NAME                                                                      ID            SIZE
embeddinggemma:latest                                                     3a2d262bdb75  621 MB
embeddinggemma:latest                                                     82f094e4c0e1  621 MB
llamacpp:82f094e4c0e19bc4208c692996d4f1ecf14e82a8dee579ee1d2ca1175260058e 82f094e4c0e1  621 MB

That’s the exact output from the first bug report, issue #18830, filed October 7, 2026 against v0.40.0 on an M5 Mac: the same model name twice with different digests, plus a llamacpp: tag nobody created. GET /api/tags returns the same three entries, which also breaks any dashboard or script that counts models by name. The server log shows the tell: completed local compat GGUF migration.

Deleting the stray tag doesn’t stick. ollama rm llamacpp:<sha> clears the row, but the next time the model loads, the migration runs again and the tag is recreated — several users confirmed the loop on Qwen and Gemma models before the cause was identified.

If your symptom is a full disk rather than weird listings, same root cause, and the cleanup section below is the fix. If your ollama list duplicates have the same ID and you’re on an older version, that’s a different, older display bug — this article is specifically about v0.40.

What actually happened, version by version

The whole episode spans 17 days, and knowing which build you’re on tells you which problems you have:

Version	Date (2026)	What it did
v0.40.0	Sep 25	MLX becomes the default engine on Apple Silicon; the “local compat GGUF migration” starts rewriting models downloaded by older versions, on first load
v0.40.1	Oct 7	No migration changes — duplicates still visible
v0.40.2	Oct 8	Migration officially documented in release notes; duplicate rows hidden from ollama list (PR #18874); official backup-cleanup snippet published
v0.40.3	Oct 11	Migration paused entirely (PR #18908) — it “created overhead per-request and GC pressure for high-volume use cases (e.g. embedding models)“
v0.40.4 (pre-release)	Oct 12	Server reuses verified manifests and loaded models — groundwork for a better-behaved return of the feature

The why, per maintainer rick-github in #18830: early Ollama builds applied compatibility shims for certain tensor shapes that were always meant to be temporary. v0.40.0 began rewriting those models into a clean format that llama-server (the llama.cpp server Ollama now tracks much more closely) can load directly. The rewrite is registered under a hidden llamacpp:<digest> manifest — the one that leaked into listings — and the v0.40.2 release notes state the policy on the old copy: “To make downgrading safe, Ollama keeps the original copy as a backup, so upgraded models are temporarily kept on disk.”

“Temporarily” is doing a lot of work in that sentence. A future release is supposed to remove the backups automatically; as of v0.40.4 none does, so the space is yours to reclaim manually.

Three separate problems (two are fixed, one is yours)

1. The duplicate rows — cosmetic, fixed in v0.40.2. The extra manifests were always intended to be internal; v0.40.2 suppresses them from ollama list and /api/tags. If you still see them, you’re on v0.40.0 or v0.40.1 — check with ollama -v and update.

2. The request slowdown — fixed in v0.40.3. The migration check ran per-request and created garbage-collection pressure, which hit high-volume workloads hardest — embedding pipelines above all, since they fire thousands of small requests. That’s why the team paused the whole feature (PR #18908) rather than patching around it. If you run embeddings for RAG or search indexing, pin Ollama ≥ 0.40.3; at least one downstream project did exactly that in its own tracker the same week.

3. The doubled disk use — still yours to clean up. Every model that got migrated exists twice. One user in #18830 measured 20.57 GB of extra disk across just four models on v0.40.1. The math scales with your library: a 621 MB embedding model becomes 1.2 GB on disk, and if you’d downloaded a 70B Q4_K_M (42.5 GB — see our 70B-on-24GB guide) with an older Ollama and run it once on v0.40.0–v0.40.2, you’d be carrying ~85 GB for one model. On the small NVMe boot drives a lot of home servers use, that’s the difference between fine and no space left on device — which is precisely the scenario the user in issue #18909 raised when asking for an off switch, a day before the pause shipped.

First: update to v0.40.3 or later

On v0.40.3+ the migration no longer runs, so nothing new gets duplicated and the llamacpp: tag stops regenerating. Check and update:

$ ollama -v
ollama version is 0.40.1

Linux re-runs the install script (curl -fsSL https://ollama.com/install.sh | sh); macOS and Windows update through the app or a fresh download. After updating, ollama -v should report 0.40.3 or 0.40.4.

Don’t stop at the update, though — the pause prevents new duplication. Backups already written stay on disk until you remove them.

Reclaim the disk: the official cleanup

The v0.40.2 release notes ship this snippet. It finds every model that has an upgraded (llamacpp runner) copy and removes the original (ggml runner) backup:

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

It needs jq, a running Ollama server on the default port, and a shell — on Windows, run it inside WSL or Git Bash, or skip to the manual method below. Measure the win with du -sh ~/.ollama/models before and after: the delta is whatever your migrated models’ originals added up to — the four-model library in #18830 got 20.57 GB back. (If your models live somewhere else, our storage-location guide covers finding and moving the model directory on every OS.)

Two warnings, straight from the release notes:

• The snippet deletes only backups. Models that were never migrated, and the upgraded copies you actually use, are untouched.
• Downgrading to anything older than 0.40 afterwards means re-pulling those models. The backup was the only copy the old format could read. If you have any reason to roll back — say, a plugin that pins 0.3x — clean up later, not now.

Manual alternative (no jq, any OS): if ollama list on an old build showed you the llamacpp:<sha> rows, the named duplicate with the older digest is the backup. But on v0.40.2+ the rows are hidden, so the API query above is the only reliable enumeration — eyeballing blob files in the models directory and deleting by size is how people corrupt their store. Don’t.

If requests got slow before you updated

Embedding throughput craters are the signature: the migration check taxed every request, and embedding workloads make the most requests per minute of anything a home lab runs. After moving to v0.40.3, re-run whatever you benchmarked. There’s nothing to tune — the overhead is simply gone with the pause. If generation is still slower than you expect after updating, that’s a different problem with its own checklist: Ollama slow? How to actually raise tokens/sec.

One more interaction worth knowing: v0.40.2 also made first-run behavior heavier in a way you might have noticed as cold-start lag, because upgrade work happened on first load of each old model. If you saw models “reloading” more than usual in that window, it wasn’t your OLLAMA_KEEP_ALIVE settings — though if models still unload too eagerly, that guide is the fix.

This is a pause, not a cancellation

The maintainers were explicit in #18909: “we’ll revisit this before re-enabling it.” The v0.40.4 pre-release already reworks manifest verification and model reuse on the server, which reads like the per-request overhead getting fixed properly. Expect the migration to return in some 0.4x release — ideally with the two things this round lacked: an off switch (the entire ask of #18909, filed by a user on a small SSD with metered bandwidth) and automatic backup removal instead of “temporarily kept on disk” with no expiry.

Until then, the steady state on v0.40.3/v0.40.4 is: old-format models keep working through the compatibility path, nothing gets rewritten behind your back, and your disk holds exactly what ollama list says it holds — once you’ve cleared the backups.

FAQ

Is the llamacpp:<sha> entry malware or a model I didn’t download? No. It’s Ollama’s own hidden manifest for the upgraded copy of a model you already had, unintentionally displayed on v0.40.0/v0.40.1. Same 621 MB embedding model in the example above — same bytes-on-disk family, different format.

Can I just delete the llamacpp tag and keep my version? On pre-0.40.3 builds it regenerates on the next model load, so no. Update first; on v0.40.3+ nothing recreates it.

Does this affect models I pull fresh on v0.40+? No. The migration only touched models downloaded by earlier versions. Fresh pulls arrive in the current format with no backup copy.

Did the MLX default on Apple Silicon cause this? They shipped in the same release but are separate changes. The migration targets llama.cpp/llama-server compatibility and ran on Linux and Windows too. For what the MLX switch itself changed on Macs, see our Ollama MLX guide.

I’m on 0.40.2 — am I safe without updating further? Your listings are clean, but the migration still runs (eating disk and adding request overhead) until 0.40.3. Update.

How much free disk should an Ollama box have anyway? Enough for your largest model twice over — updates, re-quantizations, and episodes like this one all temporarily double a model’s footprint. Factor it in when sizing the drive; our SSD-for-local-AI guide covers why the drive matters beyond capacity.

Sources

• Issue #18830: duplicate model and bogus llamacpp tag after local compat GGUF migration — ollama/ollama
• Release v0.40.2 notes (migration documented, cleanup snippet, backup policy) — ollama/ollama
• Release v0.40.3 notes (migration paused) — ollama/ollama
• PR #18908: server: skip local model compatibility migration — ollama/ollama
• PR #18874: hide duplicate entries for upgraded models in ollama list — ollama/ollama
• Issue #18909: Option to disable automatic model upgrade — ollama/ollama
• Release v0.40.0 notes (MLX default on Apple Silicon, start of the 0.40 line) — ollama/ollama

Last updated October 14, 2026. Version behavior described here matches Ollama v0.40.0–v0.40.4; later releases may re-enable the migration with different mechanics.

Get the numbers before you buy

New GPU and mini-PC benchmarks, VRAM thresholds, and price checks — sent when there's something worth acting on, not on a schedule. No spam, unsubscribe anytime.

Email address Subscribe