What a harness is

The biggest secret of local LLMs: the model is not the product, the harness is. A harness is the wrapper around the model that gives it tools, memory, context management and a workflow. The same model is a toy in a bare chat box and a real worker inside a good harness.

Why the wrapper beats the model

Ask a bare model to "fix this bug in my repo." It cannot see your repo, cannot run tests, cannot read files. It guesses, confidently. Now put the same model inside a harness that:

loads the relevant files into context,
lets the model run commands and read their output,
keeps a plan and a todo list,
compacts the context before it overflows.

Now the same model actually does the task. The difference is not the model, it is the harness. This is why "harness maxxing" is a real term and the most repeated lesson in the community.

What a harness does

Context management — deciding what goes into the window, and summarising or compacting before it fills.
Tool access — letting the model read files, run commands, search, and call APIs, with the results fed back.
Memory and state — keeping a plan, notes and progress across turns, so the model does not restart from zero.
Guardrails — scoping what the model may touch, and requiring approval for anything dangerous.

The scale

Simple — a script that formats a prompt and prints the answer.
Agentic — tools, plans, multi-step loops (Cline, OpenCode, Hermes and similar).
Purpose-built — the custom harnesses people write for their own business, which is where the real value lives.

The takeaway

Stop asking "which model is best" as the first question. The first question is "what harness will this model live in." The catalog records exactly this: the setups that ship real work all describe their harness, and the ones that stay toys usually do not.