SuperQode on the Unified Harness Protocol and HarnessRouter

Coding harnesses have been arriving at a steady pace. Muse Code from Meta, fx from Vercel Labs, and Prime Agent from Prime Intellect all landed in recent months, each with its own loop, its own tools, and its own way of being driven. SuperQode already supports them. The Harness Hub catalogs 103 harnesses and agents across native routes, vendor products, the ACP registry, optional runtimes, model presets, and whatever specs a repository defines for itself. That is the layer SuperQode occupies: a place where harnesses are discovered, built, evaluated, and optimised, rather than a single agent competing with the rest.

Which brings us to HarnessRouter, and a launch we think is genuinely important. They open sourced the Unified Harness Protocol along with a self hosted Community Edition under Apache 2.0. UHP is an HTTP contract for handing a task to a complete agent harness and getting finished work back. A product submits a job, an agent runs inside the server, and results and files return together. The specification covers configuration discovery, task execution, progress streaming, sessions, files, cancellation, and errors, and it ships a runnable conformance suite so a claim of compliance means something specific.

SuperQode now implements UHP as a client. Point it at a conformant server and the harnesses that server runs become selectable routes in the same list as everything else in the Hub.

MCP, ACP, A2A, and now UHP

Protocol support is not new here. SuperQode connects external coding agents over the Agent Client Protocol and can serve a harness as an ACP agent to editors. It connects MCP tool servers and exposes harness workflows as MCP tools. It publishes an A2A Agent Card so other systems can call a SuperQode harness as a peer. Each of those solves a different problem: MCP attaches tools to a loop, A2A connects agents to each other, and ACP connects an agent that owns its own loop.

Underneath them SuperQode has run a harness protocol of its own since early on. It is a versioned contract for how a harness is created, sent a message, resumed, steered, cancelled, checkpointed, and exported, and it is the reason a Codex session, an ACP process, a local model, and a repository defined spec produce one comparable event stream instead of five incompatible ones.

That contract stops at our boundary. It normalises what SuperQode runs, and says nothing about how a product that is not SuperQode should hand work to a harness it does not host. Until now no public specification did either, so integrations in that direction were bilateral: written once, understood by nobody else. UHP is the first shared answer to that specific question, which is why it joins the list rather than replacing anything on it.

What a client gives you

SuperQode speaks UHP 2026-08-11 and sends that version on every request. The protocol version, conformance class, and harness list shown at connect time are read from the server’s discovery document rather than printed from a constant.

Selecting a harness makes it active. Switching to it keeps the session. Streaming deltas, reasoning, tool calls, produced files, and token accounting arrive as the same normalised events every other SuperQode route emits, so a remote run is inspectable through harness events and harness graph exactly like a local one, and it lands in the same evidence store.

Conversations also survive a restart. UHP threads a session with a response identifier rather than a held connection, so SuperQode records that identifier with the session and recovers the thread from the server when local state is gone. A task begun in one process continues correctly in another.

What the server owns

On a UHP run the server owns the harness. It owns the model, the tools, the sandbox, and the working directory. A local HarnessSpec does not govern any of them, and the agent operates in a workspace inside the server rather than in your checkout. A prompt about “this repository” therefore describes somewhere you have never been. SuperQode reports the route as server owned rather than implying otherwise. File upload is defined in the protocol and is not something SuperQode does yet.

Demo

SuperQode running a harness hosted on a HarnessRouter Community Edition container

Run it yourself

Everything below runs against HarnessRouter Community Edition, which is the quickest way to get a real UHP server. The full command surface is documented on the SuperQode UHP page.

1. Start a server

Community Edition serves the protocol under a path prefix rather than at the root, and its console login covers the API, so a local instance needs that gate disabled before a client can reach it. Leave HR_BACKENDS unset.

SHELL
docker pull harnessrouter/harnessrouter

docker run -d --name harnessrouter \
  -p 127.0.0.1:3000:3000 \
  -v harnessrouter:/data \
  -e HR_AUTH_DISABLED=1 \
  harnessrouter/harnessrouter

docker logs -f harnessrouter    # wait for "ready on :3000"

2. Check what it says about itself

The discovery document reports the protocol, the versions the server offers, its conformance class, and the capabilities it declares. SuperQode reads the same document when it connects.

SHELL
curl -s http://127.0.0.1:3000/api/harness/v1/uhp | jq

{
  "object": "uhp.discovery",
  "protocol": "uhp",
  "versions": ["2026-08-11"],
  "default_version": "2026-08-11",
  "conformance_class": "full",
  "capabilities": { "sessions": true, "cancellation": true }
}

3. Add a provider and create a harness

Open http://localhost:3000 and add a model provider key under Integrations. Then create a harness, which is a base, a model, and a name. A server routes only the models in its own catalog, so list them before choosing one.

SHELL
# the models this server can route
curl -s http://127.0.0.1:3000/api/harness/v1/models | jq -r '.backends | keys[]'

# create a harness: a base, a model, a name
curl -s -X POST http://127.0.0.1:3000/api/harness/v1/harnesses \
  -H 'content-type: application/json' \
  -d '{"base":"hermes","name":"Demo","default_model":"YOUR_MODEL"}' | jq

One practical note. Providers that bill in advance reserve the maximum output tokens multiplied by the price per token, then refuse a task whose reservation exceeds the balance. A large reservation on an inexpensive model costs a fraction of a cent, while the same reservation on a premium model costs several hundred times more. Choosing on price rather than on model size avoids nearly every early failure of this kind.

4. Connect SuperQode

Install SuperQode and point it at the server. With a single harness on the server, connecting selects it.

SHELL
uv tool install superqode

superqode connect uhp --base-url http://127.0.0.1:3000/api/harness

Connected:  http://127.0.0.1:3000/api/harness
Protocol:   UHP 2026-08-11 (full)

Harnesses (1):
 * chrn_7f2a91c4   Demo   hermes · your-model

5. Or connect from the terminal interface

The same route is available inside the SuperQode TUI. The connect screen has an entry for agent protocols, which lists ACP, A2A, and UHP. Choosing UHP asks for a server address, lists what came back, and activates the harness you pick. The address field is prefilled with the Community Edition default, so a local container needs no typing.

SUPERQODE
superqode

:connect
   [4] Connect to existing agent protocols
   [3] Unified Harness Protocol (UHP)

:harness switch uhp

> What is the capital of the UK?

6. Run tasks

Once a harness is selected, the uhp route behaves like any other harness in SuperQode.

SHELL
superqode harness protocol list | grep uhp
superqode harness run uhp --prompt "what can you do?" --stream

# continue the same conversation from a separate process
superqode harness run uhp --session work --prompt "read the config"
superqode harness run uhp --session work --prompt "now change the timeout"

Where we see it going

Two pieces of SuperQode sit close to this protocol. HarnessSpec is a portable declarative description of what a harness is configured to be: its tools, sandbox, approvals, and checks, owned and versioned by a repository. HarnessBench measures what changes when only the harness changes, and publishes the manifest, the raw runs, and checksums rather than a headline number.

A wire format decides how a task travels. What a harness is configured to be, and how you establish that one performs better than another, are the questions next door. We would like to work on both alongside the HarnessRouter team.

Conclusion

A public wire format for the harness layer is a good development for everyone building coding agents, and this one arrived with a specification, a reference implementation, and a conformance suite rather than an announcement alone. Congratulations to the HarnessRouter team on the launch. SuperQode supports it today, and we look forward to working closely with them on what comes next and to contributing to the protocol itself.

Give it a try now. SuperQode is open source and the UHP client ships with it.