Ollama Models Taking Up Space on Mac? Find and Remove Them Safely

Where Ollama stores models on macOS

Ollama's official FAQ lists ~/.ollama/models as the default model location on macOS. The wider ~/.ollama directory also contains configuration, while ~/.ollama/logs contains application and server logs. Those are different data classes: model weights dominate storage, configuration may be difficult to recreate, and logs are diagnostic history. Do not erase the entire ~/.ollama directory when your goal is merely to retire one downloaded model.

A model name is not necessarily represented by one obvious file in Finder. Ollama keeps manifests and content-addressed blobs so data can be addressed by digest and, in some cases, shared. That internal layout is why manually deleting the largest blob is a poor cleanup method: a filename does not tell you which model still needs it, and bypassing Ollama can leave the library inconsistent.

If you set OLLAMA_MODELS, the active library may be somewhere else. The official FAQ supports this environment variable for choosing a different model directory. Check how Ollama is launched and confirm that location before measuring ~/.ollama/models; otherwise you may inspect an old default folder while the live library is on another disk.

Measure the model library before deleting anything

Start with Ollama's own inventory. Run ollama ls to list available models, including their names, tags, sizes, and modification information as reported by the current service. A tag matters: model:latest and model:another-tag can refer to different manifests, and a custom model can depend on layers also used elsewhere. Copy the names exactly before removal rather than guessing from a folder name.

Use du -sh ~/.ollama/models to measure the default library as a whole. If the library is elsewhere, substitute the confirmed OLLAMA_MODELS path. Finder's Get Info is also acceptable for a high-level measurement. The total on disk may not equal the simple sum shown by ollama ls because the storage layout can reuse content and filesystem accounting has overhead. Treat both readings as evidence, not as a promise that removing a model will free its displayed size byte for byte.

Also run ollama ps before cleanup. It lists models currently loaded for use. Removing a model that serves an editor, local API client, automation, or coding assistant can interrupt work. Stop the dependent workflow, record its required model name and tag, and then decide whether the download cost is acceptable.

1. Run ollama ls and save the exact names, tags, reported sizes, and modified dates.
2. Run ollama ps and identify models currently loaded by active tools.
3. Measure the active model directory with du -sh ~/.ollama/models or the confirmed OLLAMA_MODELS path.
4. Map each deletion candidate to the applications, scripts, and local APIs that call it.
5. Protect the Modelfile and local source artifacts for every custom model before removing its Ollama entry.

A model that is not currently running is not automatically unused. Editor integrations and scheduled tools may load it only when a task starts.

Choose models by replacement cost, not size alone

The safest first candidates are large public models you can name, no longer use, and can download again from a trusted source. Check network limits, download time, and whether the exact tag remains available. Keeping one frequently used quantization can be more useful than keeping several near-duplicate sizes just because each was expensive to download once.

Be more conservative with custom models created from a Modelfile. The Ollama entry is reproducible only if you still have the Modelfile and every local file it references, such as an imported GGUF file or adapter. A model created months ago may embody a prompt template, parameters, or private local assets that are not recoverable from the model name alone. Back up those source materials before treating the built model as cache.

Offline work changes the decision. Ollama models are locally useful precisely because they do not require a network round trip at inference time. If you travel, work behind a limited connection, or rely on a model during an outage, its redownload cost is operational rather than merely inconvenient. Free less space now or move the supported model location to a suitable disk instead of creating an avoidable outage.

Remove one model with Ollama's CLI

Use Ollama's supported command rather than Finder: ollama rm model:tag. The official CLI reference documents ollama rm for removal and ollama ls for inventory. Include the tag when the list shows one so the target is unambiguous. Read any error instead of escalating immediately to manual deletion; an unavailable service, wrong environment, or different model directory should be fixed before touching storage.

Remove one candidate at a time. Re-run ollama ls to confirm that the intended name disappeared, then measure the active models directory and macOS free space. Storage may fall by less than the model's displayed size when remaining models reuse some content. Conversely, deleting the last manifest that references a large set of blobs can release more space than expected from a superficial comparison.

