Local machine learning tools quietly became one of the largest storage consumers on developer Macs, and for a reason that's easy to miss: a single language model checkpoint is routinely several gigabytes, and it's normal to have downloaded four or five while comparing options, only using one or two regularly. Unlike a build cache that rebuilds itself, an ML model is a deliberate download you chose to make — which means cleanup here is less about "is this safe to delete" and more about "do I still want this specific model available locally."
Where each tool actually stores its models
Hugging Face's Transformers and related libraries cache downloaded models at ~/.cache/huggingface/hub, organised into folders per model repository. This is the cache used whenever a Python script calls from_pretrained() on a model identifier — every distinct model and revision you've ever loaded this way accumulates here, and it grows silently in the background of whatever project you're actually working on.
Ollama stores its models under ~/.ollama/models, split into a manifest structure and a blob store where the actual model weights live. Because Ollama's blobs are content-addressed, pulling a new tag of a model you already have can share underlying layers with the existing one rather than duplicating them entirely — similar in spirit to how container image layers work.
LM Studio keeps downloaded models in its own models directory, configurable in the app's settings, defaulting to a location under your user Library or a folder you chose during setup. Because LM Studio is a GUI wrapper around running local models, it typically shows you each downloaded model's size directly in its interface, which makes manual review more straightforward than digging through folders for the other two tools.
Checking what you actually have before deleting
For Hugging Face's cache, the huggingface_hub library ships a command specifically for reviewing and pruning what's stored, which is safer than deleting folders by hand since it understands the cache's internal structure:
pip install -U "huggingface_hub[cli]"
huggingface-cli scan-cache
This lists every cached model, its size, and when it was last accessed, giving you the information needed to decide what to remove without guessing from folder names alone.
For Ollama, ollama list shows every model you have locally along with its size, and ollama rm <model-name> removes a specific one cleanly, which is the right approach rather than deleting files directly from ~/.ollama/models — Ollama's blob-sharing structure means a folder-level delete can leave orphaned or broken references for other models sharing the same underlying blobs.
Deciding what to prune
A few practical signals for whether a locally cached model is worth keeping:
- Have you used it in the last month? Models downloaded to try once and never revisited are the easiest category to remove.
- Is it superseded by a newer version you've since switched to? It's common to accumulate several versions of the same model family (different quantisation levels, different parameter counts) while settling on the one that actually fits your use case and hardware.
- Would re-downloading it be inconvenient? Some models are large enough (double-digit gigabytes) that re-downloading is a real cost in time, which is a legitimate reason to keep one you use only occasionally rather than delete-and-redownload each time.
| Tool | Command to list | Command to remove | Storage location |
|---|---|---|---|
| Hugging Face | huggingface-cli scan-cache |
huggingface-cli delete-cache (interactive) |
~/.cache/huggingface/hub |
| Ollama | ollama list |
ollama rm <model> |
~/.ollama/models |
| LM Studio | In-app model list | In-app delete action | Configurable, check app settings |
Why deleting folders by hand is riskier here than for most caches
Most of the caches discussed elsewhere on this site — npm, pnpm, Homebrew — rebuild automatically and cleanly if you delete them entirely, because the tool re-derives the cache from a lockfile or manifest the next time it's needed. ML model caches don't quite work the same way: deleting ~/.ollama/models wholesale does clear space, but if you're mid-project depending on a specific model, "just re-download it" might mean pulling tens of gigabytes again at an inconvenient moment, and for Hugging Face's blob-sharing structure specifically, manual deletion risks leaving the cache in a state its own tooling doesn't expect. Using each platform's own list-and-remove commands avoids both problems.
Quantisation and why file sizes vary so much for "the same" model
If you've compared model sizes and noticed wildly different figures for what's nominally the same model, quantisation is usually why — a model can be distributed at full precision or at a reduced numerical precision (common labels include Q4, Q5, Q8 in the GGUF ecosystem Ollama and LM Studio both use) that trades some accuracy for a substantially smaller file. When pruning, it's worth checking whether you've accumulated multiple quantisation levels of the same underlying model while experimenting, since keeping just the one you settled on is an easy way to free space without losing capability you're actually using.
A reasonable review cadence
Because these caches grow in large, deliberate jumps (each new model pull) rather than the slow drip of a build cache, checking them monthly is usually sufficient — run huggingface-cli scan-cache or ollama list, glance at what's there, and remove anything from an experiment you've moved past.
Where VolumeLens comes in
Model cache folders show up in VolumeLens sized like any other large directory, which is a useful cross-check against what huggingface-cli scan-cache or ollama list report — if the folder on disk is much larger than what the tool's own listing accounts for, that's worth investigating with the tool's own commands rather than deleting through Finder. VolumeLens's role here is visibility: showing you that ~/.cache/huggingface/hub or ~/.ollama/models has grown, so you know it's time to go prune it with the right tool for the job.