Once you have Ollama running and a few models downloaded, you’ll spend a surprising amount of time managing those models — pulling new ones, removing ones you no longer use, checking what’s loaded, switching between versions. The Ollama CLI has a clean set of commands for all of this, and knowing them well saves you time and disk space. This guide covers every model management command with practical examples of when and how to use each.
Pulling Models
ollama pull downloads a model from the Ollama library without running it. Use this when you want to pre-download a model before you need it, or when you want to update an existing model to the latest version.
# Pull the default version of a model
ollama pull llama3.2
# Pull a specific size variant
ollama pull llama3.1:8b
ollama pull llama3.1:70b
# Pull a specific quantization
ollama pull llama3.1:8b-instruct-q4_K_M
ollama pull llama3.1:8b-instruct-q8_0
# Pull to update an existing model to the latest version
ollama pull mistralRunning ollama pull on a model you already have checks whether a newer version is available. If the remote version matches what you have, it confirms this and downloads nothing. If a newer version exists, it downloads only the changed layers — similar to how Docker handles image updates. This makes re-pulling efficient even for large models.
Download progress is shown as a progress bar with the current layer being downloaded. Pulls can be interrupted and resumed — if your connection drops mid-download, just run the same ollama pull command again and it picks up where it left off.
Listing Downloaded Models
ollama list shows every model currently on your machine:
ollama listOutput looks like this:
NAME ID SIZE MODIFIED
llama3.2:latest a80c4f17acd5 2.0 GB 3 days ago
llama3.1:8b 42182419e950 4.7 GB 2 weeks ago
mistral:latest f974a74358d6 4.1 GB 1 month ago
qwen2.5-coder:7b 2b3c43b07c27 4.7 GB 5 days ago
phi4:latest f2816b0cc8c5 8.9 GB 1 week agoThe list shows the model name and tag, a short ID, size on disk, and when it was last modified. This is your starting point for managing disk usage — sort through what you have and identify models you no longer use regularly.
There’s no built-in sort flag, but you can pipe to sort:
# Sort by size (requires awk + sort, Linux/macOS)
ollama list | awk 'NR>1' | sort -k4 -hRunning Models
ollama run loads a model and starts an interactive chat session. If the model isn’t already downloaded, it pulls it first:
ollama run llama3.2
ollama run mistral "What is the capital of France?" # non-interactive, single prompt
ollama run phi4 --verbose # show timing and GPU layer infoPassing a prompt directly after the model name runs it in non-interactive mode — Ollama generates the response and exits. This is useful for scripting:
# Use in a shell script
RESPONSE=$(ollama run llama3.2 "Summarise this in one sentence: $TEXT")
echo "$RESPONSE"Checking What’s Currently Loaded
ollama ps shows which models are currently loaded in memory:
ollama psNAME ID SIZE PROCESSOR UNTIL
llama3.2:latest a80c4f17acd5 3.1 GB 100% GPU 4 minutes from nowThe output shows the model name, memory footprint, whether it’s running on GPU or CPU, and when it will be unloaded (based on OLLAMA_KEEP_ALIVE). If nothing is loaded, the output is empty. This is useful for checking GPU utilisation and for confirming a model has unloaded before trying to load a larger one on constrained hardware.
Removing Models
ollama rm deletes a model and frees its disk space:
ollama rm llama3.2
ollama rm llama3.1:8b
ollama rm codellama:34bAlways specify the tag when removing — ollama rm llama3.1 removes the latest tag, but if you have multiple variants like llama3.1:8b and llama3.1:70b, you need to remove each explicitly. Removal is immediate and permanent — there’s no recycle bin or recovery, so be sure before you delete a large model.
After removing models, verify the space was freed:
ollama list # confirm the model is gone
du -sh ~/.ollama/models # check total remaining sizeFigure 1 — Ollama Model Management Commands
Inspecting Model Details
ollama show displays detailed information about a specific model — parameters, context length, quantization format, and the Modelfile it was built from:
ollama show llama3.2Output includes:
Model
arch llama
parameters 3.2B
context length 131072
embedding length 3072
quantization Q4_K_M
Capabilities
completion
tools
System
[system prompt if any]
License
META LLAMA 3 COMMUNITY LICENSE AGREEMENTThis is useful for checking what quantization a model is using (before deciding whether to download a different version), what context length it supports, and whether it has tool-calling capability. If you have multiple variants of the same model downloaded, ollama show helps you confirm which is which before deciding which to keep.
Understanding Model Tags and Versions
Model names in Ollama follow a name:tag format, similar to Docker. The tag specifies which version or variant you want:
llama3.2 # equivalent to llama3.2:latest
llama3.1:8b # 8B parameter version
llama3.1:70b # 70B parameter version
llama3.1:8b-q4_0 # 8B with specific Q4 quantization
llama3.1:8b-instruct-q8_0 # 8B instruct with Q8 quantizationThe :latest tag points to the model’s recommended default — usually the best quality/size trade-off for most hardware. Specific quantization tags give you precise control over which file you download. You can see all available tags for a model at ollama.com/library/modelname — each tag is listed with its size and a description of the quantization format.
When you have multiple tags of the same base model, they appear as separate entries in ollama list:
llama3.1:8b a4b9f7c1d3e2 4.7 GB 2 weeks ago
llama3.1:8b-q8_0 b5c8d2e4f1a3 8.5 GB 1 week ago
llama3.1:70b c6d9e3f5g2b4 43.0 GB 3 days agoEach tag is stored independently — removing one doesn’t affect the others. The blob storage under the hood deduplicates shared model layers, so if two tags share base weights, they don’t double the disk usage. But quantization variants have different weight files and don’t share blobs, so keeping Q4 and Q8 of the same model costs you the full size of both.
Copying and Renaming Models
ollama cp creates a copy of a model under a new name. This is primarily used to create aliases or to base a custom Modelfile on an existing model:
# Create an alias
ollama cp llama3.2 my-assistant
# Create a base for customisation
ollama cp llama3.2 coding-assistant
# Then create a Modelfile that builds on coding-assistantThe copy shares the underlying blob files with the original — it doesn’t duplicate the full model on disk, just creates a new manifest pointing to the same files. This means copies are free in terms of disk space until you start building custom variants on top of them.
Creating Custom Models with Modelfiles
A Modelfile lets you build a custom model variant — typically used to bake in a system prompt, set default parameters, or combine a base model with a custom adapter. Here’s a minimal example:
# Create a Modelfile
cat > Modelfile << 'EOF'
FROM llama3.2
SYSTEM "You are a concise technical assistant. Give direct answers without preamble. Use code examples where relevant."
PARAMETER temperature 0.3
PARAMETER num_ctx 8192
EOF
# Build the custom model
ollama create my-tech-assistant -f Modelfile
# Run it
ollama run my-tech-assistantCustom models created with ollama create appear in ollama list alongside pulled models and can be removed with ollama rm like any other. The FROM directive points to the base model — changing the system prompt or parameters doesn't download anything new, it just creates a new manifest on top of the existing model blobs.
Figure 2 — Common Quantization Tags and What They Mean
Keeping Your Model Library Organised
A few habits keep your model library tidy over time. Only keep models you've actually used in the last month — it's easy to pull "just to try it" and forget to clean up. Run ollama list and use modification dates as a guide for what to cut. For models you use regularly, consider keeping just one quantization variant per model rather than multiple — Q4_K_M is the right default for almost everyone, and keeping both Q4 and Q8 of the same model rarely provides enough quality benefit to justify double the storage. If you switch between different use cases (coding, writing, reasoning), it's worth keeping one specialist model for each rather than a large library of general models — four well-chosen models you use daily beat twenty that you cycle through randomly. And when new versions of models are released (Llama 4, Qwen 3, etc.), remove the old version after confirming the new one meets your needs rather than accumulating multiple generations of the same model family.
The ollama CLI is intentionally minimal — there's no bulk-delete or search command. For power users managing large model libraries, a short shell script that pipes ollama list output to a selection menu (using fzf on Linux/macOS) gives you an interactive model browser and batch-delete capability that the CLI doesn't provide natively. But for most users, the handful of commands above cover everything needed to keep a clean, efficient local model library.
Managing Models via the API
Everything the CLI does is also available through Ollama's REST API, which is useful if you're managing models programmatically — building a tool that auto-pulls required models before running a job, or checking model availability in a script before starting inference. The key endpoints:
import requests
base = 'http://localhost:11434'
# List all models
models = requests.get(f'{base}/api/tags').json()
for m in models['models']:
print(f"{m['name']} — {m['size'] / 1e9:.1f} GB")
# Pull a model (streams progress)
import json
with requests.post(f'{base}/api/pull', json={'name': 'phi4'}, stream=True) as r:
for line in r.iter_lines():
if line:
print(json.loads(line).get('status', ''))
# Delete a model
requests.delete(f'{base}/api/delete', json={'name': 'codellama:34b'})
# Show model info
info = requests.post(f'{base}/api/show', json={'name': 'llama3.2'}).json()
print(info['modelinfo'])The API-based pull streams status updates as the download progresses — each line is a JSON object with a status field showing the current operation (pulling manifest, pulling layer, verifying digest, success). This is how tools like Open WebUI show download progress in the UI. The delete endpoint is permanent and immediate, same as the CLI — no confirmation prompt, so build that into your tooling if you're automating deletions. The tags endpoint is the authoritative source for what's installed — it returns richer metadata than ollama list including the full model digest, family, parameter size, and quantization level for each model.
Pulling Models with Specific Parameters
Beyond the standard quantization tags in the library, you can also import GGUF model files from external sources directly into Ollama using a Modelfile with a local file path in the FROM directive. This is useful for models not in the official Ollama library, or for custom quantizations you've created yourself:
# Import a GGUF file from disk
cat > Modelfile << 'EOF'
FROM /path/to/your/model.gguf
SYSTEM "You are a helpful assistant."
EOF
ollama create my-custom-model -f Modelfile
ollama run my-custom-modelThis workflow lets you use any GGUF-format model with Ollama, not just those in the official library. Hugging Face hosts thousands of community-quantized GGUF models — download the file, point a Modelfile at it, and it becomes a first-class Ollama model you can run, list, and manage with the same commands as library models. After importing, Ollama copies the GGUF file into its blob storage, so the original file can be deleted once the import completes.
The import process supports any GGUF file regardless of its origin — original Meta weights, community requantizations, fine-tuned variants, or models converted from SafeTensors format. Ollama's model management layer handles them all identically once imported, giving you a unified interface for both official library models and custom imports.