Last month we released the SuperQode UHP client, which turned harnesses hosted on a remote server into selectable routes alongside everything else in the Harness Hub. The next step was to build the other side of the protocol. SuperQode now serves the Unified Harness Protocol as well as speaking it: it passes the published conformance suite at class core with 40 of 40 checks and no skips, and there is a public host at uhp.superqode.dev you can query right now.
superqode serve uhp binds one configured HarnessSpec and puts it on the wire. It is a native harness answering as a harness, not a multi-backend runner, and it is complementary to HarnessRouter. HarnessRouter puts many existing harnesses behind the contract; serve uhp makes SuperQode's own harness callable by anything that speaks it, HarnessRouter included. Both sides moved to the current protocol version in the same release, and the client drops to the previous one by itself when it meets a server that does not serve the newer, so nothing you already connect to breaks.
The public host
Discovery is unauthenticated by design, because a client needs to know whether it is talking to a UHP server before it can sensibly present credentials. The host serves both the current protocol version and the previous one from a single code path, so a client written against either works without negotiation failing.
# Discovery is open. No credential, no model call.
curl -s https://uhp.superqode.dev/v1/uhp | jq
{
"protocol": "uhp",
"versions": ["2026-09-12", "2026-08-11"],
"conformance_class": "core",
"implementation": { "name": "superqode", "version": "2.3.1" }
}Running a task is different. The host holds no model key of its own and never has, so inference is paid for by the caller using a Gemini key from Google AI Studio. A bearer alone will not run anything, and the refusal says exactly that. Send both and a real harness runs: it reads files, writes them, and remembers what it did when you continue the session. Warm responses take about three seconds.
export SUPERQODE_UHP_API_KEY=... # issued on request, see below
export GEMINI_API_KEY=... # yours, from aistudio.google.com
superqode connect uhp --base-url https://uhp.superqode.dev
superqode harness run uhp --prompt "review this repository"Discovery needs no credential, which is what lets a client learn what it is talking to before presenting one. Everything else on the host, the harness catalog included, needs a bearer, which we issue on request through GitHub Discussions while the host is a pilot. Nothing in the next section needs it: a local server is one command and reaches the same protocol surface.
The header carrying that model key is a SuperQode extension. UHP does not define it, so a stock client cannot run a task against this host today. We are raising it as a specification proposal with the HarnessRouter team instead of leaving a private extension in the ecosystem.
Demo video
Running a harness on uhp.superqode.dev with a caller-supplied Gemini key
Serve your own
The public host runs a deliberately lean harness, but the same command serves any HarnessSpec you own, with your tools, your sandbox policy and your working directory, and any UHP client can then drive it. A harness you have configured and version alongside your code becomes something another product can hand work to, without that product knowing anything about SuperQode. Serving needs FastAPI and uvicorn, which live in their own uhp extra, and the client side needs neither.
A local bind is single-user, so it also serves session listing, inspection and turn history, letting you find a session you did not record and rebuild its transcript from the server. The public host reports that capability as false and declines those routes, because one bearer shared by every caller would make a session listing expose everyone's work. Each session there gets its own directory instead, so callers cannot read each other's files.
uv tool install 'superqode[uhp]'
superqode serve uhp --spec harness.yaml --port 8787 \
--provider google --model gemini-flash-latest --working-dir ./work
Serving SuperQode UHP 2026-09-12 on http://127.0.0.1:8787
Discovery: /v1/uhp · harness: chrn_demo · class: coreConformance
The specification is direct about what the word means: a server is conformant at a class when it passes the conformance suite at that class, and nothing else counts, not a self-assessment and not an implementation of the endpoints. The suite ships in the same repository as the spec, runs against any server over HTTP, and executes real agent tasks, because the defects worth catching are invisible to anything that only inspects a schema. Cancellation is one example. Ours returned success and left the agent running, which on a host paid for by the caller means a cancelled task keeps spending their key. Both cancel routes now stop the work and wait for it to be over before answering.
scripts/run_uhp_conformance.sh
Summary
40/40 passed · 0 failed · 0 skipped · 0 errored
CONFORMANT (core)The suite treats a skip as something it did not establish and marks any run containing one as not conformant, so a clean result requires zero of them. Reaching that took more than implementing the endpoints. Reading the specification next to the suite turned up six requirements with no check behind them, covering session expiry, model substitution, request budgets, idempotent retries and identifier formats, and all six were wrong in our server before they were right. The script above reproduces the whole run, and the report is checked into the repository so the number is not something you have to take on trust.
Looking ahead
Class Extended needs one more piece, artifact retrieval, which we have deliberately held back: serving files an agent produced is a surface that deserves its own review, not a quiet addition to a release. Beyond that sit harness lifecycle management, session sharing and the Plugins chapter, all reported honestly as unimplemented in the discovery document so a client can tell what it is talking to.
Two questions sit upstream of our own roadmap. A public bind whose operator will not pay for inference has no way to say so in the protocol today, and harness identifiers are scoped to the server that issued them, which leaves a catalog spanning several servers without a way to name anything. We intend to raise both with the HarnessRouter team as specification proposals.
All of this is in SuperQode 2.3.1, on PyPI now. Try it: it is open source, and the UHP client and server both ship with it.