HarnessRouter

Bring the world's best AI agents into your app, with one API

API

Developer Tools

Artificial Intelligence

Visit WebsiteSee on Product HuntTwitter ⧉LinkedIn ⧉

The durable run identity model makes sense — polling a run id is a much cleaner contract than keeping a WebSocket alive. Curious about the human-in-the-loop gate you mentioned as the next feature: will that surface as an event in the same stream the app already subscribes to, so the approve/reject is just another event the app handles, or does it go through a separate approval channel that requires its own integration?

I like that the output is framed as finished work: files, diffs, images, or actions. That is the part most agent demos skip, but it is exactly what product builders need.

Love the idea of turning Codex and Claude Code into something an app can call through one API. That feels much closer to “AI feature backend” than another chat UI.

Interesting idea. I imagine this is most useful for building stateless apps / artifacts. Is it also possible to build a stateful app with persistent data? If so, where would that data be stored, and could the app interact with my system’s existing persistence layer?

Building sandbox infrastructure from scratch is an absolute sinkhole for dev time.. Congrats @renchu_song 🙌.
quick question are there any plans to open-source parts of the harness or SDK down the road for local self-hosting?

Super curious about the gaming outputs mentioned in the description—what kind of assets or mechanics are agents currently producing with this?

Handling cost control at the agent level is tricky—does HarnessRouter allow setting strict token/cost caps per request or per user?

The agent-session model is what I'd want to understand before building on top of this. When Claude Code or Codex stops mid-task to wait on a tool call or user permission, does HarnessRouter maintain the in-flight state for that run, or does the app need to handle the resume logic itself? Curious how recovery actually looks when a long-running agent crosses a timeout or drops a connection.

one api across agents is a nice pitch but it also means you're now the single point of failure for every app that plugs in. if HarnessRouter itself has an outage or a rate-limit issue on your end, does traffic fail over to hitting the underlying provider directly, or does the whole integration just go down with you? curious how much of the reliability story is actually in your hands vs still tied to whichever agent is behind the call that day.

Huge congratulations to the team! The orchestration and sandbox management headache is real, so this feels super timely.

Love the infrastructure angle.

Curious—do you think the long-term moat is access to many models, or helping developers choose the right one automatically?

Congrats on the launch @renchu_song - I've actually been looking for a product like this for months. Glad someone has finally done it. Looking forward to trying it out!

the eval-suite-gates-the-switch answer to Brandon above is a genuinely satisfying answer, more concrete than most vendor-lock-in claims I see here. question on that - are those eval suites something your team builds and maintains centrally per vertical, or can a customer plug in their own rubric and test cases for their specific use case before they trust a harness swap in production?

@renchu_song Epic launch! One question I had while looking through it: what is the most common mistake teams make when they try to build multi-agent infrastructure on their own before using something like HarnessRouter?

One API across agents solves the problem every team hits by month three, getting locked into a single vendor's agent right when a better one ships. Smart wedge. The place this gets sticky is evals and observability. Whoever owns routing is best positioned to tell me which agent wins for which task, and per-task performance data turns you from a router into the layer teams cannot rip out.

@renchu_song Congratulations!

neat landing page and easy to understand explanation. tho, one question comes to mind: Since different harnesses output varying artifact formats, how does HarnessRouter enforce a consistent schema when returning structured results back to the host app?

Not being locked into one harness is the claim I'd want to poke at, since swapping Claude Code for Codex with one line of config sounds simple, but different harnesses often disagree in how they interpret the same instructions, how they handle tool permissions, and what kind of output they naturally produce. If someone builds their AGENTS.md and their whole prompting approach tuned around Claude Code's habits, does switching the config line actually give equivalent results with Codex, or does it quietly need a rewrite of the instructions to get the same quality out of a different underlying agent. Also, on the healthcare compliance use case specifically, running sandboxed agents against real operational and patient adjacent data raises the obvious question of where that data physically lives during a run and after it finishes. Is anything retained on your infrastructure once a task completes, or does everything get destroyed with the sandbox, since that is usually the first thing a healthcare compliance team will ask before they trust a third party backend with their data.