Local models are some of the largest files on a Mac, often 4 to 40 GB each, and they live in hidden folders. Here is where to find each one.
By MacMonitor · Published · Updated · macOS 26; app requires macOS 14 or later
Short answer: Ollama stores models in ~/.ollama/models, LM Studio in ~/.lmstudio/models (older versions used ~/.cache/lm-studio/models), and Hugging Face downloads in ~/.cache/huggingface/hub. Remove models with each tool's own command so its index stays correct.
| Tool | Default folder | Change it with |
|---|---|---|
| Ollama | ~/.ollama/models | OLLAMA_MODELS environment variable |
| LM Studio | ~/.lmstudio/models | My Models → models directory |
| Hugging Face | ~/.cache/huggingface/hub | HF_HOME environment variable |
Folders that start with a dot are hidden. In Finder press ⇧⌘. to show them, or use Go → Go to Folder.
du -sh ~/.ollama/models ~/.lmstudio/models ~/.cache/huggingface/hub 2>/dev/null# Ollama
ollama list
ollama rm llama3.1:70b
# Hugging Face: inspect the installed CLI and cached repositories
hf cache --help
hf cache lsCurrent Hugging Face Hub releases use hf cache; inspect hf cache rm --help before removing a selected repository. Older releases used huggingface-cli delete-cache. In LM Studio, inspect the configured models directory and delete models from My Models. Deleting Ollama's blob files by hand can leave its manifest pointing at files that no longer exist.
The default paths above answer where common installations begin, but they are not a complete inventory of your Mac. A model manager can use a custom directory, an environment variable can change a cache root, and an older installation can leave a second folder behind. Check the running tool’s configuration before assuming that the largest familiar path is the active one.
In Finder, use Go to Folder and paste the path you verified. A hidden directory is not inherently disposable. Hidden folders are common for command-line tools because they hold configuration and working data outside ordinary document views. Identify the model manager and the specific files it owns before moving or removing anything.
Model weights are only one part of a local AI workflow. Downloads may also include tokenizer files, configuration, multiple revisions, partial transfers and other assets. An application can keep chats, imported documents or settings elsewhere. A model-storage cleanup should not silently become a decision to remove your conversation history or private document library.
Similarly, a model loaded into RAM is not the same as a model stored on disk. Stopping a running model may reduce its active memory use without deleting its downloaded files. Removing the files can require another download later. Decide whether your immediate problem is memory pressure, disk capacity or an application configuration issue.
Suppose you downloaded two versions of a model while comparing quality and responsiveness. This is an illustrative example, not a benchmark. One may be a larger quantization you still use for a particular task; the other may be a smaller version you keep for a constrained machine. A similar model name does not establish that one file is redundant.
Record the exact model identifiers and which workflows use them. If you decide to keep one, remove the other through the owning tool’s supported interface. Then run a simple local task with the retained version. You want to verify the model you kept, not merely celebrate that a folder became smaller.
Some model stores keep references and shared file content separately. Several model entries or revisions can refer to common data. Deleting a large-looking blob by hand can leave a reference pointing at a missing file; counting that same shared content for every entry can also exaggerate potential savings.
This is why the safest general procedure is to inspect and remove through the relevant model manager. In the Hugging Face cache, use the installed CLI’s inspection and dry-run controls before deletion where supported. In Ollama, identify the exact model entry and use its supported removal command. Do not turn a list of blob filenames into a bulk deletion script.
Before relocating models, choose a destination that will be available when the application starts. Check capacity, the drive’s connection and your backup needs. A portable disk can be useful, but a model manager configured to use a disconnected path may fail or download data somewhere unexpected depending on its behavior.
Follow the tool’s documented setting for changing the model directory. Keep the original copy until you have restarted the application, confirmed the configured path and successfully loaded a model from the destination. A successful file copy is only the first part of verifying the move.
Environment variables deserve a careful check on macOS because a GUI application and a Terminal session may not inherit the same environment. If the tool still uses the old location, inspect its documented startup configuration rather than creating several copies in different hidden directories. Keep a note of the setting you changed so you can reverse it.
Downloaded model files can be expensive to recreate in time or bandwidth. If you will work offline, confirm that the model and its required supporting files are present before removing alternatives. Access to a model repository can also depend on an account, accepted terms or a version that remains available.
Do not assume that a filename alone is a complete recovery plan. Record the tool, model identifier and any revision information your workflow depends on. For reproducible development, include the relevant configuration in your project notes without including access tokens or private prompts.
If several entries share data, the space returned may differ from adding their displayed sizes together. Preserve that distinction in any cleanup report. Avoid describing a candidate total as a measured saving unless you actually measured the change in available storage.
No. Inspect My Models and the configured directory, particularly after migrations or a custom setup. Older locations can remain on disk after the active location changes. Determine which installation owns a folder before deciding it is obsolete.
Do not assume so. Application files, models, caches and user data can have separate locations and removal behavior. Check the vendor’s instructions and preserve the information needed to reinstall the models you still want.
In-app installation is not advertised as an implemented capability here. Use your model tool to download or install models. MacMonitor’s supported role is discovery and reviewed cleanup, with permanent-removal consequences clearly separated from Trash recovery.
Tools can display a model entry, a particular revision, a quantization or an underlying shared file. Those are different levels of organization. Compare the exact identifier and the configured store instead of matching only a familiar short name. If two entries appear related, inspect them in the owning tool before declaring one redundant. A smaller file can also be a different representation, so its presence does not establish that it serves the same quality or compatibility requirement as a larger download.
Model Vault finds models from Ollama, LM Studio and the Hugging Face cache in one list, grouped by source, with their real size on disk and when each was last changed. Removing a model is permanent rather than a Trash move, so MacMonitor labels it clearly and asks you to confirm.