The obvious way to compare two local models is to give them the same instructions. That sounds fair. But a system prompt is also part of the interface between a model and the work it is supposed to do. Different models may react differently to its length and wording.
We tested that directly. Ten local model variants each received thirty controller-decision tasks: the same ten cases written in three operating styles. The task rules stayed fixed. The styles were CONCISE, CURRENT and BLOATED.
The result was useful because the models disagreed.
For operational AI experiments, the public SC Agent Lab shows how we document bounded model and workflow tests without turning them into universal performance promises.
For hardware-first model selection, LLMRadar addresses local model fit. Instruction-profile testing is a separate step in this guide.
What the test measured
The cases asked a model to choose an appropriate next action in an agent workflow. Some required fresh verification, another source, permission handling or checking the result of a write. Others required the agent to recognise that it could not verify a claim or that the user still needed to make a choice.
Temperature was set to zero, the seed to 42, and a strict decision format was used. A common CUDA llama.cpp backend was used where possible. Each model saw thirty prompts, but only ten distinct task types. That distinction matters when deciding how far to generalise.
The experiment tested interaction fit for these controller tasks. Web development, creative writing, image generation and end-to-end autonomous completion were outside this benchmark's scope.
Eight models favoured the shorter instructions
For eight of the ten tested variants, CONCISE was the preferred profile when the team ranked correctness first and prompt-token cost second. The remaining two preferred CURRENT.
Some examples make the trade-off more concrete:
| Tested variant | CONCISE outcome | CURRENT outcome | What we learned |
|---|---|---|---|
| MiMo V2.6 9B | 10/10 | 7/10 | Shorter instructions restored the missed decisions in this fixture |
| OBI / Gemma 12B | 9/10 | 7/10 | Concision improved accuracy but did not remove every error |
| Qwen3.8 27B | 10/10 | 9/10 | Correctness improved; local runtime remained slow |
| Bonsai 2 27B | 9/10 | 10/10 | Removing too much instruction lost an expected decision |
| MiniCPM v4.5 8B | 9/10 | 10/10 | The fuller profile worked better |
All percentages here represent just ten cases per profile. A 100% result means ten out of ten on this particular test, not reliable behaviour across every task.
The short prompt also was not automatically faster. One model with fewer input tokens still had a slightly higher measured response latency. Token savings, inference delay and total task completion must be reported separately.
For a wider, tool-driven task, the real-work landing-page test tests completion rather than instruction selection alone.
The survival challenge records a failure caused by generation-length limits, a separate issue from prompt style.
The ten-model measurement summary lists measured accuracies, prompt-token means and latencies. It is a bounded local test record, not an independently replicated leaderboard.
How to make an operating profile
Start with the exact model file, quantisation, backend and hardware. Use a small, frozen set of the tasks you expect the model to perform. Test at least two instruction profiles without changing the acceptance criteria between runs.
Record which profile causes wrong decisions and which helps. If a short prompt omits essential failure-handling rules, its token savings have no value. If the long prompt adds repeated explanations without changing behaviour, it may waste context and slow work.
A useful profile contains the prompt version, required tool schema, context budget, preferred reasoning mode, observed failure patterns and the benchmark that justifies the choices.
Hardware fit is another question
The 27B Qwen variant answered well under a concise profile but took roughly 1,057 seconds for its thirty-run matrix on the test workstation. A model can be a good decision-maker under the right prompt and still be unsuitable for responsive local work.
Our selection method therefore separates hardware fit, task fit and interaction fit.
The guide to comparing local LLMs explains how to freeze the test fairly. The agent result-verification guide explains why correct model decisions remain different from correct tool outcomes.
Test boundary: Results apply to the recorded 28 September 2026 matrix of ten model variants, ten controller tasks and three prompt profiles. Other versions and tasks require fresh measurements.