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
Launched this week
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
@renchu_song @priya_kushwaha1 Sounds great, we'd love to collaborate with you!
Congratulations on your launch, @renchu_song Curious about the handoff between agents. If I build with Claude Code today and switch to Codex later, how much context and setup carries over without rebuilding the workflow?
HarnessRouter
Thank you @habibferdous , great question.
The parts we want to make portable are the tools, skills, and instructions, where the workflow and evaluation criteria live.
Think of it like Lego: tools, skills, and instructions are the reusable blocks. The harness is the base you can swap, test, and rebuild on.
If you start with Claude Code and later switch to Codex, you should not have to rebuild the whole workflow. You can keep the portable layer, run it against the new harness, compare performance, and adjust only the parts where that harness behaves differently.
That way, switching harnesses becomes an iterative optimization process, not a full rewrite. And we provide the observability and tracing tools to help you see what changed and adjust with confidence.
HarnessRouter
@renchu_song @habibferdous let's visualize it.
HarnessRouter
@habibferdous @kuanzema Here is an example how we provide tracing:
HarnessRouter
@habibferdous Great question, Habib. We have a feature called fork a harness, which copies the configuration of the harness into a different base harness (codex -> claude code, hermes -> codex, etc) in one click. From that fork point, the builder or the builder's coding agent can iterate the harness configuration to bridge the harness specific setup differences. We call it vibe harness engineering.
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
@thys_beesman @renchu_song Great question and great answer. One thing I’d add: we think about routing at the level of the whole execution setup.
For a specific task, the relevant unit is [harness + model] plus [instructions + tools + skills]. Over time, the performance data for each setup: success rate, cost per task, latency, reliability, and output quality, becomes the asset.
Rather than comparing Codex vs. Claude in isolation, we help teams compare complete setups and route each task to the one that performs best.
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.
HarnessRouter
@omri_ben_shoham1 Thank you for your question, this touches some of the deepest core of our product. "One API" does mean you're trusting our uptime, so let me be straight about where the line actually is.
Honest answer to the direct question: no, we don't silently fail a call over to you hitting the provider directly. If our control plane is down, calls through it are down. Pretending otherwise would be the wrong answer. So the real question is how much we've done to make "HarnessRouter is down" rare and non-catastrophic, and where you keep an escape hatch.
What's in our hands:
- Provider/model failover within an agent loop turn. A request walks a chain of connections, if the primary provider errors or rate-limits, it falls back to the next authorized provider/model automatically, and the substitution is recorded in run metadata so it's auditable, not silent. So "the agent behind the call is having a bad day" is largely handled.
- Stateless, horizontally-scaled control plane. The routing layer holds no per-turn state that can't be rebuilt, so it scales out and a bad node doesn't take the fleet.
- Turns survive infrastructure failure. Every turn's events are written to durable storage as they happen, and an in-flight turn is recoverable/resumable if the node running it dies, you get the finished work, not a black hole. (This one we just hardened specifically because it's the scary failure mode.)
What's still shared risk, honestly: a total outage of our edge is a hard dependency, same as any API you build on (your DB, your auth provider, Stripe). We're not magic there.
The escape hatch that should matter to you: we're not a lock-in. In our next minor release, we will support BYOK, and the models are the same frontier models you'd call directly, so if you ever needed to, routing around us is a config change, not a rewrite. That asymmetry is deliberate: the pitch only works if leaving is cheap.
Happy to go deeper on the failover chain or the durability model. You can DM me or contact us at contact@harnessrouter.ai
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.
HarnessRouter
@noctis06 Great question, this is exactly the part that decides whether you can trust it in production, so let me be precise.
State is on us, not you. HarnessRouter maintains the in-flight state for a run, you don't write resume logic. Every run streams its events (reasoning, tool calls, tool results, file writes) to durable storage as they happen, and the run's workspace is checkpointed, so the run has a durable identity you can reconnect to rather than a fragile in-memory session you'd have to babysit.
One correction on the premise: in our model, agents run autonomously inside an isolated per-run sandbox, they don't pause mid-task to ask the app for tool permission. Tool calls (shell, file edits, web, etc.) execute inside that sandbox without round-tripping to your app for approval, so there's no "app must handle the permission handshake" step. The human-in-the-loop gating is the immediately next feature we will launch in next minor release.
Recovery, concretely:
- Connection drop / client disconnect: the run does not get cancelled when your connection drops. It keeps executing server-side; you reconnect and catch up, either by re-subscribing to the live event stream or by reading the run's stored events. Nothing is lost, no resume code on your side.
- Long runs / timeout: each run has a configurable wall-clock cap (with a hard ceiling), so a runaway can't hang forever, and the state up to that point is durable and readable.
- Follow-ups: a next turn resumes the same conversation + workspace by run/session id, independent of which machine handled the previous turn.
So the short version: you build against a durable run you poll or stream, not a live socket you have to keep alive. A dropped browser tab, a redeploy on your side, or a flaky network doesn't lose the work.
Happy to go deeper on the event/replay model if you're designing around it, feel free to DM me or contact us at contact@harnessrouter.ai
HarnessRouter
@noctis06 @renchu_song This is exactly the distinction that matters for product builders.
The value is not only that the agent keeps running. It’s that the host app can treat the run as a durable object: start it, stream events, reconnect, inspect history, and continue from the same run/session id.
That means developers don’t have to build their own fragile resume layer around long-running agents. The app can focus on the product design and workflow, while HarnessRouter handles the agent runtime, workspace, event stream, and recovery model underneath.
Handling cost control at the agent level is tricky—does HarnessRouter allow setting strict token/cost caps per request or per user?
HarnessRouter
@matthew_flores1 Today you get a hard balance stop, spend is metered in credits, and when the wallet's empty, runs get refused cleanly instead of silently overspending. Plus every run has max-step and timeout limits so an agent can't loop forever, and each run reports exactly what it cost.
We are working on a strict per-request token cap or a per-user dollar limit you set as a number. That per-user budgeting is squarely where we're headed though, since you bring your own end users, enforcing a budget per user server-side is the whole point.
If that's central to how you'd build, tell me the shape you'd want (per-user monthly cap? per-call limit?), genuinely shapes what we ship next. 🙏
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?
HarnessRouter
@johnny_chang Hi Johnny, you read our minds! Yes, persistent data is our next major release. Our ultimate goal is for builders to be able to monetize your product on our platform, so we will expose a managed database layer each generated app can read/write to, no separate DB to stand up, no extra billing account to wire in, it just comes with the app.
Once that's in place, the natural next step is letting you charge your own end users through the same platform (usage or one-time), so the whole loop (build, persist, monetize) happens in one place.
Not shipped yet, but it's the thing we're building toward right now. Would love to hear what shape of persistence you'd actually want (structured DB vs. simple key-value vs. file storage) feeds directly into how we design it.
HarnessRouter
@johnny_chang One thing I really like about the hunter community is that many builders like you immediately understand where this is heading and where the value will be.
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
HarnessRouter
@renchu_song @st0rm_27 I love the “leverage rather than build” framing. I also fully agree that whoever owns the insight into the problem and the path to the solution will have the competitive advantage. Everything we are building toward today points to one vision: product follows your words. If you can articulate the problem clearly, a productized solution should be delivered almost instantly.
HarnessRouter
@renchu_song @st0rm_27 I’ve personally built an agent harness to run my projects, so I know many ways to get it wrong.
You end up designing orchestration across tools, MCP, models, sandboxes, files, permissions, usage caps, retries, streaming, and observability. Each piece becomes almost its own product, and then you still have to think carefully about how all those pieces interact.
That’s why I think this is the better path for most teams: instead of building and maintaining the harness itself, stand on the shoulders of existing harnesses and customize the parts that actually encode your domain: instructions, tools, skills, evals, and product workflow.
Fewer infrastructure mistakes, less maintenance, and faster, better outcomes.
HarnessRouter
@st0rm_27 @kuanzema yes, Mark and I had a dinner exactly 5 weeks ago, that's where this all started. We have independently pursued the same mountain from two different directions, and when we met in the middle, that's all this ideas emerge and HarnessRouter becomes a product.
HarnessRouter
@st0rm_27 This is such an inspiring question, Mohit! It touches on the deeper philosophy of how we think about the relationship between humans and AI in the future of knowledge work.
We believe customer knowledge will eventually live in a versioned, temporal knowledge graph—what we call a contextual graph. Retrieval should be not only domain-aware but also time-aware, enabling the system to model how knowledge evolves and supersedes previous knowledge over time.
The system becomes a digital twin of an enterprise’s collective human knowledge, though biases and hidden nuances cannot always be fully captured digitally. No system can represent reality with 100% accuracy. Instead, it must dynamically balance accuracy, quality, latency, and cost against the complexity of the real world.
The most important role of a service provider is to navigate that balance and deliver a system that satisfies the constraints set by the customer.
HarnessRouter
@st0rm_27 You are right on the point.
To answer your question: I think the advantage comes from both:
1. Deep knowledge of your customers’ problems.
2. Operational insight gained while solving those problems repeatedly.
The first is strengthened by proprietary data and customer feedback. The second comes from continuously refining the workflow: what to automate, where humans stay in the loop, which tools to use, and how to evaluate quality.
The real moat is when those two compound together: customer understanding turns into better workflows, and better workflows generate more insight from every run.