Lock In a Local Model's Behavior With a Modelfile

Ask a general-purpose local model to "only answer homework questions by guiding, never giving the answer directly," and it might comply — for one message. Start a new chat, and the instruction is gone. If you want a rule that sticks every time, you don't put it in the chat. You put it in a Modelfile.

The problem with chat-only instructions

A system prompt typed into a chat window lives only in that session. Close the window, switch devices, or let someone else use the same model, and the rule disappears. For anything you want to reuse — a support bot that won't wander off-topic, a homework helper that won't just hand out answers, an assistant with a fixed persona — retyping instructions every time isn't a workflow, it's a chore waiting to be skipped.

Why a Modelfile fixes it

Ollama lets you define a new model on top of an existing one using a small text file called a Modelfile. It specifies a base model plus a system prompt (and optionally other parameters), and once you build it, the result is a real, separately-named model on your machine — not a chat setting, a model. Anyone who runs that name gets the rules baked in, every time, with zero setup.

How to do it

1. Create a file named Modelfile (no extension) anywhere on disk.
2. Add two lines to start:

   FROM llama2
   SYSTEM "You are a homework helper. Guide the student toward the answer with hints and questions. Never give the final answer directly."

   FROM picks the base model already available via Ollama. SYSTEM is the instruction applied to every conversation with this new model, automatically.
3. Build the model: ollama create homework-helper -f Modelfile. This registers homework-helper as its own model name, backed by llama2 plus your system prompt.
4. Run it like any other model: ollama run homework-helper. No need to paste instructions again — the rule is compiled in.
5. Clean up when you're done. ollama rm homework-helper removes the custom model without touching the base model it was built from.

Where this fits

• A homework helper that guides instead of giving answers outright.
• A support bot that stays on-topic and won't improvise outside its scope.
• A character or persona assistant that keeps a consistent voice across sessions, instead of drifting once the system prompt scrolls out of context.
• Shared or family setups, where you want to hand someone a model that behaves a specific way without trusting them to type the right instructions themselves.

Pitfalls

• A system prompt is guidance, not a hard sandbox. A determined user can still push a model off its instructions with the right prompt — Modelfiles set default behavior, they don't enforce a security boundary. Don't rely on one for anything safety-critical.
• The base model still matters. A Modelfile changes behavior on top of a model, not its underlying knowledge or capability — pick a base model that's actually good at the task before layering rules on it.
• Rebuilding overwrites, it doesn't merge. If you ollama create again with the same name, the new Modelfile fully replaces the old definition.

Power tricks

• You can set generation parameters like temperature inside the same Modelfile, alongside the system prompt — for example, a lower temperature for a rule-following support bot, or higher for a more creative persona.
• On a shared or family server, whitelist which model(s) a given user account can access, so only the constrained custom model — not the raw base model — is available to them.
• Keep your Modelfiles under version control alongside the rest of your project; they're just text, so treat "the assistant's rules" the same way you'd treat any other config you don't want to lose.

Resources

• ollama.com — model library and docs
• Ollama Modelfile reference