Building, Running, and Sharing Custom Models for Ollama (Modelfile)

Say you want a model that writes git commit messages for you. You hand it a code change, and it hands back a clean commit message.

You can set this up by hand in a single chat session:

# ollama run granite4.1:3b

# Tell the model its job
>>> /set system "You are commitwriter, a model that writes git commit messages. I give you a code change, and you reply with one commit message."

# Make the output steady
>>> /set parameter temperature 0.2

# Give it room to read a long diff
>>> /set parameter num_ctx 8192

# Paste the code change
>>> """
-    def get(self, key):
-        return self._store[key]
+    def get(self, key, default=None):
+        return self._store.get(key, default)
"""

# The model replies
Fix: add default value to get so a missing key no longer raises KeyError

Three settings did the work here:

• The system message told the model what it is and what to do.
• The low temperature made it pick the most likely words and reply with more determinism.
• The larger context window gave it room to read a long diff without cutting it off.

This works. The problem is that none of it sticks. The moment you exit, the session is gone, and next time you run the model, the system message and both parameters are back to their defaults, and you type all three commands again. You repeat the same exact setup every single session.

A Modelfile fixes this! You write the system message, the parameters, and any other details once, in a file, and bake them into a new model. After that the model already knows its job the moment you run it. Nothing to set up, nothing to remember.

(i) A Modelfile is a plain text file. It holds a list of instructions. A Modelfile is to a model what a Dockerfile is to an image: a short text recipe that starts FROM a base and layers your changes on top. The ollama create command reads those instructions and bakes them into a new model that you run like any other.

In this chapter you build a custom model called commitwriter