HN Explorer

Show HN: HarnessRouter: Unified interface for agent harnesses (github.com)

2 points by songrenchu ↗ HN
Hey HN! We are building HarnessRouter, a canonical API for running Codex, Claude Code, Hermes, and other managed agent harnesses as your product backend.

Before building HarnessRouter, I used to build our own agent harness for our products. I tried LangGraph, agent SDKs from different vendors, pydantic, LLM tool use / function call, and so on. It's a very heavy lifting engineering effort, and I am disappointed about the agent deliveries compared to what Codex, CC can deliver. That changed my mindset. The frontier labs and famous open source communities are already putting so much engineering effort to build the world's best harnesses, why not leverage them directly instead of building our own, just like how we call LLM chat completion endpoints instead of training our own models?

We provide a docker image to run HarnessRouter locally.

----------

Quickstart:

    docker pull harnessrouter/harnessrouter

    docker run -d --name harnessrouter -p 127.0.0.1:3000:3000 -v harnessrouter:/data harnessrouter/harnessrouter

    docker logs -f harnessrouter

    Wait for the "ready on :3000" show up, then open the browser at http://localhost:3000.
    Default username/password is harnessrouter/harnessrouter

    Then in Integrations page, add your model provider credentials or API keys.
    In Harnesses tab, as of today we provide routing to Codex, Claude Code, and Hermes as base harnesses.
    You can customize any of them and configure harness instruction, MCP tools, and skills.

    Then go to Tasks and let them do jobs.
----------

Every harness has its own request/response format and incompatible with each other. We propose Unified Harness Procotol [1] to standardize how an application talks to an agent harness. It covers harness selection and configuration, task execution, event streaming, sessions start cancel and resume, artifact management and delivery, and failure handling. It's similar idea like LiteLLM, but for harnesses rather than models.

HarnessRouter implements UHP. We provide an AGENTS.md [2] and your coding agent can follow it to integrate your application with the harnesses available.

We also provide starter kits [3] to demonstrate some types of agentic products that can be built on HarnessRouter. It currently includes PPT agent, Spreadsheet agent, BI Dashboard agent, and Video generation agent.

Can't wait to hear what you think!

[1] https://unifiedharnessprotocol.org

[2] https://harnessrouter.ai/agents.md

[3] https://github.com/harnessrouter/starter-kit

18 comments

[ 4.5 ms ] story [ 60.5 ms ] thread
kuanzema
Here's Kuanze, co-founder of HarnessRouter. Before building HarnessRouter, I was building an entire harness to power other products. Building a harness was pretty fun for me. I enjoyed and learned quite a lot through building it.

However, Richard asked me a question: how do you plan to keep up with the iteration speed of harnesses like Codex and Claude code. That question leads to the solution that we are delivering to the community today.

From our perspective, the agent harness is becoming an independent infra layer, and it should become a dev tool. Our goal is to make agent harnesses plug-and-play solution for all developers, so they can skip rebuilding the infra layer and focus on shipping product features.

We welcome all comments, feedbacks, protocol contributions, and feature suggestions.

Bnjoroge
What’s the pitch for a harness router?iirc codex has codex app server, pi also has a reusable core.
songrenchu
Think of it as OpenRouter, but for different agent harnesses, not models. Instead of sticking to any one harness, you can route to and use any of them through a unified API
kuanzema
On top of that, in HarnessRouter cloud: we provide developers with seamless deployment for their serveless, managed agents in sandboxes that can scale at anytime; and tracing insights so they can pick the best Harness × Model × Tools × Skills combination based on production performance. In one benchmark, one combination is 99.8% cheaper, and one combination is 3.2× faster. Check out the benchmark here: https://harnessrouter.ai/benchmarks
Bnjoroge
right, that part makes sense. The part i'm a little confused on is what the utility is for actually routing across harnesses. Is the point that most harnesses have been co-trained with models thus perform the best in the native harnesses?
songrenchu
The router sits between application layer and the harness layer. HarnessRouter is the spec translation layer that translates the unified interface into each harness's own api format. Each harness is treating somehow like a blackbox, and they talk to the models as is. For routing across harnesses, think about it as an aggregator, like OpenRouter. The application layer have multiple use cases and each function could backed by a different harness. We do have smart routing feature on our roadmap to support use cases of harness fallback, cost optimization, etc
Bnjoroge
I appreciate that, but unfortunately I'm still unclear why I need to route across multiple (coding) agent harnesses vs just sticking with one(omp).
songrenchu
You are right, for coding scenario, I also stick with one (CC in my case, really got disappointed at codex during gpt-5.4 time and never came back since then)

Where we need HarnessRouter is package the harness agent as part of the product backend to serve the end users. In that scenario, the harness needs specific instructions, MCP tools, skills pre-configured, so it can reliably receive requests from upstream product service and deliver result to downstream product components.

We put 4 demo agent products for white collar working scenarios: PPT agent, Spreadsheet agent, Bi Dashboard agent, Video editing agent. Each of them is backed by a different harness setup. Video editing is most sophisticated so it's CC + Opus 5. The other 3 are more simpler use cases so default setup in the kit is set to Hermes + DeepSeep V4 Pro.

Take the PPT agent use case, for sure we can hook the same tools and skills to local Claude Code or Codex, but it only works for yourself using it locally. If you are building a AI PPT product (like Gamma), you need to host the harness setup somewhere in the cloud together with other product code. That's when you can use HarnessRouter as the PPT generation/manipulation component of the product, with the chosen harness backed in. For sure you can build the same harness wrapper plumbing as we did in HarnessRouter to make the same stack work, but using HarnessRouter the development time is shorten as we have already get the nitty gritty engineering details covered

Bnjoroge
ah gotcha! For non-coding use cases I see the value/utility. Thanks, good luck!
kuanzema
On top of that, in HarnessRouter cloud: we provide developers with seamless deployment for their serveless, managed agents in sandboxes that can scale at anytime; and tracing insights so they can pick the best Harness × Model × Tools × Skills combination based on production performance. In one benchmark, one combination is 99.8% cheaper, and one combination is 3.2× faster.

Check out the benchmark here: https://harnessrouter.ai/benchmarks

kiops
How does this handle harness-specific features without becoming a lowest-common-denominator API?
[deleted]
(comment deleted)
ltononro
This could benefit from a agent handoff protocol where it can communicate and continue different workflows once your tokens are done or a model couldnt achieve what you expect.
songrenchu
Yes, these two are good use cases. With no harness lock-in, a fallback and context handoff can solve LLM vendor service unreliable. Loop engineering can also be done for achieving long horizon goals a single harness loop struggles to close
songrenchu
We added 4 things to remediate lowest common denominator. The first is task interface, it is portable cross harnesses. Second is capability discovery. Each implemenation needs to specify capabilities it doesn't support. Third is config that captures harness differences. Last is extensions like metadata and extra fields.