How to choose a coding harness.
The honest answer is that it depends on constraints, and here are the constraints that actually decide it.
There is no single best coding harness, because the choice is decided by constraints rather than by quality: whether your source code may leave the machine, whether you need a specific model, and how much verification your codebase can support. The criteria that actually separate them are model freedom, isolation of failed attempts, context handling, approval granularity and verification. Public harness leaderboards exist and are worth reading, but they benchmark one model on one task set and will not tell you which constraints you have.
Start with the constraint that eliminates options
If source code cannot leave the machine, every hosted harness is out and the question is settled before any feature comparison begins. If you must use a specific model for procurement or contractual reasons, that eliminates a different set. Work out which hard constraint applies first, because it usually reduces a long list to two or three candidates and makes the rest of the comparison cheap.
Verification is the criterion people under-weight
The differentiator that shows up after a month is not generation quality, it is how much of the agent's output can be checked before a human looks at it. Böckeler's framing is useful here: computational sensors like tests and type checks are fast, deterministic and cheap; inferential ones like AI review are slower and non-deterministic. A harness that makes it easy to wire your existing computational checks into the loop saves more human attention than one with better prompts.
Isolation, so a bad attempt costs nothing
Ask where a failed attempt lands. If it lands in your working tree, every speculative run has a cleanup cost and you will run fewer of them. Lucid Train executes dispatched sub-agents in isolated git worktrees and applies the diff back, which means an attempt that goes wrong is discarded rather than reverted.
Context handling under pressure
Every harness works on a small task. What separates them is behaviour near the context limit: whether the conversation compacts automatically, whether there is a recovery path when a provider reports overflow mid-turn, and whether anything persists between sessions. Anthropic's write-up names the failure mode to watch for, context anxiety, where a model starts wrapping up prematurely because it believes it is running out of room.
Where Lucid Train fits
It is model-agnostic, runs fully offline against local Ollama models, executes sub-agents in isolated worktrees, routes roles to different models, reads Claude Code-compatible skill packs, and can drive Claude Code, Codex, Cursor or OpenCode as its engine. It adds a visual architecture surface that generates diagrams from the repository and turns them into implementation specifications. It is not an editor and does not do inline completion.
Criteria that actually separate harnesses
| Criterion | Why it decides things |
|---|---|
| Model freedom | Whether a procurement or privacy constraint rules it out entirely |
| Fully offline | Whether source code may leave the machine at all |
| Isolation | Whether a failed attempt costs cleanup work |
| Verification wiring | How much output is checked before a human reads it |
| Context recovery | Behaviour at the limit, not on a small task |
| Approval granularity | Whether you can grant trust incrementally |
| Skills and portability | Whether your conventions survive switching agents |
| Runs other agents | Whether adopting it forecloses anything |
Questions
Related
- What Is a Coding Harness?Everything in the agent that is not the model. The part you can actually change.
- Harness Engineering vs Context EngineeringOne is a component of the other, and confusing them is why teams optimise the wrong thing.
- Coding Agent vs HarnessAgent equals model plus harness. The harness is the half you control.
- Is Claude Code a Harness?Both, and the confusion is in the question rather than the answer.