3 ms·

What’s the pitch for a harness router?iirc codex has codex app server, pi also has a reusable core.

songrenchu 2mo ago
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 2mo ago
  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 https://harnessrouter.ai/benchmarks
- Bnjoroge 2mo ago
  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 2mo ago
    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 2mo ago
      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 2mo ago
        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) We need HarnessRouter when we need to 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 components and deliver result to downstream product components. We put 4 demo agent products for white collar working scenarios in our starter kit: 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 + DeepSeek V4 Pro. Take the PPT agent use case, for sure you 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 baked 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 2mo ago
        ah gotcha! For non-coding use cases I see the value/utility. Thanks, good luck!
        songrenchu 2mo ago
        Thank you for the discussion! This really nudges us to think how to make the broader white collar agent use case message more clear
deleted 2mo ago
[deleted]

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 2mo ago
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 https://harnessrouter.ai/benchmarks
Bnjoroge 2mo ago
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 2mo ago
  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 2mo ago
    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 2mo ago
      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) We need HarnessRouter when we need to 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 components and deliver result to downstream product components. We put 4 demo agent products for white collar working scenarios in our starter kit: 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 + DeepSeek V4 Pro. Take the PPT agent use case, for sure you 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 baked 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 2mo ago
        ah gotcha! For non-coding use cases I see the value/utility. Thanks, good luck!
        songrenchu 2mo ago
        Thank you for the discussion! This really nudges us to think how to make the broader white collar agent use case message more clear

deleted 2mo ago

[deleted]