HarnessRouter is an open-source unified interface that lets product teams plug Codex, Claude Code, Hermes, and other supported agent harnesses into their products through one Agent API. It enables them to build and scale agent-powered products quickly without managing separate agent backends.
This is the 5th launch from HarnessRouter. View more
HarnessRouter Community Edition
Launched this week
Plug-and-play managed agent harnesses in your product: Codex, Claude Code and Hermes through one API on your infrastructure, now open sourced under Apache 2.0. Switch harnesses without rebuilding your backend. Sessions, streaming, files, artifacts, cancellation, failure recovery, all handled. Model provider keys, state, and deliveries under your control. Gateway, Runner, Console in one Docker container. Ready-to-use starter kit apps as inspiration of possibilities.
Free
Launch Team / Built With
Langgraph
HarnessRouter
Hey Product Hunt 👋
Today we're launching HarnessRouter Community Edition. Think of us as OpenRouter, but for agent harnesses instead of models.
We built HarnessRouter because we used to rebuild the same backend every time we need an agent runtime behind a product. We used to build our own harness with LangGraph, agent SDK, pydantic, etc, just to find out our self-built harness performance is hard to compete with Codex, Claude Code, Hermes, etc. Once we switched our infra to leverage off-the-shelf harnesses instead of rebuilding, our agent feature delivery time is shortened from weeks to hours, and the agent quality is dramatically better. We want to advocate the same mindset to the builder community.
HarnessRouter Community Edition puts Codex, Claude Code, and Hermes behind a single API: sessions, streaming, files, artifacts, cancellation, and all the failure handling nobody enjoys writing. Pull and start with one Docker container. Your credentials, state, and files never leave your infrastructure.
In addition to the product itself, we are also publishing Unified Harness Protocol. The Unified Harness Protocol standardizes how an application talks to an agent harness. The protocol covers harness selection and configuration, task execution, streaming events, sessions, file management, cancellation, error handling, and result delivery.
One more thing: harness agents are good at far more than coding. We're shipping open source starter kits across a bunch of agentic use cases (PPT building, Spreadsheet creating, BI/Dashboard creating, Video editing, etc). The use cases we're most curious about are the ones we haven't thought of.
We would love to learn two things from ProductHunt community:
Which harness should we support next?
Where does the abstraction leak for what you're building?
We're around all day.
@renchu_song Nice launch Congrats🙌 loving the clean UI and vision here, How are you guys handling data privacy and local vs. cloud processing under the hood?
HarnessRouter
@priya_kushwaha1 Thank you for your support, Priya!
HarnessRouter
@renchu_song @priya_kushwaha1 Thanks Priya!
HarnessRouter
To answer your data privacy question: Community Edition runs entirely on your infrastructure, keeping everything under your control, while HarnessRouter Cloud manages the infrastructure and operations for you.
HarnessRouter
@tehreem_fatima5 Thanks! Great question, and it gets at a distinction we think about a lot. AutoGen and CrewAI are frameworks: you use them to build your own agent. Codex, Claude Code, and Hermes are harnesses: complete, packaged agent runtimes with their own planning, tool use, and recovery behavior built in. HarnessRouter routes to harnesses, so the near term roadmap is more of those (tell us which ones you want!). That said, the interesting bridge is the Unified Harness Protocol: if you've built an agent with CrewAI or AutoGen and wrap it in a UHP conformant interface, it can sit behind the same API as everything else. So rather than us shipping a specific AutoGen integration, we'd love to see framework built agents join as harnesses through the open spec.
HarnessRouter
@tehreem_fatima5 great question! @renchu_song great answer! UHP is an open protocol, and we welcome all harness developers and industry players to contribute to and shape together: https://github.com/HarnessRouter/harnessrouter/tree/main/protocol. Frameworks used to be small, granular building blocks that most developers had to learn. UHP and HarnessRouter help them stop worrying about that, since they now have larger, fully featured building blocks.
HarnessRouter
@tehreem_fatima5 @renchu_song This is a visual illustration of what I mean by saying: UHP and HarnessRouter help them stop worrying about that, since they now have larger, fully featured building blocks.
@renchu_song Congrats on the launch! Open sourcing this is a strong move. We ship agent-powered products and the "one API, swap the harness" idea is exactly the abstraction we ended up building badly in-house. Question: how do you handle harness-specific capabilities that don't map 1:1 across Codex / Claude Code / Hermes lowest common denominator, or escape hatch to the native layer?
HarnessRouter
@lolo_cappucci Thanks Lorenzo, this is THE design question for an abstraction like this, so let me answer from what's actually in the spec rather than hand waving. We deliberately didn't go lowest common denominator; UHP is layered.
First, the uniform task surface: sessions, streaming, files, artifacts, cancellation, structured errors. That's the portable core, and it's what the conformance suite enforces with real agent tasks, not schema checks (a stream that never flushes or a cancel that returns 200 while the agent keeps running are invisible to schema validation).
Second, capability discovery is first class. Every UHP server serves a discovery document at /v1/uhp with named capability booleans (sessions, cancellation, file input and output, harness management, idempotency...). Servers must report false rather than omit, so a client can distinguish "not supported" from "server predates this field." No learning from 404s. Fun fact: missing capability discovery was literally the first defect the conformance suite caught in our own reference implementation.
Third, harness differences live at the config layer, not the wire. The harness base is an opaque string, deliberately not enumerated by the spec, so next year's harness doesn't require a protocol revision. And where runtimes genuinely differ, the spec documents the latitude instead of pretending uniformity: disabling a tool is a hard deny rule in Claude Code but an instruction to Codex, and the spec permits both and says which guarantee you're getting.
Fourth, the escape hatch: extensions are additive and documented (metadata, a small number of extra fields, additional object types), never a redefinition of an existing field, and the schemas are open. A client that ignores every extension still gets a working task. The suite only enforces what the spec says, so anything our implementation does beyond it stays clearly labeled as HarnessRouter behavior, not accidental protocol.
Would love to hear which specific capabilities bit you when you built this in house, that's exactly the feedback that decides what gets promoted into core.
HarnessRouter
@lolo_cappucci @renchu_song Great discussion! Extensibility is essential for any open industry standard. That’s why we designed UHP as a layered, modular protocol, with a shared portable core and additive extensions for harness-specific capabilities.
I really enjoyed this exchange. Conversations like this are what move industry standards forward. We’d love to have you join the community and help shape UHP with us.
HarnessRouter
@kuanzema @lolo_cappucci Honestly, you found two real gaps, so I'll just say that plainly. On guarantee strength: capabilities today are plain booleans, and the enforced vs advisory distinction lives in spec prose, not in discovery. Your version is better. We've been bitten by exactly what you describe: constraints that hold most of the time and fail when it matters (we found a "hard" tool block that was silently advisory, it's written up in the conformance report). So I want strength per capability in the spec, not just fixed in our code. On staleness: the spec is currently silent on the discovery document's lifecycle. A session can't silently change harness (409 harness_mismatch) and version is pinned per request, but "what does a client assume if the capability set changes mid session" is genuinely unspecified. You're right that that's the gap between discovery existing and discovery being trustworthy. We will file both as issues, spec changes land with a conformance check attached, so they won't die as thread ideas. And glad you joining our community, bring exactly this energy!
HarnessRouter
@renchu_song @lolo_cappucci The prompt-vs-runtime trade-off is almost a philosophical one. From my experience building harnesses, if an issue is likely to improve as models get better, I usually leave it to the prompt unless the constraint is critical. This avoids adding rapidly growing complexity to the runtime, or building temporary infrastructure that may soon become obsolete as models evolve.
I really like your point that capability discovery should communicate the strength of each guarantee. Whether fallback is allowed, or the system must fail loudly, is essential to whether teams can trust the product with important tasks.
Your insight about stale capability information is excellent as well. We are honored to have you join the community and help shape UHP and the HarnessRouter Community Edition with us.
@renchu_song Congratulations on the launch! 🎉 HarnessRouter is a really interesting approach to making different agent harnesses more accessible through a single API. One question: how are you thinking about handling the differences in capabilities and behavior between Codex, Claude Code, and Hermes while keeping the harness abstraction consistent?
HarnessRouter
@kamal_sharma26 Thank you Kamal! We normalize the lifecycle, not the harness. What every harness shares (sessions, streaming, files, cancellation, structured errors) is the uniform surface the conformance suite enforces. What differs is made explicit instead of hidden: every server declares its capabilities in a discovery document, fail closed, so apps can detect and branch rather than assume, and harness specific behavior stays at the config layer instead of being flattened into a lowest common denominator. Where runtimes genuinely differ in guarantees, the spec documents the difference rather than pretending uniformity. There's a deeper exchange on exactly this in the thread with @lolo_cappucci and @galdayan if you want the details, including the gaps they found that are becoming spec proposals. The abstraction stays consistent because it standardizes how you drive a harness, never how the harness thinks.
DiffSense
Since its opensource. Its meant to be forked and customized I suppose? And since its a composition product, a product with many parts, how composable is it? how easy is it to swap out parts of the system for my own when I want to change things etc? Recently DeepSeek launched their harness as opensource. 100k stars in 2 days etc. And the code was modeled on a composable plugin architecture of sorts ref https://github.com/cordiverse/paper what are your thoughts around this? Thanks!
HarnessRouter
@conduit_design Great question André! And yes, we've been watching the dsh launch closely (the Cordis paper is genuinely interesting work on revertible effects / hot-swap composability).
The way we think about it: dsh and HarnessRouter are composable at different layers. dsh makes the internals of one harness swappable: model adapter, tool registry, agent loop, all plugins. HarnessRouter makes harnesses themselves swappable: you integrate one API (UHP), and you can route each task to Codex, Claude Code, Hermes, and soon Pi, dsh and more, without rebuilding your backend. UHP is a versioned open spec (OpenAPI 3.1 + JSON Schema, 47 runnable conformance checks), so if you want to swap in your own harness implementation, or fork ours, the contract is public and independently testable. That's where the fork-and-customize story lives.
On plugin-level flexibility: it's always a trade-off between composability, customizability, and ease of use. Our bet is that the frontier labs and the best harness teams will keep their harnesses tuned with the latest best practices, and most application builders get better results building on those than reassembling agent loops from parts. It's an 80/20 thing, most use cases are best served by a strong common foundation; the domain-specific cases that need a 10-20% edge may want plugin-level control, and dropping down to something like dsh makes sense there.
And because we sit a layer above, dsh isn't a competitor for us, it's a candidate harness. We can absolutely support it behind the same API and let the market tell us which harnesses win, beyond the launch-week hype. Thanks for the thoughtful question!
HarnessRouter
@conduit_design @renchu_song One thing I’d add: this is really composability at two levels. dsh makes the pieces inside one harness swappable. UHP makes the harness itself swappable at the product boundary, while keeping a shared task interface and leaving room for harness-specific extensions.
They’re complementary layers, not competing approaches.
Congrats on the launch and kudos to open source! I am wondering how does it work if I want to iterate on the artifacts it returns? And is it possible to iterate with different harnesses? For example if I am not satisfied with the slides codex generated and wanted to use Claude code to refine it, how’d that work?
HarnessRouter
@johnny_chang Thank you for supporting us! Two different flows here. Iterating itself is the native motion: a session keeps the conversational context and the working directory with all its files, so "make slide 3 less crowded" is just the next turn, the agent edits the same files in the same workspace. In the Slides kit that's literally the design, a deck is one conversation, and slides are real objects on a canvas, so you can also just drag and retype things yourself between turns.
Switching harnesses mid conversation is the interesting one, and the spec takes a deliberate stance: a session is pinned to its harness. Asking Claude Code to continue Codex's session errors loudly (409 harness_mismatch) instead of silently starting over, because continuing a conversation with a different agent IS a different conversation, and doing it quietly loses work you believed you had. The supported flow is: pull the artifacts out (per file or as a zip), start a task on the Claude Code harness with those files as input, and refine from there. Same API shape both ways since file input and artifacts are part of the protocol, so the handoff is a couple of calls, it's just explicit rather than magical. Cross harness refinement is honestly one of the fun workflows: draft with the fast one, polish with the picky one.
HarnessRouter
@johnny_chang @renchu_song Great discussion! Currently, artifacts are the portable boundary between harnesses, rather than hidden session state. This makes each handoff explicit and reproducible.
the composability answers above cover most of what I'd ask, so a narrower one: Codex, Claude Code and Hermes each have harness-specific stuff that isn't just an implementation detail - things like Claude Code's permission/tool-approval flow or subagent delegation. when a task gets routed to whichever harness actually supports that, does UHP give the calling app a way to detect "this harness can do X" and branch on it, or does building against the common surface mean you're implicitly limited to whatever the weakest supported harness can do
HarnessRouter
@galdayan Thank you for your insightful question! It's the classic abstraction-layer problem, and the trap you're describing (silent LCD) is what UHP is designed against.
First, more normalizes than you'd think. Claude Code's tool-approval flow, from the app's side, is just a lifecycle event: "run paused pending approval, approve/deny." Subagent delegation surfaces as structure in the trace. UHP models these in the common surface (sessions, streaming events, cancellation, structured errors), so harnesses that support them emit them natively.
Second, what doesn't normalize is explicit, not silent: harnesses declare what they support so apps can feature-detect and branch, and invoking an unsupported capability returns a structured error, same pattern LSP used (capability negotiation at init) to avoid LCD across hundreds of language servers.
Third, harness-specific config (permission policies, skills, MCP, model policy) stays typed at the harness-config layer rather than forced through the intersection. So the ceiling is per-harness, not weakest-common.
The common core is what's hardened by the conformance suite today; the capability surface will keep evolving as we add harnesses with weirder shapes. Spec's public and versioned, would honestly love your review on exactly this seam: https://github.com/HarnessRouter/harnessrouter/tree/main/protocol
@renchu_song the LSP comparison actually answers it well, that ecosystem survived because capability negotiation was mandatory from day one, not bolted on after servers already shipped assuming a shared baseline. curious if UHP has that same discipline this early, or if the conformance suite is more descriptive right now, catching gaps after a harness adds something new rather than requiring the declaration upfront. will go read the protocol repo, appreciate the detailed answer
HarnessRouter
@galdayan Sharp distinction, Gal! And you're right that it's the thing that decides whether the ecosystem survives.
The declaration is mandatory, at the lowest conformance class. The discovery document at /v1/uhp is required at class Core, capabilities is a required field in its schema, and the semantics are fail closed: a server must report false for what it doesn't implement rather than omitting it, and a client must treat an absent key as false. So there's no path to "conformant" that skips declaring, and no path for a client to assume a shared baseline, because absence reads as no. New capabilities enter as named booleans in an open schema, so a harness with a weirder shape declares first and the spec catches up, rather than the other way around.
Now the candid part, because it's already public in the repo: our own reference implementation initially had no capability discovery at all, and a client had to learn from 404s. Writing the conformance suite caught it, it's listed as defect #1 in the published report, and it got fixed before anything third party shipped against the spec. So you could say we weren't born with the discipline, but we installed it before there was an installed base, which is the window LSP had too.
As for descriptive vs prescriptive: the suite is normative by construction. Passing it is what "conformant" means, every check names the spec section it enforces, and governance requires that no spec change lands unless the spec, the reference implementation, and the suite move together. Our internal phrasing is "a rule nothing tests is a wish." Would love your read on the seam once you've been through the repo!
@renchu_song that defect #1 admission is the part that actually convinces me, not the spec text itself - a lot of protocols publish nice sounding principles and never say where they broke their own rule first. logging it as defect #1 and fixing it pre-installed-base is the kind of thing you can't fake after the fact. going to go read the conformance suite itself now rather than just the spec doc, curious how many of the checks exist because of a real defect like that one versus being written ahead of any observed failure
Lancepilot
Curious how you’re handling concurrency. What happens when a lot of users kick off long-running jobs at once? The API feels like the easy part; isolation and recovery are where it usually gets messy.
HarnessRouter
@istiakahmad Agreed, the API is the easy part. The spec draws one hard line on concurrency: tasks run in parallel across sessions, but never two at once inside the same session. A session is one conversation and one working directory, and two agents writing to both isn't a defined state, so the second request gets a clean structured error instead of a corrupted workspace. For isolation, every session gets its own workspace, state, and checkpoint, with one agent process per session. For recovery, workspaces live on the data volume, so a restart doesn't lose work in flight, and cleaned up idle sessions restore from their checkpoint. And the honest ceiling in the self hosted edition: one box runs what the box can run, concurrency defaults to your core count. Scaling beyond that is what the hosted version exists for.
HarnessRouter
@charlie_titherley Hey Charlie, as a founder/CEO, I constantly need to build a lot of pitch decks and PPTs. I was so frustrated about all AI ppt products in the market and I tried to build one myself. When I first tried it last September, I find it so intimating to even get an agent loop (harness was not a term back then) able to understand a PPT template. A lot of trials and errors, a few weeks and no success. The only learning I had was agent able to generate EChart json config and be embedded into a slide page as an image, following the style.
This year, I retried the same challenge. With the harness being so mature, and a lot of taste skills, I was able to build a fully functional PPT agent within a day. We put our PPT agent implementation as one of our starter kits at https://github.com/HarnessRouter/starter-kit/tree/main/kits/slides
HarnessRouter
@tehreem_fatima5 Great question! The task API held up well, start, stream, cancel, files. Where the abstraction leaks in non coding workflows is everywhere the harness touches the outside world, and those failures are silent, they look like the model being dumb. Skills are a good example: for slides or BI, the agent's format knowledge lives in a folder of scripts and references, and if any part of that surface degrades, nothing errors. The agent just quietly gets worse at its job. Same with tools: a dropped tool connection reads as "I can't access that," which looks exactly like a refusal. And long running spreadsheet or dashboard tasks stream for minutes, so anything that buffers the stream makes working look identical to frozen. The pattern we internalized: coding agents fail loudly (the test fails), non coding agents fail politely. That's why the conformance suite runs real agent tasks and even measures streaming behavior, instead of just checking schemas.