What is a coding harness?

Published August 16, 2026 · by the AQ team

A coding harness is the software wrapped around a language model that turns it into a working coding agent: the system prompt, tool definitions, context management, execution loop, and failure handling that decide what the model sees, which actions it can take, and how its work gets checked. Claude Code, Codex CLI, OpenCode, and Pi are all coding harnesses. The model supplies the reasoning; the harness supplies everything that turns reasoning into edited files, executed commands, and pull requests. The distinction stopped being pedantic in 2026, when publishing benchmark results per harness became normal because the same model scores differently depending on the harness driving it.

Where the term comes from

The name is borrowed from the test harness, a decades-old idea in software engineering: a fixture that runs code under controlled conditions, feeds it inputs, and observes what it does. An agent harness does the same job for a model. It gives the model a controlled environment (a working directory, a set of tools, permission rules), feeds it a task, and runs the observe-act-retry loop until the task is done or abandoned.

Through 2025 the layer went by many names: scaffolding, wrapper, agent framework. Harness won in 2026, and two publications mark the mainstreaming. In early 2026, OpenAI published "Harness engineering: leveraging Codex in an agent-first world," describing a three-person team that shipped a production beta of roughly one million lines of code and 1,500 merged pull requests over five months without hand-writing the code, by investing in the environment around the agents instead of in the code itself. In July 2026, Lilian Weng's essay "Harness Engineering for Self-Improvement" defined the harness as the layer for tool use, planning, context, artifacts, and evals, and argued that progress toward self-improving AI runs through that layer before it runs through model weights. Between those two posts, the word settled: the harness is a first-class engineering artifact, not glue code.

What a harness actually contains

Implementations differ, but a working coding harness answers the same set of questions, and its parts map to them:

• The system prompt. The standing instructions that set the agent's behavior: how cautious to be, when to ask, what style of change to make. Vendor harnesses treat theirs as core IP.
• Tool definitions. What the model is allowed to do to the world: read and edit files, run shell commands, search the repository, call external services. The tool surface is the agent's entire reach.
• Context management. What enters the model's limited window and what gets summarized or dropped as a long session grows. Two harnesses reading the same repository can show the model very different slices of it.
• The loop. The cycle of act, observe output, decide next step. Loop control decides when the agent keeps going, when it retries a failed command, and when it stops.
• Permissions and guardrails. What requires human approval, what runs sandboxed, what is refused outright.
• Failure handling and verification. What a malformed tool call, a failing test, or a crashed build does to the run: a retry, a replan, or a stall. This is where harnesses differ most and where "same model, different results" usually comes from.

The harness is not the model

The cleanest evidence that the harness is a separate, load-bearing layer is that it now shows up in measurements. The Harness-Bench study (arXiv, 2026) ran 106 sandboxed tasks across 5,194 execution trajectories, varying the harness while holding tasks and budgets fixed, and found substantial variation in completion, process quality, efficiency, and failure behavior across model and harness pairings; its conclusion is that agent capability should be reported per pairing, not attributed to the base model alone. Model labs already behave this way: Z.ai's August 2026 launch materials for GLM-5.3 report Terminal-Bench results measured inside the Claude Code harness, with the harness version pinned in the footnotes.

The practical consequence: a benchmark number earned in one harness does not transfer to yours, and when two vendors report different numbers for the same model, the harnesses are usually what differ. The harness chooser guide covers how to run a small bake-off on your own repository instead of reading leaderboards.

Coding harnesses in the wild

The harnesses people mean when they use the word, as of August 2026:

What a coding harness is not

• Not an agentic development environment. An ADE is a workspace built around delegating tasks to agents and reviewing the results; the harness is the agent runtime an ADE runs inside itself. One is the engine, the other is the vehicle.
• Not an agentic IDE. Cursor and Windsurf are editors with agent modes inside them. The harness is present there too, but embedded in an editor-first product rather than exposed as the primary surface.
• Not a harness of harnesses. That is the layer above: an environment that runs several stock harnesses side by side and adds what none of them provides alone, like isolation between sessions and shared visibility.
• Not harness engineering. Harness engineering is the practice: designing the environment, feedback, and verification around agents (the subject of the OpenAI and Lilian Weng posts above). The harness is the artifact the practice produces and tunes.

Why the harness layer decides agent quality

Four decisions the harness owns explain most of the quality gap between agents running the same model. What the model sees: context selection determines whether the agent reads the right files before editing. What a failure does: a malformed tool call or failing test can trigger a clean retry or a silent stall. When the loop stops: too eager and tasks come back half done, too persistent and the agent burns an afternoon on a dead end. And what counts as done: whether "tests pass" in the summary is backed by an actual test run. A model upgrade shifts all four a little; a harness change can shift them completely.

Where the team layer fits

Every harness in the table above is, by default, a single-player terminal program: the session lives in one terminal on one machine and is invisible to everyone else. That default has measurable consequences: a July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular GitHub repositories found that in 79 percent of agentic PRs the same developer both reviewed and modified the agent's contribution, and only about one in eight workflows involved multiple humans. The harness solves the loop around one model; it does not solve isolation between parallel sessions, persistence beyond a laptop, or a second person seeing the work. That layer has its own vocabulary: multiplayer coding agents for the category, harness of harnesses for the architecture.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this page's terms, AQ does not replace your coding harness; it runs the stock ones. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser, so a session survives a closed laptop and resumes from any device. Each workspace is one isolated git worktree, so parallel harness sessions never trample each other, and teammates open the same workspace and watch the same live session (typing into someone else's terminal happens only after its owner approves a control request in one click).

The harness choice stays per engineer: everyone signs into the CLIs with their own Claude or OpenAI account, AQ never marks up model usage, and agents commit, push, and open pull requests with per-user GitHub auth. Pricing is two plans: Free is a personal sandbox for one person (AQ creates a private machine in an isolated network, nothing to install, no time limit), and Team is $50 per user per month in early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, with the rate locked for your first 12 months.

Plainly: the harness is the layer you should pick per engineer and re-pick as models change. AQ is the layer above it, and it earns its place when harness sessions need to be persistent, isolated, and visible to more than one person.