Note

A Background Upgrade Is Not a Verified Pull: Ollama 0.40.2–0.40.3 and On-Disk Model Migration

Ollama 0.40.2 converts older models to llama.cpp-compatible builds the first time you run them; 0.40.3 pauses that background upgrade. A familiar tag is not a verified pull.

2026-10-12 · oss-ai, local-ai, ollama, llama-cpp, gguf, model-migration, verify, open-weights, data-residency, sovereignty, civil-liberties

Dark CryptoDecentral hex mesh — one sealed model capsule quietly duplicates into a second capsule while a soft upgrade arrow passes under the shared tag glow; no text.

Open-source AI special · week of 12 Oct 2026

Local AI operators often treat “I already have this model” as a finished verification step: the tag is present, the daemon answers, inference stays on-box. This week’s thesis: a background upgrade is not a verified pull. Between 8 Oct and 11 Oct 2026, Ollama shipped and then paused a convenience path that converts models downloaded with earlier versions into llama.cpp-compatible builds the first time you run them, without a new ollama pull in the operator’s hands. The tag string can stay familiar while the on-disk artefacts, runner identity, and free space change underneath.

CryptoDecentral frame: sovereignty is continuity you can audit — verify weights and packaging events, keep residency claims honest, and treat automatic migration as policy you re-read, not magic that stays invisible.

What actually shipped

Ollama v0.40.2 (8 Oct 2026) introduced a section titled Model upgrades:

Models downloaded with earlier versions of Ollama are upgraded in the background the first time you run them, for better performance and compatibility when running on llama.cpp.

Downgrade safety is explicit: Ollama keeps the original copy as a backup, so upgraded models are temporarily kept on disk. A future release “will remove these backups automatically.” The notes ship a jq loop over localhost:11434/api/tags and /api/show that deletes only digests whose manifests show runner == "ggml" after a llamacpp upgrade exists — and warn that after that cleanup, downgrading below 0.40 means re-pulling those models.

