HarnessRouter lets developers run multiple sandboxed agents, including Codex, Claude Code, and Hermes, inside their products through one API. It turns months of agent backend work into minutes.
This is the 4th launch from HarnessRouter. View more
HarnessRouter
Launching today
Building an AI agent backend yourself takes months: sandboxes, orchestration, retries, cost controls. HarnessRouter runs it for you. One API in, finished work out: code, files, videos, games. Trusted by top medical research institutions, leading healthcare companies, and cutting-edge startups in multiple domains.
Free Options
Launch Team
HarnessRouter
Hey Product Hunters,
We're the HarnessRouter team.
Building an AI agent backend yourself takes months: a sandbox per run, agent runtime, tool orchestration, files and artifacts, sessions and streaming, retries and timeouts, permissions, cost controls. And the upgrades, fixes, and maintenance never stop.
So we built HarnessRouter: bring the world's best AI agents into your app, with one API. Codex, Claude Code, Hermes, and more, running as your product's backend.
Here's what people are already building with HarnessRouter as their backend:
🎬 A cutting-edge AI video marketing startup uses HarnessRouter to drive their content generation loop, producing human-level viral video content.
🏥 A top medical research institution uses HarnessRouter to build an academic brain that connects all their operational data into a unified agent plane.
✅ A leading healthcare compliance company uses HarnessRouter to bake human domain expertise into agent skills, saving their customers hundreds of hours of labor.
What HarnessRouter does: your app sends a task through one API, HarnessRouter runs it using Codex, Claude Code, Hermes, and soon more, then sends back finished work: code, files, videos, games.
How you use it：
1. Drop our AGENTS.md into Cursor or Claude Code
2. Describe your idea, for example: "Build a founder launch-video app: users drop a logo and an idea, get a launch video."
3. Add your API key. Ship.
What happens behind the scenes: each task runs inside its own sandbox, traced step by step, so you can see exactly what the agent did. What comes back is structured and renderable, not just a chat reply: reviewable diffs, generated files, images, confirmations of real tool actions. And you're not locked into one harness. Claude Code today, Codex tomorrow, swappable with one line of config, and flexible enough to run thousands of harnesses concurrently.
Free during a 7-day trial. Would love for you to try it and tell us what your app should build. Reading every comment today. 🙏
Amazing launch congrats👏 @renchu_song does each sandbox have direct outbound internet access for tool scraping or can we configure strict egress rules?
HarnessRouter
@priya_kushwaha1 Thanks, Priya! 🙌 Yes, sandboxes have outbound internet access today (agents can fetch/scrape/install as needed), each isolated in its own VM. Configurable egress policies (allowlists/deny-by-default) are on the roadmap, and I would love to hear your use case, feel free to DM me!
@renchu_song Great to hear.. Egress controls will be a huge win for enterprise use cases. sure i'll dm
HarnessRouter
@thys_beesman Great questions, both are things we learned the hard way rather than designed on a whiteboard.
On harness portability, you're right that a bare prompt tuned to one agent doesn't transfer for free, and we don't claim swap-and-forget. What makes switching practical for us is that the harness definition stays deliberately thin, and the domain expertise lives in two layers that are genuinely portable: skills (explicit, procedural instructions paired with deterministic scripts the agent invokes: recipes, not model-idiom prompting) and typed tools (every tool exposes a strict input schema; the schema is the contract, and both runtimes consume it the same way). The system prompt describes the job, not the model's habits.
The honest second half: every harness config ships with an eval suite, real domain cases scored against rubrics, with human-expert alignment checks on the grader. Switching the underlying agent means re-running the suite and fixing what it surfaces, which is usually tool-boundary discipline rather than instruction rewrites, where runtimes differ in how carefully they fill tool arguments, we add validation guards at the tool layer instead of forking the instructions. Today we run some verticals on one runtime and some on the other, chosen by eval results, not loyalty. So "one line of config" is the mechanism; the eval suite is what makes it safe to actually pull the lever.
On data residency: this is the first question every healthcare compliance team asks, and the answer is structural, not policy: agent runs execute in sandboxes inside the same private network where the data already lives, there is no third-party backend the documents travel to. Each run gets an isolated workspace; reference material is mounted read-only; the workspace is destroyed when the task completes. What persists is exactly what a compliance team wants persisted: the audit trail, what was asked, which tools ran, what was produced, not copies of source documents. Customer data is never used for model training. Happy to walk through the architecture in detail under NDA, that conversation is usually shorter than people expect because the answer to "where does our data go" is "nowhere."
HarnessRouter
@nivotools thank you for your insightful question! We built a OpenAI responsive API compatible contract for the harness response, and cannicalized all harness repsonse to this format. So that any AI app built with OpenAI responsive API can do a one line swap to upgrade their one-shot chat completion backend to an agentic intelligence backend.
HarnessRouter
@st0rm_27 Great question, Mohit. I think teams, especially highly technical ones, tend to build their own agent harness infrastructure in-house, and that decision itself is surprisingly risky. We made the same mistake, until earlier this year we realized agent harnesses are getting commoditized fast. Competing with frontier labs, well-funded startups, and open source communities by hand-crafting our own harness just wasn't a wise use of our time.
So we chose to leverage rather than build. That freed us up to focus on what actually differentiates us, and it's let us build great applications both for ourselves (more launches coming soon!) and for our customers. HarnessRouter is us packaging up those learnings and handing the same leverage to the builder community.
HarnessRouter
@st0rm_27 inspirational discussion, Mohit. Don't get me wrong, I still believe the best infrastructure will be a competitive advantage. That's why we spend a lot of time designing the our harness service infrastructure in an elastic serverless way that is cost efficient, so we can best serve our customers. But the infrastructure advangate alone is not enough as a moat, that's why we send forward-deployed engineers / founders to customer site, work side by side with our customer, and make sure our product can really solve their problem. Yes, it's like Palantir, in an AI-native way of operation
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?
HarnessRouter
@galdayan great question, Gal. For enterprise customers with deep domain expertise, we send forward-deployed engineer to customer site and work with customer side by side, distill the human expertise into both the agent skills, AND the evaluation sets. To iterate, we build tools for human experts to easily rank and label different versions of agent response, and use that signals to gate go/no-go on harness swap
MonoCloud for Startups
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.
HarnessRouter
@roguetink you absolutely nailed it, Shivangi! Yes, just like there are a lot of model routers / token routers vendors in the market, the market need a vendor neutral platform and aggregator for the harness layer. Harness + Model = Agent. With the M harnesses * N models options, any business have the flexibility to avoid vendor lock-in for the best of their benefit.
HarnessRouter
@roguetink Hi Shivangi, you’re exactly right. Builders don’t want to be locked into a single agent, especially when the best system may combine different agents, each optimized for a specific task.
We’re already seeing labs use HarnessRouter’s infrastructure to evaluate models and agents across different tasks. Over time, this performance data can power smarter routing and become an increasingly valuable intelligence layer.
HarnessRouter
@renchu_song Congratulations!
HarnessRouter
@huisong_li thank you for your support, Huisong!