Choose theme
AI Resources
HarnessRouter
HarnessRouter Community Edition lets an application send work to different agent harnesses through one API, then follow progress and retrieve the results and files.
A harness is the runtime around a model: it runs the agent loop and tools that do the work. HarnessRouter connects products to runtimes such as Codex, Claude Code and Hermes, with a self-hosted Console for configuring and following tasks. Use this as a first read, not a recommendation. Open the original project before trusting details like terms, limits, privacy, cost, setup, or safety.
What it is
One interface for running agent tasks
The API covers task execution, persistent sessions, streaming, input files, generated outputs, cancellation and structured failures. Its Unified Harness Protocol, or UHP, defines the shared contract between the application and supported harnesses.
Why it stands out
Change the agent behind the integration
An application can select a harness through the request metadata while keeping the same task interface. The harness still supplies its own execution behavior; a common API does not make every harness and model combination equally capable.
Availability
Self-host with Docker and your provider keys
Community Edition includes the Console, Gateway and Runner in one Docker deployment and declares Apache-2.0. The quickstart needs Docker, disk space and a model-provider API key, without a HarnessRouter account. Managed HarnessRouter Cloud is a separate deployment choice.
Why it matters
What makes it useful
A product that asks an agent to prepare a document or change code needs more than a final message. It needs to show progress, accept files, keep a conversation going and return what the agent made. HarnessRouter exposes those operations through a shared API. A follow-up can use previous_response_id to continue the session, so an app can ask for a revision in the existing work context instead of treating every request as a fresh job.
What to know
Where it fits
Your product backend calls the Community Edition instance; the Console is also a place to configure harnesses and run tasks directly. The Gateway handles the API and lifecycle, while the Runner starts harness CLIs in session workspaces. Model requests still go to the provider you configure. The Console password, provider API key and instance-issued API key have separate jobs: sign-in, model access and product integration.
Notable points
What stands out
The common task interface leaves room for differences underneath. The project publishes a support matrix that records first turns, follow-ups, model switches, produced files and recovery after a sandbox is recycled for particular harness/provider/model combinations. Some scenarios fail or are not run. That makes the exact combination relevant when choosing a backend; a harness name appearing in the project is not evidence that every provider path supports the same workflow.
Before using
What to review
The Docker setup downloads and installs enabled harness CLIs on first launch. Community Edition does not bundle a model or trial key; model access, provider charges and supported combinations depend on your connections.
Self-hosted sessions use separate workspaces and operating-system users inside one container, rather than a separate container for each session. The entrypoint and Runner retain root privileges to manage those users. Agents can run shell commands and use the tools and credentials supplied to them.
The security policy says to keep the instance off public networks until a password is set and TLS is in front of it. The Console can run tasks and read transcripts; its deployment boundary matters as well as the agent workspace.
The v0.38.0 release changes remote MCP credential handling: the server keeps the remote address and credentials while a session receives a local relay and a token limited to the turn. Its release notes say older sessions, checkpoints and Git history retain existing credential copies, and recommend rotating MCP tokens if an agent you do not fully trust has run on that instance.
The same release adds a generated encryption key when HR_SECRET_KEY is absent. The notes explain that keeping this key beside the data protects a copy of the secret store, not a copy of the whole volume, and describe how to keep the existing key separately. The setup guide also says an agent can use what it receives during a turn; stdio MCP values and harness environment variables remain readable to it.
Reader fit
Who may find it relevant
Developers adding agent work to an application and wanting task progress, follow-ups and file outputs through a common integration.
Teams comparing supported harness/provider combinations on their own work while operating the Community Edition deployment themselves.
Less suitable for someone seeking a ready-to-use personal assistant with no deployment or provider setup, or identical behavior across every backend.
Editorial note
Why LifeHubber lists it
We list HarnessRouter because its shared interface accounts for the practical problem of retrying agent work. Its documented Idempotency-Key behavior returns the existing result when the same request is retried with the same key, rather than starting another execution. For a product that asks an agent to create files or run commands, a delayed response should not make a request retry into a second job. This connects the common API to a concrete integration need: distinguishing a retry of work already accepted from an instruction to do new work.
Source links
Source materials
Reader note
Before relying on this entry
LifeHubber lists entries to help readers inspect AI projects, not to endorse them or prove they are safe, suitable, accurate, maintained, or right for a specific use. We do not verify every entry in depth. Before relying on anything listed, review the original materials, terms, privacy practices, limits, and risks that matter for your situation.
More in AI Agents
Keep browsing this category
Explore more AI agent projects.
Paperclip
paperclipai/paperclip
A self-hosted server and dashboard for coordinating agent teams through companies, goals, roles, issues, heartbeats, budgets, approvals, and persistent activity records.
Eigent
eigent-ai/eigent
A CAMEL-based desktop workspace for single-agent and specialist-workforce tasks across files, browsers and connected services, with visible task activity and separate backend choices.
LiveKit Agents
livekit/agents
A realtime framework for voice, video, and physical AI agents, with Python and Node.js paths, LiveKit room participants, WebRTC clients, telephony support, tools, testing, and deployment options.
For project maintainers
Listed here? You can use the badge.
If you maintain a project with a current LifeHubber listing, you may add the optional “Listed on LifeHubber AI Resources” badge to its README, docs, or website. No introduction or permission request is needed.
