HarnessRouter Community Edition: One API in Front of Six Agent Harnesses

The integration matrix problem HarnessRouter is built to remove

Every agent harness ships its own invocation model. Codex, Claude Code, Hermes, PI and DSH each expect a different way to start a run, feed it context, collect streamed output and abort mid-flight. A product that wants to offer more than one of them ends up maintaining N integrations against M harnesses, and each integration carries its own session bookkeeping, file handling and error vocabulary. HarnessRouter Community Edition collapses that into one HTTP surface. The README describes it as an "OpenAI Responses-compatible interface" that handles "tasks and runs, sessions, streaming, files, artifacts, cancellation, recovery, structured errors, and traces." The audience is therefore not an individual developer experimenting with a coding agent. It is a team that has already decided to expose agent runs inside a product and wants the harness choice to be a routing decision rather than a rewrite. If you only ever intend to run one harness, the abstraction costs you a container and buys you very little.

What actually sits between your client and the harness CLI

The deployment bundles three named components: Console, Gateway and Runner. The Console is the browser UI on port 3000 where you add provider integrations and start tasks. The Gateway is what your product calls; it presents the OpenAI Responses-compatible API and the Unified Harness Protocol (UHP) described in the repository as "an open standard," with a conformance directory at protocol/conformance/ and a badge claiming full UHP conformance. The Runner is the process that executes harness work. The README states that the container "starts as root to establish per-session users, then runs the product and agents without root privileges," which tells you sessions are isolated by Unix user rather than by container. That is a meaningful design choice: it keeps per-session overhead low and lets one container host many concurrent sessions, but it also means session isolation depends on the correctness of that privilege drop rather than on a hypervisor boundary. State lives in the named volume: the README lists the database, files, installed harness CLIs and workspaces as all persisting there. Provider keys are entered through the Console and, per the README, requests "follow the provider and credentials you choose," so the gateway is not proxying through a HarnessRouter-hosted account.

Getting a first run out of the container

The documented path is a single Docker command: docker run -d --name harnessrouter -p 127.0.0.1:3000:3000 -v harnessrouter:/data harnessrouter/harnessrouter. The README notes you need Docker, roughly 4 GB of disk, and an API key from a supported model provider, and that no HarnessRouter account is required. First boot is slow because the enabled harness CLIs are installed then; you follow progress with docker logs -f harnessrouter and wait for the line "[harnessrouter] ready on :3000". The Console is then at http://localhost:3000 with initial credentials harnessrouter / harnessrouter, and the README is explicit that you should change the password from Profile immediately, noting that saving briefly restarts the Console and signs out other browsers. Two environment variables are named for overriding those credentials: HR_AUTH_USER and HR_AUTH_PASSWORD. The README also warns against adding --user to the Docker command, since the root start is what sets up per-session users. Port 3000 can be remapped, for example -p 127.0.0.1:3100:3000, and the loopback binding should stay in place until the default password is changed. After that, an integration is added under Integrations, and a task is started from Agent harnesses. There is no bundled model or trial key, so nothing runs until you connect a provider.

First boot installs software you did not pin

The most consequential operational detail in the README is that the container installs the supported harness CLIs on first launch. That means the exact version of Codex, Claude Code or Hermes your gateway drives is determined at container start, not at image build. For a self-hosted deployment this is a real supply-chain and reproducibility question: two containers started a week apart from the same image tag can end up with different harness versions, and a harness release that changes CLI flags can break runs without any change on your side. The README points to a self-hosting guide for "version pinning, Docker Compose, and scripted setup," so pinning is possible, but it is not the default path shown in the quickstart. The release history compounds this: v0.15.8, v0.15.9 and v0.15.10 all landed on 2026-09-10, three releases in a single day. A cadence like that suggests active iteration, and it also means you should be deliberate about which tag you run and how you upgrade, rather than tracking the newest image.

Where the abstraction leaks, and when to skip it

A unified protocol is a lowest-common-denominator surface by construction. UHP covers tasks and runs, sessions, streaming, files, artifacts, cancellation, recovery, structured errors and traces, which is a broad set, but anything a specific harness exposes beyond that surface has no obvious place to go in a single API. If your product depends on a harness-specific capability, you will either wait for UHP to model it or bypass the gateway for that path, at which point you are maintaining the integration you adopted HarnessRouter to avoid. There is a second, sharper limitation: the README points UHP at unifiedharnessprotocol.org, and the conformance material lives in protocol/conformance/ in this repository, but the specification itself is not reproduced in the material available here. You cannot verify from the README alone how conflicts between harness behaviours are resolved, what the error taxonomy actually contains, or whether the conformance suite covers cancellation and recovery or only the happy path. Treat the "UHP Full" badge as a claim to test, not a property to assume. Finally, the Console is a browser UI with a default password and a loopback binding; the README's own instruction to keep the instance local until the password is changed is the correct reading of its default security posture.

How this differs from calling provider SDKs directly

The obvious alternative is the direct route: use the OpenAI SDK against OpenAI, the Anthropic SDK against Anthropic, and whatever client each harness vendor publishes, wiring each one into your backend yourself. That approach has no gateway in the request path, no container to operate, no volume holding sessions and files, and no intermediary that sees your provider keys. What it does not have is a common session model. Cancellation, artifact collection and structured errors get reimplemented per provider, and adding a fifth harness means a fifth integration. HarnessRouter's bet is that the shared surface is worth the extra hop. The comparison is genuinely close for a team running one or two harnesses on one provider, and it tilts toward HarnessRouter as the harness count grows or as you want to move a task between harnesses without changing the calling code. The benchmark graphic in the README shows eight Harness x Model configurations on a single recorded task with costs ranging from 0.47 to 223 credits and latencies from 1m 25s to 4m 36s; the surrounding text says cost and latency vary by task. One recorded task is not a basis for predicting your workload, so treat the routing-freedom argument as the reason to adopt, not the cost numbers.

Licence, upgrade cost and what to check before you commit

Community Edition is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notices intact and do not imply endorsement. The README frames this edition as the reference implementation of UHP and distinguishes it from a HarnessRouter-hosted offering; nothing in the supplied material describes a paid tier, seat limit or feature gate on the Community Edition, but the existence of a company site, a Console product and a hosted benchmark page means you should confirm the boundary yourself if your use is commercial. This is not legal advice. On upgrade cost, the practical burden is the combination described above: a fast release cadence, harness CLIs installed at container start, and a persistent volume holding your database and workspaces. Upgrading the image is one command, but validating that the newly installed harness versions still behave against your tasks is work you own. Before deploying, run the conformance suite under protocol/conformance/ against the specific harnesses you plan to enable, pin an image tag rather than pulling latest, and read docs/self-hosting-guide.md for the version-pinning and Compose options the quickstart leaves out.

Editorial conclusion

Adopt HarnessRouter Community Edition if your product already speaks the OpenAI Responses API and you want to swap or add harnesses without rebuilding the backend, provided you can run a Docker container that installs harness CLIs on first boot. Do not adopt it if you need per-harness tuning that the UHP surface does not expose, or if you cannot accept a gateway and its stored sessions sitting between your users and the provider keys. Before committing, verify three things yourself: the conformance suite under protocol/conformance/ against the harnesses you actually intend to run, the pinned image tag and its release cadence, and whether your provider's terms permit routing through a self-hosted intermediary.

Official sources

1. HarnessRouter/harnessrouter on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases