Table of Contents
Here’s a trap that’ll bite you exactly once with Ollama: if you run ollama create using the same name as an existing model, it overwrites the original. No warning, no confirmation, just gone.
The Scenario
Say you pulled mistral:7b-instruct and want to customize it with a new system prompt or different parameters. You write a Modelfile:
FROM mistral:7b-instruct
SYSTEM "You are a code reviewer..."
PARAMETER temperature 0.3
Then you run:
ollama create mistral:7b-instruct -f Modelfile
Congratulations, you just replaced your base model. The original mistral:7b-instruct is now your customized version. Want the vanilla one back? Time to re-pull it.
The Fix
Always use a distinct tag name for your customizations:
# Copy the base first (shares blobs, no extra disk)
ollama cp mistral:7b-instruct mistral:7b-instruct-base
# Create your custom version with a NEW name
ollama create mistral:7b-code-reviewer -f Modelfile
The ollama cp command shares the underlying blobs with the original, so it doesn’t double your disk usage. It’s basically free insurance.
Naming Convention That Works
I’ve settled on this pattern: base-model:size-purpose
ollama list
# mistral:7b-instruct 4.4 GB (original)
# mistral:7b-code-reviewer 4.4 GB (custom)
# mistral:7b-instruct-base 4.4 GB (safety copy)
# qwen2.5-coder:7b 4.7 GB (original)
The sizes look alarming but remember: copies share blobs. Actual disk usage is much lower than the sum suggests.
Why This Matters
When you’re iterating on Modelfile configs (tweaking temperature, system prompts, context length), you’ll run ollama create dozens of times. One slip with the wrong name and you’re re-downloading 4+ GB. Use distinct tags from the start and you’ll never have that problem.

Leave a Reply