What an agent harness is, and how to choose yours
A language model, alone, only produces text. What makes it a coding agent is the program around it: the harness. It gives the model tools (read a file, run a command, search), checks permissions, decides what goes into the context and what is compacted, connects to a model provider, and shows you what happens. The same model in two harnesses can be brilliant in one and useless in the other.
What you get. A clear map of the harnesses we use every day and why, and five questions that tell you which one fits a given job. Each has its own installation tutorial.
A bit of history
The first coding assistants (2021 onward) completed lines inside an editor. In 2023, open projects started to let a model call tools in a loop until a task was done. In 2025, the large labs shipped their own terminal agents, and open-source ones multiplied. By then the lesson was clear: the loop, the tools and the context management matter as much as the model. That is why the same lab model can feel very different from one harness to another.
1. What a harness decides for you
- Tools: which actions exist, and how they are described to the model (each description costs context at every turn).
- Permissions: what runs without asking, what waits for your yes, what is refused.
- Context: what the model sees, when old turns are compacted, how big the window is declared.
- Provider: a subscription, an API key, or your own models through a gateway.
- Interface: a terminal, a web page, a phone, or none at all (a queue that works alone).
2. The six we use, and why
| Harness | What sets it apart | Why we use it |
|---|---|---|
| OpenFox | built for local models; acceptance criteria as a contract; web interface; agents, workflows, skills | everyday coding on our own cards, from any device, with our own "fh-coder" agent |
| Claude Code | the most mature loop; hooks that can refuse a command; skills; runs on a subscription or on local models | operations work on the whole lab, and the engine of the unattended junior |
| Kimi Code | one million tokens of context; terminal, web interface and remote control; its own subscription | long tasks that read a lot, and a second hosted agent when the first one's quota runs out |
| FH Coder | not interactive: a queue, a runner, a verification gate, a pull request, a report | work done while nobody watches, with nothing merged unread |
| OpenCode | an open-source terminal agent, independent of any provider, with plugins and skills | installed on both machines; our voice console can drive it as its coding agent |
| Cloudroom core | hosts several harnesses behind one protocol; sessions that move between machines | the base of our rooms, so the phone and the desktop see the same conversations |
3. Five questions to choose
- Which model? Your own cards favour a harness designed for local models; a frontier model favours its lab's own harness.
- Will you watch, or delegate? Watching: an interactive harness. Delegating: a queue with a verification gate.
- How much must it read? A whole repository or a long history: the largest window you can get.
- What may it touch? Unattended work needs a sandbox, a closed list of files, and no credential within reach (see agents and authority).
- Where will you be? On the sofa or on the road: a harness with a web interface or a phone client.
Traps
Declare the real context window in every harness that talks to a local model. Each assumes a large default; when it is wrong, answers stop mid-sentence and the message blames the output limit.
Do not judge a model in the wrong harness. A model that seems unable to call tools in one may be excellent in another that describes the tools in its style.
Sources
Found this useful? Tell us what to measure next.