Test the workflows you intended to keep. Launch a retained model, start the editor integration or local app that depends on it, and check that scripts still refer to installed tags. If a required public model was removed, ollama pull model:tag can download it again. That is replacement, not recovery of an undocumented custom build.

1. Copy the exact candidate name from ollama ls.
2. Stop applications or automations that depend on that model.
3. Run ollama rm model:tag for that one target.
4. Run ollama ls again and remeasure the active model directory.
5. Launch every retained critical workflow and restore a mistakenly removed public model with ollama pull model:tag if needed.

Why you should not delete blobs manually

The blobs directory looks tempting because it exposes very large files, but those filenames are content digests rather than a user-friendly model inventory. A blob can be part of a model you want to retain. Deleting it directly can turn an apparently installed model into a broken one without updating the manifest state that Ollama reports.

Avoid shell one-liners that enumerate every model and pipe all names into ollama rm unless your intention is genuinely to empty the library. Bulk commands remove the review step, make custom and public models look equivalent, and increase the chance that a rarely used production dependency disappears. A short per-model decision log is faster than reconstructing an unknown local setup later.

Do not confuse model cleanup with complete uninstallation. Removing /Applications/Ollama.app does not answer which model data should remain, while deleting ~/.ollama also removes configuration and the whole default library. This guide assumes you will keep using Ollama. A separate uninstall decision should inventory the application, CLI link, models, settings, and integrations together.

Move future models when the startup disk is the problem

If you need most models but the internal SSD is constrained, moving the supported model location is more appropriate than repeatedly deleting and downloading the same weights. Ollama documents OLLAMA_MODELS as the environment variable for selecting another directory. Choose a reliable local disk with enough headroom and a filesystem suitable for large files.

Changing the variable does not by itself prove that existing data moved correctly. Quit dependent apps, copy the model directory with a tool that preserves file integrity, configure the environment for the way the Ollama app or service actually launches, and confirm ollama ls against the new location before removing the old copy. Keep the original until a retained model runs successfully from the destination.

An external disk becomes a runtime dependency. If it is disconnected, renamed, slow, encrypted but locked, or mounted at a different path, Ollama may appear to have no models or may fail to load them. Document the location and keep source assets for custom models separate from the disposable model library.

What AskClean can safely show

AskClean's current Mac scanner recognizes the default ~/.ollama/models library as an AI model-cache category when it reaches the configured size threshold. It reports the entire Ollama model library as one item, assigns the high redownload-cost classification, and leaves it unselected by default. It does not pretend that every model is cheap to replace.

The current scanner does not split Ollama storage into individually named models and does not discover an arbitrary OLLAMA_MODELS location. Use AskClean to reveal that the default library is a major space consumer, then use ollama ls and ollama rm for the per-model decision. If you choose the whole library in AskClean, understand that you are choosing all downloaded models in that default location, not one obsolete model.

AskClean moves ordinary selected filesystem items to the Trash so they can be restored before the Trash is emptied, but application-level consistency still matters. Restoring a manually selected library is not as reliable as removing and pulling models with Ollama's supported commands. For this category, visibility and conservative defaults are more valuable than one-click deletion.

A practical retention policy for local models

Give every retained model an owner and a reason: active daily use, a named project, offline fallback, compatibility testing, or a preserved custom build. Mark public experiments with an expiry date. When a project ends, remove its unused public models after recording the exact names; keep the project's Modelfiles and source assets with the project repository or backup.

Review after upgrades or evaluation rounds rather than on an arbitrary daily schedule. The highest-value cleanup usually comes from superseded sizes, quantizations, or model families accumulated during comparison. Keep the variant that matches current hardware and quality needs, not every candidate downloaded during testing.

Finally, verify the result at three levels: Ollama's inventory, the model directory's disk usage, and the workflows that must still run. That closes the gap between a command reporting success and a Mac actually recovering useful space without losing a hard-to-rebuild local model.

Ollama storage decisions by data type

Model storage is usually replaceable, but replacement cost and custom source material change the decision.

AskClean currently identifies the default Ollama model library as one conservative, unselected item; use Ollama itself for per-model removal.

FAQ