A model returns text. The harness is the program that decides what happens to that text — run it as a command, paste it into a file, or throw it away and ask again.
That is why two products built on the same model feel different, and why a benchmark names the harness it used.
The four jobs
It runs the tools. The model cannot execute a shell command. It can only write one and ask. The harness executes it and returns the output as the next message.
It keeps the loop going. Read a file, edit it, run the tests, read the failure, edit again. Each step is a full round trip, and the harness is what counts the steps and decides when to stop.
It manages the context. Every tool result spends window. Anthropic's engineering post on context engineering describes the window as a budget rather than a bucket: more tokens is not automatically better, and summarising the history is part of the job.
It enforces the permissions. Which commands may run without asking, which files may be written, whether the agent can reach the network. That is not a model behaviour. It is a policy in the program around it.
Why benchmarks name the harness
Anthropic's Opus 5.5 results footnote says the public Terminal-Bench leaderboard runs five trials per task with the Claude Code harness, and that its own setup reproduced a published Opus 5 score at 29.0% against 30.0% on the leaderboard. Same model, same test, slightly different rig, different number.
The consequence for you
When someone says a model is good at coding, ask which harness, which tools, and how many attempts. A model with a shell and a test suite beats a better model with neither.
The harness is also where your costs live: every loop iteration re-sends the conversation, so a harness that retries five times costs five times as much.