How to Choose a Coding Harness in 2026

Published August 15, 2026 · by the AQ team

Choosing a coding harness in 2026 comes down to four questions: where your model access comes from (a subscription, your own API keys, or local open-weight models), how much built-in workflow you want versus how much you want to shape yourself, whether the specific model and harness pairing actually performs on your repository (published benchmarks will not tell you), and who besides you needs to see the work. This guide walks each question in order, using the harnesses people ask about most as of August 2026: Claude Code, Codex CLI, OpenCode, and Pi.

What a coding harness is (and is not)

A coding harness is the agentic loop wrapped around a model: the system prompt, tool definitions, context management, and retry behavior that turn a raw LLM into a working coding agent. Claude Code, Codex CLI, OpenCode, and Pi are all harnesses. The harness decides what the model sees, which tools it can call, and how failures are retried, which is why two harnesses driving the same model produce visibly different results. (The layer above this one, an environment that runs several harnesses side by side, is a harness of harnesses.)

Question 1: Where does your model access come from?

This is the fastest filter because it is mostly decided for you.

• You already pay for Claude. Claude Code is included in Claude Pro and Max plans as of August 2026, and can also run against an API key with per-token billing. If your model budget is already an Anthropic subscription, this is the path of least resistance.
• You already pay for ChatGPT. Codex CLI is OpenAI's open-source terminal agent; as of August 2026 you sign in with a ChatGPT account (Plus, Pro, Business, Edu, or Enterprise) or an API key. Same logic: the subscription you have points at the harness built for it.
• You want to pick the model per task, or bring your own keys. OpenCode is the most established open-source harness here: it runs in the terminal, an IDE, or a desktop app and connects to any provider with your own API keys, including locally served models, plus an optional low-cost subscription (OpenCode Go, $10 per month as of August 2026) for hosted open-source models.
• You run open-weight models locally. The deciding constraint is tool-call reliability: a local model that emits malformed tool calls stalls the loop no matter how good its code is. OpenCode and Pi both support local endpoints; test your specific model before committing.

One custody note that applies across all four: the harness runs on your machine, but unless you serve the model yourself, prompts containing code context still go to the model provider under its data terms. The own-keys guide covers why key custody matters.

Question 2: How much harness do you want out of the box?

The second axis is philosophical: batteries included versus a kit of parts.

Claude Code and Codex CLI are vendor-tuned appliances. Each is built by a model lab, tuned end-to-end for its own models, and ships opinionated defaults: permission prompts, sandboxing, session management. You get the pairing the lab itself optimizes; the tradeoff is a single vendor's roadmap and models.

OpenCode is the open middle. A full-featured harness (LSP integration, plan and build modes, MCP support) that is open source and model-neutral: most of the appliance experience without the single-vendor bet.

Pi is the minimal end. Pi describes itself as a minimal agent harness: a deliberately small core with a short system prompt, extended through extensions, skills, prompt templates, and packages shared over npm or git. It expects you to build your workflow rather than configure someone else's. If you have strong opinions about context engineering, that is a feature; if you want to type a task and go, it is homework.

A useful heuristic: if the only customization you made to your current tools is the theme, take the appliance. If you maintain dotfiles with commit messages, aim toward the minimal end.

Question 3: Ignore the leaderboard, run the pairing on your repo

Published coding benchmarks measure a model inside a harness, not the model alone, and the harness contribution is large. The Harness-Bench study (arXiv, 2026) measured substantial variation across model and harness pairings on identical tasks, and argued capability should be reported per pairing, not per model. In an August 14, 2026 dev.to postmortem titled "Are you benchmarking the model, or the harness?", what looked like a model's risk-taking behavior turned out to be a harness bug injecting probability estimates into the prompt; fixing the harness cut the measured behavior by a factor of six.

The consequence: a number earned in one harness does not transfer to yours, and two vendors reporting different numbers for the same model are usually measuring their harnesses. So run your own bake-off, on your own repository, and keep it small:

• Pick three real tasks from your backlog: one small fix, one medium feature, one gnarly refactor. Not toy problems: the value of the test is your build system and your weird directory layout.
• Run each task in each candidate harness from the same clean branch, isolated so the runs cannot trample each other (a git worktree per run).
• Score what matters: did it finish without rescue, were the edits clean, how did it recover from failure, what did the run cost, and would you have merged the diff.
• Keep the transcripts. The scrollback is the evidence: where the harness looped, what it read before editing, whether "tests pass" in the summary matches an actual test run. This is session review, and the habit keeps paying after the bake-off ends.

An afternoon of this beats any leaderboard, because it measures the only pairing that matters.

Question 4: Who else needs to see the work?

Every harness above is a single-player terminal program. The session lives in one terminal on one machine, dies with the laptop lid unless you add tmux and a server, 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.

Choosing for yourself, this question costs nothing. Choosing for a team, it reshapes the decision: the harness pick stays per-engineer, and the thing worth standardizing is the layer around the harnesses: isolated checkouts so parallel sessions never collide, sessions that survive laptops, and a way for a second person to open a running session and read it. That layer is what multiplayer coding agents names.

The options at a glance

You do not have to choose once

The answer has a short shelf life. The best pairing changes with every model release, engineers on the same team land on different harnesses for good reasons, and switching costs one login. Treat the harness as a consumable, re-run the bake-off when a major release lands, and put your durable investment in what survives a switch: your repository conventions, your test suite, and the environment your agents run in.

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 guide's terms, AQ makes the harness choice low-stakes: agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, so the bake-off above is just several tabs in one workspace, each in its own isolated git worktree, surviving a closed laptop the whole way.

The team questions this guide raises are the product: 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), workspace visibility is owner-managed (team-visible, or private and shared with specific people), and every session's scrollback is right there for review. Model access stays as described above: each engineer logs into the CLIs with their own Claude or OpenAI account, and AQ never marks up model usage. Agents commit, push, and open PRs 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 your rate locked for your first 12 months.

Plainly: pick your harness with the four questions above, and pick it per engineer. AQ earns its place when the sessions those harnesses produce need to be persistent, isolated, and visible to more than one person.