Updated · Sources & corrections
In this guide
Use Ollama’s model-management command to remove an installed tag. Deleting a model, unloading it from memory and uninstalling the application are separate operations. Confirm which result you need before removing files.
List the installed tags
ollama listCopy the complete name, including its tag. The name in your installation may differ from an example in a tutorial. Make a note of any custom Modelfile or settings you would need to recreate the model.
Remove one model
ollama rm llama3.2:3b
ollama listThe first line is an example: replace it with the exact installed tag you intend to remove. The second line verifies that the tag is no longer listed. Removing a tag is not a measured guarantee of a particular number of gigabytes reclaimed; stored layers can be shared and the underlying filesystem can affect the free-space reading.
Check disk space separately
On Windows PowerShell, inspect the relevant drive:
Get-PSDrive -PSProvider FileSystem | Select-Object Name, Used, FreeOn macOS/Linux, inspect the filesystem holding the model directory:
df -hThese commands report filesystem capacity rather than model ownership. If free space does not change as expected, confirm the actual configured model directory and other tags that may use the same data. Do not remove individual blob files from a working shared store.
Removing several models
Review the list first and remove selected tags explicitly. A loop that removes every listed model is a bulk-deletion operation and should not be the default cleanup recommendation. Keep the installation and any other users of the model service in mind before deleting an entire data directory.
Unloading is different
A model can be installed on disk without being loaded in memory. ollama ps reports loaded models; ollama list reports installed ones. If the problem is GPU memory rather than disk, first check the running-model view and your requested context/model size.
Full uninstallation
Use the application’s normal uninstaller or the official platform-specific removal instructions. A desktop app, a package-manager installation, a container and a systemd service have different removal steps. Confirm the installation method before deleting binaries or service users. Preserve any custom configurations you need.
Related: where Ollama stores models, diagnosing connection and memory issues and the setup guide.
Sources and verification scope
This is a documentation-based guide. Command outputs and configuration examples are illustrative unless explicitly identified as recorded test results. Check the installed version and platform; a successful syntax check does not establish hardware compatibility.
Editorial update, 21 October 2026: source references and verification scope added; identified command, feature or wording errors corrected. Read our sourcing and correction policy.
Choose the operation before changing anything
The official CLI reference lists model removal and stopping as separate commands. Use the result you need to choose between them:
| Goal | Inspect first | Appropriate next step |
|---|---|---|
| Release a model loaded in memory | ollama ps | Stop that running model; keep its installed tag if you still need it. |
| Remove a selected installed model | ollama list | Remove the exact reviewed tag and check the list again. |
| Keep every model but free the system drive | The actual model location and destination capacity | Use the separate storage-migration workflow, with a retained source copy. |
| Remove the entire application | The installation method and configurations to preserve | Use the platform’s uninstallation procedure; this is broader than tag removal. |
To stop an example loaded model, replace the tag below with one you actually intend to unload. Then recheck the running-model view:
ollama stop llama3.2:3b
ollama ps
The running-model API documentation describes the corresponding loaded-model view. Absence there is evidence about memory residency, not deletion of the installed library. A later application request can load an installed model again.
Verify tag removal and capacity as separate observations
Before removing a tag, note the server you are connected to, the exact name, the configured model directory and the free space on the filesystem holding that directory. Preserve any custom model definition you need. On a shared server, coordinate with the people who use that tag.
After removal, check the same server’s installed list and the same filesystem. Use this record to avoid confusing an endpoint change or another drive with a successful capacity check:
Illustrative cleanup record — fill from your actual observations
Server endpoint / installation:
Configured model directory:
Filesystem or drive measured:
Exact tag selected:
Custom definition preserved:
Free space before:
Removal result or error:
Tag listed afterward:
Free space afterward:
Other active downloads or writes:
| Observation | Next check |
|---|---|
| Removal reports model not found | Copy the exact installed tag and confirm the client reaches the intended server. |
| Tag disappears, capacity differs from its listed size | Measure the correct filesystem and inspect other tags and concurrent disk activity; do not infer corruption from that difference alone. |
| Tag appears again later | Check whether a frontend, script or user pulled or recreated it after removal. |
| Command cannot connect | Repair reachability before interpreting it as a removal result. |
| The frontend still shows the old list | Compare its saved endpoint and refresh its model view; do not delete files to fix a stale interface. |
Changing a tag list and recovering filesystem capacity are related but different checks. Avoid an automatic delete-everything loop when one selected model will meet the goal. If you need to keep the library, follow the copy-and-verify storage guide. If the server address differs between applications, use our frontend connection checks.
Editorial update, 25 October 2026: added the operation decision table, unload example and separate endpoint/tag/capacity verification record. Examples are illustrative; command syntax was checked locally without removing or unloading a real model. No amount of recovered space is claimed.