Ollama 0.40 keeps a backup when it converts older models on load

This post is for developers who run models locally with Ollama and found their model folder larger after updating to the 0.40 releases. It explains which older model files Ollama converts, why the original stays on disk as a backup, how to see both copies, and what the release notes say about removing them. Nothing was run for this post: it is based on Ollama’s release notes, two pull requests, one GitHub issue, Ollama’s docs and one Ollama blog post, all read on 2026-10-26.

Ollama converts some older model files the first time they load

The conversion decides which of your files are touched. In issue #18870, a report about duplicated entries in ollama list, an Ollama maintainer explains that Ollama is moving to llama-server and removing its own patch set for llama.cpp. The maintainer says the 0.40 release added manifest lists and began converting GGUF model files on disk so they can run without that patch. To avoid slowing the first response, the conversion is done lazily.

Not every download is affected. Pull request #18874 says the conversion happens when “a legacy GGUF which requires our llama.cpp patch set is loaded”. In the same issue, the maintainer adds that models that are never loaded are left as they are. The affected architectures are in the “Supported Transformations” table of the compat layer README, which describes a temporary translation layer that lets existing Ollama GGUFs run without a re-pull. The table includes gemma3, gemma4, gptoss, qwen3vl, llama (Llama 3) and llama4, among others, and the README says its layer leaves files that match none of these markers unchanged.

The original file stays on disk as a backup for downgrades

Keeping the old file is what makes the model folder grow. The v0.40.2 release notes say Ollama keeps the original copy as a backup “to make downgrading safe”, so for a while both copies of an upgraded model are kept on disk. Pull request #18874 says Ollama holds “both the new and old GGUFs” and creates a hidden v1 manifest tag so that an older server does not delete the new files. Both documents say a future release will remove the old copies.

The user who opened issue #18870 reported Ollama 0.40.1 on Linux listing gpt-oss:latest twice plus a llamacpp: entry, each 13 GB. Another commenter in the same issue said they hold 253 models and 3 TB in active storage. The v0.40.2 release stopped ollama list from showing duplicate entries for upgraded models; the files themselves stay.

Version 0.40.3 paused the conversion, and later notes say nothing about backups

What happened after 0.40.2 decides whether waiting for an update will free the space. The v0.40.3 release notes contain one line on it: “Paused background model upgrade for embedding and other request performance”. Pull request #18908, merged on 2026-10-09 (dates in this post are UTC, from GitHub’s records), says it “Temporarily removes the background model migration until a future release” because of per-request overhead and garbage-collection pressure with embedding models and other high-volume use. The pull request does not say what happens to copies already made.

The release notes from 0.40.4 through 0.40.11 do not mention backups or their removal.

How to see whether a model has a converted copy and a backup

Two views show the copies, one from the CLI and one from the REST API. In issue #18870, the maintainer says ollama show gpt-oss:latest lists the versions under “available runners”, and that those names can be passed to other commands such as run, rm and cp. The v0.40.2 release notes use the API instead: /api/show returns a manifests list whose entries carry a runner and a digest. Their cleanup command treats a model as converted when one of its manifests has the runner llamacpp, and treats that model’s ggml manifests as the backups.

To check sizes on disk, the Ollama FAQ gives the default model folders. They are ~/.ollama/models on macOS, /usr/share/ollama/.ollama/models on Linux and C:\Users\%username%\.ollama\models on Windows. The OLLAMA_MODELS environment variable moves that folder elsewhere.

What the cleanup command in the 0.40.2 notes deletes

The v0.40.2 release notes include a shell pipeline for removing backups now instead of waiting, and it deletes model files. It requires jq. It reads every local model name from /api/tags, asks /api/show about each one, and keeps the models that have a manifest with runner llamacpp. For those models it prints the digest of each manifest with runner ggml, removes duplicate digests and passes each one to ollama rm. The exact command is in the release notes.

The release notes say the command “only deletes the backups”. They also say that after running it, downgrading to a version older than 0.40 means re-pulling those models. In issue #18870, the maintainer describes the same step by hand: removing the ggml versions and keeping the llamacpp versions if space becomes a concern in the short term.

On Apple Silicon, 0.40.0 moved supported models to MLX

The other runner change in the series affects Macs with Apple Silicon. MLX is Apple’s machine learning framework, which Ollama started using in a preview in March 2026, according to the Ollama blog. The v0.40.0 release notes say that on Apple Silicon devices, model architectures supported by the MLX runtime now run on MLX automatically. The notes name gemma4, qwen3.6 and qwen3.5 among the models and say more will be enabled over time.

Limits

This post comes from reading sources, not from running Ollama, so no sizes or outputs were measured. No source read lists values of the runner field other than ggml and llamacpp, or says whether the converted copy is the same size as the original.

The sources give no date or version for resuming the conversion or for removing backups automatically. The 0.40.0 notes give no full list of MLX-supported architectures and no documented way to opt out of MLX. The pull request that introduced the conversion could not be identified; the maintainer says only that it began with the 0.40 release.