HarnessRouter/harnessrouter

Worth a look if you are building agent features into a product and do not want your backend welded to one vendor's coding harness. It is less compelling if you only need a single harness on a laptop.

The problem

Imagine a product backend that wants to offer an agentic feature—drafting slides, analyzing a data file—using an existing agent loop rather than writing one from scratch. The usual path is to pick DeepSeek Harness, Hermes, PI, Codex or Claude Code, then wire its own session model, streaming format, file handling, cancellation and error paths into your code. When that harness changes shape or your users need a different one, the integration work happens again. HarnessRouter puts a self-hosted server in front of those harness CLIs and exposes one OpenAI Responses-compatible endpoint; you select the backend with metadata.harness_id and keep sessions, streaming, files and cancellation in a single shape. The setup builder in the Console writes the agent's instructions and picks harness, model, skills and tools from a one-sentence brief, leaving an example request to run.

What's different

The mechanism is a router plus an open specification. The project says it implements the Unified Harness Protocol (UHP), with a task interface that stays portable across harnesses, capability discovery so each implementation declares what it does not support, config for harness differences, and extensions such as metadata. In practice, that means your product code talks to one API while the harness underneath is a configuration choice. The Console adds a workspace-level place to attach plugins, skills, MCP servers and environments, and the project ships starter kits to show harnesses as pluggable backends.

A limitation is built into the design: the README says the agent harness is fixed once a setup is saved—using another harness means creating a new setup. The router's structure also means your product inherits the vocabulary and feature surface of the protocol, and the trade-off for uniformity is that harness-specific behavior has to fit through the capability and config layers rather than being used directly. The project's own benchmark graphic claims large cost and latency differences between harness/model configurations on one task, and explicitly notes the cheapest and fastest configurations vary by task; treat that as the author's illustration rather than a serving guarantee. In a Hacker News thread, co-founder Kuanze framed the goal as making harnesses plug-and-play so teams skip rebuilding infrastructure, and in a later reply that same account described a fallback/context-handoff use case. That is the project's stated direction, not independent validation.

Who should try it

Good fit: a backend team that already runs more than one harness, or expects to switch, and wants self-hosted control of provider keys and infrastructure instead of a hosted agent platform. It also suits teams that want to compare harness and model combinations on their own tasks without rewriting their integration per backend. Poor fit: a solo developer who just wants to run Codex locally, or anyone who needs a single harness's exact behavior exposed directly—the fixed-harness-per-setup rule and the protocol layer add distance. If you only need programmatic model calls without agent sessions, a plain provider API is the smaller tool.

Requirements and limitations

You need Docker, roughly 4 GB of disk, and your own provider API key; there is no account, bundled model or trial key. The harness CLIs are installed on first launch and remain under their own upstream licenses, so you must watch which ones the image installs and whether their terms fit your product. The default login is harnessrouter/harnessrouter; the README warns to change it in Profile and keep the instance local until then—because saving briefly restarts the Console and signs out other browsers.

Ongoing upkeep is the bigger cost. The named volume preserves your database, files, installed harness CLIs and workspaces; pulling a newer image does not upgrade a running container, and the upgrade and backup guide is where that procedure lives. Budget time for provider keys, harness CLI churn and the restart that follows configuration changes.

HotRepo's take

HotRepo observed 3,663 stars and +95 in a single daily-board appearance on 2026-10-26; with one recorded date, trend persistence cannot be judged. The HN thread drew 10 points and 14 comments, which shows discussion volume only. Before adopting, check the conformance and protocol material for which harness capabilities the UHP layer actually declares, since that determines how much harness-specific behavior you can keep.