The same release notes that ollama list “no longer shows duplicate entries for upgraded models” (PR #18874) — a hygiene line that only makes sense if dual artefacts were already confusing inventory.

v0.40.3 (11 Oct) paused background model upgrade “for embedding and other request performance,” via @jmorganca in PR #18908. The PR is sharper: it “Temporarily removes the background model migration until a future release” because of per-request overhead and GC pressure for high-volume cases such as embedding models. Issue #18909 asked for a disable option (SSD headroom; metered traffic); the maintainer said 0.40.3 would pause and the team would revisit before re-enabling. Issue #18830 reports inventory fallout — duplicate listing and a bogus llamacpp: tag — so the operator-visible surface was never only “faster llama.cpp.”

This sits on v0.40.0 (25 Sep), which made supported Apple Silicon architectures run on MLX by default. Last week’s special argued that a model tag is not a runner contract. This week is the adjacent failure mode: even on a llama.cpp-shaped path, packaging can migrate under the same tag without an intentional pull.

Why background conversion is a different kind of change

An explicit ollama pull is a bounded ceremony. You choose the moment, watch bandwidth, compare digests if you care, and decide whether the new bytes replace what you trusted. A first-run background upgrade is a side effect of inference:

Trigger ≠ consent ceremony. Conversion starts when you run a model pulled under an older Ollama — not when you type a migration command. Busy embedding services feel that immediately (hence the 0.40.3 pause).
Disk becomes a second residency claim. Keeping original + upgraded copies “temporarily” means free space is part of the upgrade contract. Operators who chose local inference to avoid cloud dependency can still be forced into a WAN re-pull later if they delete backups and then downgrade below 0.40 — exactly the trap the release notes document.
Inventory can lie while the daemon is “healthy.” Duplicate list entries and odd runner-prefixed tags are what #18830 describes. A green chat window does not prove a single, named artefact set.
Runner field is now part of the artefact story. The 0.40.2 cleanup script selects on manifests[].runner values "llamacpp" and "ggml". Packaging is multi-manifest and runner-aware. Treat that as something to inspect, not as an implementation detail you can ignore because the tag string did not change.

This is orthogonal to embedded GGUF alignment: successful load still is not proof of correct tensors. Here the point is different — bytes and runner packaging can change under you even when load keeps succeeding.

Contrast: deliberate API surface vs silent packaging

Around the same days, LM Studio 0.4.26 (8 Oct) added /v1/systemone and /v1/decisions, coexistence with Bionic 1.1.8+, CUDA 13 on Windows ARM, and a llama.cpp runtime bump to 2.50.0 (upstream b11337). That is a visible contract change — new routes you can probe, beside the OpenAI-shaped surface we covered for Ollama’s decision endpoint. Background model migration is the opposite pattern: same CLI verbs, same tags, new digests and dual on-disk copies. Both matter for local stacks. Only one trains operators to notice without reading release notes.

Continuity without kill-switch dependency

A cloud kill-switch is obvious: the remote endpoint refuses you. Local continuity failures are quieter. Automatic conversion that doubles disk until cleanup, then requires a re-pull after downgrade, is a bandwidth and storage dependency wearing a convenience badge. The open issue that asked for a disable switch said the quiet part out loud: limited SSD capacity and people without unlimited traffic. That is a worldwide constraint — researchers on metered links, clinics and newsrooms with thin uplink, anyone who cached models precisely so travel or outage would not force a re-download. Local inference without kill-switch dependency still fails if an opaque packaging event forces WAN contact you cannot afford, or if you cannot name which digest answered last month’s eval.

Civil-liberty-adjacent lesson: if you must keep running when registries and CDNs are unreachable, first-run migration policy belongs in the runbook next to the model card, not only in a changelog skimmed after latency spikes.

What an operator can verify

Daemon version and window. Record whether the host is on 0.40.2 (migration active on first run), 0.40.3 (paused per release notes / #18908), or something else. The pause is temporary language — re-check before any “we’re done migrating” claim.
Manifest runners via /api/show. Use the show-model API. The 0.40.2 cleanup script assumes manifests[] expose runner and digest — look for dual ggml / llamacpp stories under one tag instead of trusting ollama list alone.
Disk before first run on a fresh 0.40.2 host. Free space is a precondition: original + upgraded copies are the documented temporary state.
Backup deletion as a one-way door. The official jq cleanup removes only ggml backups after a llamacpp upgrade exists. After that, downgrade below 0.40 ⇒ re-pull. “I freed disk” ≠ “I kept offline continuity.”
Embedding and high-QPS paths. If latency moved after 0.40.2, correlate with migration policy before blaming the model card.
Model cards describe intent, not daemon side effects. Hugging Face model cards do not narrate a local client’s background rewrite of what you already pulled.

Frame: A verified pull is a deliberate artefact event. A background upgrade is a packaging side effect that can change digests, runners, disk, and downgrade paths while the tag string stays calm. Sovereignty is noticing the side effect — and deciding whether you accept it.

What this note deliberately does not do

It does not rank Ollama against LM Studio, llama.cpp, or any commercial host. It does not guarantee tokens-per-second, embedding latency, or disk savings for any hardware. It does not claim every 0.40.2 install completed migration, or that 0.40.3 deleted already-upgraded artefacts. It does not teach bypassing lawful process. It does not rehash MLX defaults, System One decision schemas, or GGUF alignment as the main thesis — those remain linked contrasts. It gives no investment, token, custody, swap, or trading advice, and it does not recommend buying any product or service.

Educational takeaway: know when your bytes moved. Local open-weight stacks only deliver continuity without kill-switch dependency if packaging events stay as inspectable as the chat reply. Read the 0.40.2 upgrade contract, the 0.40.3 pause, and your /api/show manifests the same way you would re-read any default that touches the artefacts you thought you already verified.