HarnessRouter earns its place when your product needs several agent backends
Switching an application between Codex and Claude Code involves more than changing a model name. HarnessRouter's README describes one API for persistent sessions, progress streams, files, cancellation and structured failures across agent harnesses. Those responsibilities are a reason to evaluate an intermediary when your product needs more than one agent backend.
For someone who simply wants an agent in a terminal, this is extra infrastructure. Community Edition includes a Console, Gateway and Runner, plus persistent state. Its appeal is to the application developer who would otherwise implement the same task lifecycle separately for each harness. Our sandbox did not exercise that lifecycle, so the recommendation remains a bounded integration trial.
The documented API is compatible with OpenAI Responses and selects a harness through request metadata. That describes an integration surface, not proof that every harness behaves identically. The README points to a provider support matrix, which should be checked for the particular combination your product needs.
What happened when we ran it
Our sandbox recorded installation success in 28 seconds and build success in 6 seconds at commit b4d53a1 on October 26, 2026. The Python project lives under gateway/. The record lists 78 dependencies occupying 251 MB. Tests exited 1 after 267 seconds, so successful setup did not lead to a passing suite.
The pytest summary reports 1,309 passed, 130 failed, 56 skipped and three collection/setup errors. The record also lists a total of 1,442, which does not reconcile with those categories. We therefore report the categories without presenting a passing fraction. The log's own elapsed time is 260.90 seconds; the outer recorded test step is 267 seconds. These refer to different scopes of elapsed time.
The supplied tail repeatedly says that async def functions are not natively supported. Named failures include session-file fallback and workspace-write durability cases. That is an explicit test-execution limitation visible in this run. The tail does not establish which configuration or package caused it, explain every failure or demonstrate that the corresponding application behavior is defective. We would need the complete failure logs and a supported test setup to resolve those questions.
The pip-audit result reports 136 known vulnerabilities. The supplied block does not identify packages, severity, reachability or fixes, so the count cannot establish exploitability or a remediation plan. It does make dependency review a prerequisite to a production recommendation. We cannot infer that the published container has precisely the same dependency exposure as this source environment.
The configured sandbox had 3 CPUs, 8 GB of RAM and image label ghcr.io/astral-sh/uv:python3.12-bookworm. That label alone establishes neither the actual Python version nor the operating-system version. The checkout contained 914 files, approximately 149,802 source lines and 49.8 MB. The scan found eight CI workflow files and a tests directory but no Dockerfile. The current README's container instructions are a separate deployment route that our scan and run did not validate.
Self-hosting still sends requests to your model provider
Community Edition's README requires Docker and a provider API key, with no HarnessRouter account required. The provider credential authorizes model requests. Product integration uses a separate HarnessRouter API key, issued by the local instance, while the Console has its own sign-in credentials. Keep these distinct when deciding how your backend will authenticate.
The README says provider keys and session state stay under your control, but model requests still go to the configured provider. Self-hosting the gateway therefore does not make inference offline. A team with a requirement that task content never leave its infrastructure must evaluate the provider route as well as the gateway deployment.
The documented quickstart binds the Console to loopback and warns users to change the default password before making the instance accessible. Its named data volume preserves the database, files, installed harness CLIs and workspaces. A useful deployment trial should therefore include a restart and a recovery check for the state your application needs. Neither operation was measured in our sandbox.
Session users are not separate containers
The README explicitly says sessions use separate workspaces and operating-system users rather than separate containers. It also says the entrypoint and Runner need root to manage those users, while the Console and Gateway run unprivileged. Organizations requiring a container boundary for every untrusted task should stop at that architectural distinction and evaluate a suitable deployment model before proceeding.
This is more consequential than the number of available harnesses. An agent can run shell commands and handle files, so the required separation between your users' tasks belongs in the adoption criteria. Our source build provides no independent isolation or credential-redaction validation.
The repository metadata records a push on October 27, 2026, and recent issue activity includes a report about file links opening as missing unless a task is shared. Release v0.37.3, dated October 26, describes fixes for fast-agent MCP addresses and docker-agent skill text. Together these show active changes and reported problems. They do not establish support responsiveness or eliminate the gaps in our run.
A direct agent is simpler when there is only one backend to call
Codex CLI describes itself as OpenAI's coding agent running locally on your computer. Evaluate it directly when that is the agent you need and a shared multi-harness product API adds no benefit. This is a choice of integration scope, not a comparative setup or speed result.
Goose describes a general-purpose agent running on your machine, with a desktop app, CLI and API. Its current repository is aaif-goose/goose. Consider it when you want an agent's own interface instead of operating a router across several harnesses. For HarnessRouter, the next useful proof is a representative task that continues a session, returns a generated file and cancels correctly through your backend, after the test and dependency findings have been investigated.