A prompt a small model can follow is a contract, not a wish
When a 7B model on your laptop mangles a task, the reflex is to blame the model: too small, too quantized, not smart enough. Run the same failure past the checklist below and the diagnosis usually changes. Frontier cloud models fill the gaps in a vague prompt for you. A local model does not. It executes exactly what you wrote, including the parts you left out.
The wish
A wish looks like this: "Summarize these meeting notes." No length, no format, no rule about what to do with action items, no rule about what to do when the notes are ambiguous. A frontier model guesses your intent from context and usually guesses well. A 3B to 13B model picks one interpretation at random per run, drifts mid-output, and invents structure you never asked for. Same prompt, different class of machine.
The contract
A contract states four things, every time, no exceptions:
- The task, in one sentence, with one verb.
- The constraints: what the output must never contain, what to do with edge cases, when to stop.
- The output format, exactly: "three bullet points, each under 20 words, then one line starting with ACTIONS:" beats "a short summary".
- The temperature the task needs, because randomness is a per-task setting, not a model setting.
When output is still bad, tune in this order
Cheapest fix first. Change one variable at a time and re-run the same test prompt.
| Order | Fix | Why here |
|---|---|---|
| 1. Prompt | Rewrite as a contract | Most "model problems" are prompt problems. Free to fix. |
| 2. Temperature | Match it to the task type | Wrong randomness masquerades as stupidity. |
| 3. Context length | Cut input before raising the window | Models forget constraints near the ceiling; bigger context is slower and looser. |
| 4. Quantization | Step up one level | Over-compression costs quality. Q5/Q6 is the 7B to 13B sweet spot. |
| 5. Model | Go bigger | The expensive fix. Only after 1 through 4. |
Temperature is a per-task setting
The one-number-for-everything habit comes from chat apps. In a loop, each step declares its own:
| Task | Temp | Why |
|---|---|---|
| Tool calls, commands | 0.1 to 0.2 | One right answer. Variance is danger. |
| Extraction, validation | 0.1 to 0.3 | Correctness tasks. |
| Code | 0.2 to 0.4 | Loose enough for idiom, never creative. |
| Summaries, rewriting | 0.4 to 0.6 | Needs phrasing freedom. |
| Headlines, brainstorming | 0.7 to 0.9 | Variance is the product. |
Two symptoms cover most cases: a model repeating itself or refusing to continue wants 0.1 to 0.2 more temperature; a model inventing facts or breaking your format wants 0.2 less.
Write the contract once, reuse it forever
None of this is worth doing per prompt, per day. The point of a contract is that it is a file: written once, tested against your model, reused every time the task comes back. A library of tested contracts is the difference between owning a local model and babysitting one.
The free guide below teaches the full pattern: the loop, the stack (LM-Studio, Ollama, oMLX, driven from Pi or OpenCode), and how to write these contracts yourself. As of this week it is a one-click download on Gumroad. If you would rather start from tested parts, the product page also carries the $29 add-on: 56 contract templates across 10 task categories, each with constraints, output format, and temperature already stated, plus a generator that builds custom ones from your tools and limits.
Make a small model on your own machine finish real jobs. The Plan, Act, Observe, Reflect loop, written for LM-Studio, Ollama, and oMLX. No email required.
Get the free guide →