A Great Harness Is All You Need
An F1-inspired race car merging with an AI coding terminal, symbolizing the importance of the harness.
The fastest engine still needs a car that can put its power on the track.
In my opinion, Max Verstappen is the best driver on the Formula 1 grid right now. And yet he did not win the 2025 championship. The driver who did was Lando Norris, whose McLaren was the class of the field across the 2024 and 2025 seasons.
That outcome shaped how I think about AI coding tools. Being the best driver does not guarantee anything if the car cannot deliver. Put a weaker driver in the fastest car and a stronger driver in an uncompetitive one, and the faster car wins more often than not, because the performance gap in modern F1 is mostly machinery, not talent. The same logic applies to large language models: you can take the most powerful model available and watch it lose to a cheaper, weaker model if the harness around it is worse. The model is the engine; the harness is the rest of the car.
What a harness actually is
First, a definition. A harness is everything that wraps around a model when it does real work: the system instructions that shape its behavior, the way context and memory are managed across a long session, the tool interfaces it can call, how the repository is indexed and searched, the permissions it is granted, the planning mechanisms it uses, whether it can spawn subagents, and the feedback loops and verification steps that check its output.
The model is the driver. The harness decides what the driver can see, what it remembers from earlier laps, and what it is allowed to touch. Two setups running the exact same model can produce wildly different results because everything except the model is different. Once I understood that, the way I evaluated tools changed completely.
Three ways people drive these models
This grouping is my own, not an industry standard: a continuum I have observed in how people actually work, from hands-on editing to hands-off autonomy.
1. Agentic IDEs and editor-integrated assistants
This is where most people start: GitHub Copilot in VS Code, Cursor, Windsurf, and Kiro. The common thread is that the human stays close to the code. The assistant suggests, completes, or edits, but the developer reviews nearly every change as it happens and keeps their hands on the keyboard. It is supervised work, and the human's attention is part of the throughput equation.
2. Terminal coding agents
A step further along the continuum are terminal-native agents: Claude Code, Codex CLI, OpenCode, Gemini CLI, and omp. Here the workflow shifts from editing to directing. You state a goal, the agent proposes a plan, and you supervise through feedback loops rather than line-by-line edits. The agent works the repository through tools, reading files, running commands, and applying structured edits, while you review plans and diffs instead of individual keystrokes.
3. Autonomous and personal-agent harnesses
At the far end sit autonomous and personal-agent harnesses like Hermes Agent and OpenClaw. These are long-running workflows with much broader permissions: agents that operate for hours, chain tasks together, and act across systems rather than inside a single repository. This group is also the most diverse in outcomes. Some people hand an agent vague instructions and burn tokens on noise; others genuinely build businesses on top of well-tuned autonomous workflows. The outcome rarely hinges on the model. It hinges on whether the operator set explicit boundaries, monitoring, and clear objectives. The more freedom you grant, the more the harness's guardrails matter.
How I moved through all three
I started with GitHub Copilot in VS Code about two years ago, then moved to Cursor, and eventually left agentic IDEs behind entirely. My reason was personal, not universal: for the tasks I was delegating, I found the models reliable enough that my own manual implementation and line-by-line supervision had become the bottleneck. Auditing every suggested edit was slowing me down more than writing the code myself would have. That is my experience, not a law of nature, but it pushed me to look for a harness built around goals instead of edits.
That search led me to OpenCode, a model-agnostic terminal harness that let me plug in whichever model subscriptions I already had. The shift in focus was immediate. Instead of thinking about the small stuff, I could think about what I wanted to build. My workflow settled into a shape I still use: write a scratchpad document describing the goal, throw in the stack I want, and let the agent's plan mode produce an implementation plan that I review before anything gets built.
For months, that loop ran on two tiers of models. I would plan with an expensive frontier model, hand the implementation to a cost-effective model to keep development fast and cheap, and then ask a strong model to review and audit the result. Planning, execution, and review each got the model that fit the job and the budget.
Then I found omp, a batteries-included terminal agent, and (call me exaggerating) the leap from OpenCode to omp felt as large as the original leap from agentic IDEs to terminal agents. The tool calls stopped breaking mid-task. Time to first token (TTFT) was noticeably better than the official harnesses I compared it against. The planning tools were more detailed and consistent. Its LSP and DAP integration means the agent navigates and debugs code the way an IDE does: jumping to real definitions, following references, and setting breakpoints instead of guessing from text search. Subagents let it fan out independent work in parallel, plan mode separates thinking from doing, persistent memory carries context across sessions, and structured edits apply changes surgically rather than rewriting whole files.
None of that made the model smarter. It made the model's existing intelligence usable.
None of this removes the human from the loop either. I still own the requirements, the architecture tradeoffs, the security review, and the final acceptance of anything that ships. The harness moved my attention from the keyboard to the decisions. It did not eliminate them.
The benchmark evidence: same model, different harness, different score
If you want hard evidence that harnesses move results, look at ARC-AGI-3, an interactive benchmark where agents explore unfamiliar 2D games with no instructions. Success demands learning an unknown environment, planning over long horizons, compressing memory as the session grows, and adapting strategy on the fly. These are exactly the capabilities a harness either supports or destroys.
When Anthropic launched Opus 5, its announcement claimed the model led the ARC-AGI-3 standings with a score three times the next best model. Anthropic's framing, on Anthropic's eval run.
Anthropic chart plotting ARC-AGI-3 score against evaluation cost, with Opus 5 leading Opus 4.8 and GPT-5.6 Sol.
Source: Anthropic on X.
OpenAI published a case study. With the official ARC-AGI-3 harness, their GPT-5.6 Sol model scored 13.3% on the public task set. When they enabled two harness-level settings they use in production, retained reasoning across turns and context compaction instead of rolling truncation, the same model scored 38.3%. The article reports roughly 3× the score with 6× fewer output tokens. Nothing about the model changed. The official harness was discarding the model's private reasoning after every action and truncating older history, so the model was forced to re-derive the game from scratch each turn. Retaining reasoning and compacting context gave it a memory, and the score tripled.
OpenAI title card: How enabling two settings tripled our scores on the ARC-AGI-3 benchmark.
Source: OpenAI — How enabling two settings tripled our scores on the ARC-AGI-3 benchmark.
OpenAI diagram comparing reasoning, tool calls, and context handling over a long task.
Source: OpenAI — How enabling two settings tripled our scores on the ARC-AGI-3 benchmark.
Prime Intellect took the idea further with Prime Agent, a harness built around a Recursive Language Model (RLM) approach. Running Opus 5 inside it, Prime Agent achieved 95.5% RHAE Best@1, where RHAE (Relative Human Action Efficiency) compares model performance against a human baseline. The Prime Agent announcement reports three runs of 95.0, 95.2, and 95.5. A model that scored in the low double digits under one harness scored near the human ceiling under another.
Prime Intellect chart of ARC-AGI-3 test-time compute scaling, with Prime Agent plus Opus 5 reaching 95.5 percent against a 95.4 percent human baseline.
Source: Prime Intellect on X.
These are vendor-reported evaluations, each run with a different harness and setup, so read them as demonstrations of harness sensitivity, not as a clean model leaderboard. If the harness were a neutral wrapper, the scores would not move like this.
The author of omp then re-ran the same benchmark with Opus 5 inside his own terminal harness and reported 97.4%, edging out even Prime Agent's number on the same chart. The same caveat applies: self-reported, different setup, no independent verification. But as demonstrations of harness sensitivity go, a personal terminal harness outscoring a purpose-built evaluation harness is about as vivid as it gets.
Chart comparing Prime Agent and omp, both running Opus 5 on ARC-AGI-3, with omp scoring 97.4 percent.
Source: @_can1357 on X.
What I actually optimize for now
I believe today's models are good enough for most of what I want to build. The bottleneck now is how I use the model: how memory is managed, how tools are called, how the project is indexed, and how work is verified. So I stopped chasing model names and started optimizing the system. My checklist:
- Choose the harness for the workflow. Hands-on editing, supervised terminal work, and autonomous operation are different jobs. Pick the tool built for the one you are doing.
- Preserve useful context. Retained reasoning, compaction, and memory are not luxuries. An agent that forgets its own thinking re-learns the same lesson every turn, and you pay for it in tokens and quality.
- Demand reliable tools and verification. Broken tool calls and unverified edits silently tax every task. Structured edits, LSP-grade navigation, and review loops pay for themselves.
- Assign specialized models by phase and cost. Plan with a strong frontier model, implement with a cost-effective one, review with a strong one. You do not need the most expensive model for every step.
- Optimize the full system, not the model name. The leaderboard ranking of your model matters less than what your harness lets that model see, remember, and do.
Back to Formula 1. Buying the strongest engine on the grid is not a strategy if the chassis, the aero, and the pit wall cannot transfer that power to the track. The teams that win championships build the whole car. Build the whole harness.