harnessrouter vs scale-agentex
Self-hosted Apache-2.0 reference implementation of the Unified Harness Protocol: one OpenAI-Responses-style API running Codex, Claude Code, Hermes, Pi and DSH with sessions, streaming, files, traces. — versus — Scale AI's open agent platform: scaffold agents with a CLI, run them behind the ACP protocol with a dev UI, and graduate from sync chat to durable Temporal-backed long-running workflows.
Both standardise how products run agents behind an open protocol (ACP vs UHP); agentex runs agents you scaffold, harnessrouter runs off-the-shelf coding harnesses.
| harnessrouter | scale-agentex | |
|---|---|---|
| Stars | 1.1k | 488 |
| Forks | 112 | 59 |
| Language | Python | Python |
| License | Apache-2.0 | Apache-2.0 |
| Last activity | yesterday | 2 days ago |
| Topics | orchestration, agents, gateway | agents, orchestration |
| Curated connections | 5 | 4 |
harnessrouter — the curator's take
Use it when your *product* needs to run coding-agent harnesses as a backend service and you don't want an integration per harness: one Docker image ships Console + Gateway + Runner, installs the harness CLIs you enable, and exposes runs/sessions/artifacts through UHP so you can swap Codex for Claude Code (or a cheaper harness×model pair — their benchmarks show 90%+ cost spread) without touching your app. Bring your own provider keys. It is a server for embedding harnesses, not a desktop cockpit for a developer (see agent-orchestrator, helmor) and not a model gateway (put litellm/omniroute underneath). Community Edition of a commercial product; check what stays in the paid tier before betting on it.
scale-agentex — the curator's take
Pick it when agents outgrow request/response: the async tier runs on Temporal, so long-running autonomous work gets durability, retries and resumability without changing your agent code's architecture — that L1→L5 'same framework at every level' pitch is the real differentiator. The local story is genuinely turnkey: ./dev.sh boots Postgres, Redis, Mongo and Temporal plus a dev UI, and `agentex init` scaffolds a working agent. NOT for a simple chatbot — that stack is heavy, and Python 3.12+/Docker are hard requirements. If you want multi-agent conversation patterns rather than deploy-and-scale infrastructure, a framework like CrewAI or AutoGen is the lighter tool. The enterprise 'zero-ops' path funnels into Scale's hosted SGP platform — fine, but know it.