A developer recently ran a small experiment that made the rounds this week: give ten different model-and-tool combinations the exact same brief — build a self-contained Three.js scene of a sci-fi hangar with hovering drones, animated lights and volumetric fog — and compare what comes back. The results varied widely, and not only because the models differed. The harness around each model mattered too.

If you use an AI coding assistant, this is worth understanding, because it changes how you should read "which model is best" claims.

What a harness actually is

The model is the engine — the trained network that predicts the next token. The harness is everything wrapped around it to turn it into a working agent: how your conversation history and tool outputs are packed into the context window, when older results get trimmed, which tools it can call, how retries and errors are handled, and what system instructions it carries. Claude Code, Cursor, and the various open coding agents are all harnesses. Two of them driving the same model are not the same product.

The evidence: same model, very different results

This isn't just vibes. A 2026 paper, Same Model, Different Harness, isolated the effect by holding one model fixed and changing only the harness. On SWE-bench Verified — a standard set of real GitHub issues — under a tight context budget, a single harness change (mechanically shortening older tool results as the context window fills, instead of carrying the full history) raised the number of fully-solved tasks from 43 to 72 out of 169 — a jump from roughly 25% to 43%. A finer-grained measure — the share of the required failing tests the agent managed to flip to passing — rose from 28% to 49% alongside it. Same weights. Same problems. Only the scaffolding changed.

The authors' conclusion is the practical one: coding-agent evaluations "should treat the model and harness together as the tested solver." In other words, capability lives in the combination, not the model alone.

What this means for you

• Read leaderboards with a grain of salt. A benchmark score is really a score for a model in a particular harness. The same model in a better-engineered agent can beat a "stronger" model in a weaker one.
• Your setup is a variable you control. How your tool manages context, which tools it exposes, and how it handles long sessions can move your real-world results substantially — by some comparisons, as much as switching models — and often more cheaply.
• When something works well, note the whole combination, not just the model name. "Model X is great for refactoring" is only half the sentence; the harness is the other half.

None of this means models don't matter — a stronger model still helps. But if your AI is underperforming on a coding task, the fix may not be a bigger model. It may be a better harness — and increasingly, that is where a lot of the real gains are being found. It's the same lesson that surfaced when Anthropic rewrote Claude Code's system prompt: the wrapper around the model is doing more of the work than it gets credit for.