The most underrated job in the house is the one your smallest model can do
Every conversation about local LLMs eventually wanders into horsepower: which quantisation, how many billion parameters, whether the GPU can hold the whole context window. Meanwhile the workload that small models are genuinely best at — not “adequate despite their size”, but actually better suited than the big ones — sits quietly in every writer’s workflow: proofreading.
The case was put well in a piece on XDA where a journalist swapped their cloud writing assistant for a small model running on modest hardware, and I think the underlying idea deserves to be generalised across home labs and small businesses: constrained, boring, high-volume text jobs belong on small local models. Not because it’s cheaper — it is — but because the failure modes of a big model are exactly the failure modes you’re trying to avoid.
The problem with “writing assistants” is that they write
Grammar tools have spent the last few years drifting from checker to co-author. Flag a typo, and along comes the suggestion to restructure the paragraph, formalise the tone, and compress three sentences into one nobody would say out loud. If you’ve ever had a document come back sounding like a press release for itself, you know the mode. The tool stopped asking “is this correct?” and started asking “could this be more impressive?”
Here’s the twist: a small local model is largely immune to this, because ambition is a function of capability. A 3–4B parameter model doesn’t have the confidence to restructure your argument. Asked to fix what’s broken and leave the rest, it does mostly that. The model that can’t write a brilliant essay is also the model that won’t try to rewrite yours. What you want from a proofreader is a careful reader with a red pen, not a ghostwriter — and the red pen role is where the small models live.
The setup is smaller than you think
This job does not need the GPU you don’t own. A Qwen, Gemma or Llama model in the 3–4B class runs comfortably on:
- the mini-PC or NAS already running your containers,
- a 8–16GB laptop through Ollama or LM Studio,
- even a recent phone, if you’re curious.
Latency tolerance is the hidden advantage. Nobody cares if proofreading takes four seconds — there’s no chat stream to keep snappy, no autocomplete racing the typist. You paste, you wait, you diff. The job has no egos in it.
The part that actually matters is the prompt. Proofreading quality is mostly a contract about restraint, and it needs to be explicit:
proof() {
ollama run qwen3:4b "$(cat <<'EOF'
You are a proofreader. Fix only: typos, duplicated words,
grammar errors, and phrasing that is genuinely ambiguous.
Do not rewrite sentences that are already correct. Do not
change tone, structure or word choice. Return the full text
with the smallest possible number of edits, then list the
changes you made in one line each.
EOF
)" "$1"
}Two details in that prompt are doing real work. “Smallest possible number of edits” turns restraint into a measurable instruction. And “list the changes” means you review a diff instead of trusting a rewrite — which is the entire safety model. Never paste-blind-accept; make the model show its work.
Why local isn’t just a preference here
For individuals, running this locally is nice. For a small business, it’s close to mandatory. The documents that most need a second pair of eyes — quotes, tender responses, client emails, anything under NDA — are precisely the documents you should not be shipping to a third-party API for a typo fix. Cloud AI terms change, retention policies change, and “we pasted the tender document into a chatbot” is not a sentence anyone wants to explain in a security review.
The same privacy argument applies to the homelab journal, the incident postmortem, the email to the accountant. Proofreading is high-touch, low-stakes, repetitive work on sensitive text — the exact shape of workload that should never leave the LAN. Run the model on hardware you own, on a network you control, and the question of where your drafts go answers itself: nowhere.
Give the boring jobs to the small models
There’s a habit worth building from this: match model size to job stakes. Big models for reasoning, synthesis, anything where a wrong answer compounds. Small local models for the high-volume, low-stakes, sensitive-text jobs — proofreading, summarising your own notes, reformatting, extracting structure. Those jobs don’t need brilliance; they need consistency and containment.
The writing stays yours. That’s not a limitation of the setup — it’s the design goal.