HarnessRouter Community Edition solves a problem I have felt myself: running Codex, Claude Code, Hermes, and the other agent harnesses normally means juggling separate CLIs and configs, but this project unifies them behind one self-hosted container and one Responses-compatible API, with per-session workspaces and provider keys that never leave the box. The UHP conformance suite passing at class Full shows the protocol is a real contract, not a slogan.
Because provider choice is already a designed surface here (an integration pairs a provider name with an API key and its models appear in the pickers), an optional gateway fits how the product works. I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter for operators who want more model options behind one key.
Proposal
OrcaRouter would be an optional, purely additive provider. It would not replace or change any existing provider: Anthropic, OpenAI, OpenRouter, Bedrock, TokenRouter, Vercel, and the other connections you already configure keep working untouched. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the natural integration point is the connection/policy path the README documents for OpenAI-compatible endpoints: a provider entry with an API key and a base_url, served to the backends that already use OpenAI-compatible gateway connections (Codex, Hermes, Pi, DeepSeek Harness, OpenCode, Qwen Code, Cline, Oh My Pi). I have not implemented or tested anything yet; I'd want maintainer input on where a catalogue entry and wiring belong before writing code, following CONTRIBUTING's describe-before-you-build flow.
What it adds for self-hosted operators
- One key, many models. A single OrcaRouter integration would put a broad chat and reasoning catalogue in the model pickers, with image and video models available too.
- Routing and failover. The README notes an unfit provider/model pairing fails quietly after a long wait; routing and failover send the turn to a provider that answers.
- Usage tracking and budgets. The operator owns the key and the bill, so usage tracking and per-team budgets keep long agent turns and batch work predictable.
Open-source ecosystem
OrcaRouter is already adopted across open-source projects, including models.dev / OpenCode, Dify, RAGFlow, and goose. OpenCode in particular is already one of the harnesses HarnessRouter runs.
Disclosure
One disclosure, offered openly: OrcaRouter runs an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for an integration, and I'm glad to follow any disclosure or governance requirements HarnessRouter has.
Next steps
A reference list of OSS integrations lives at https://www.orcarouter.ai/built-with. I'd welcome maintainers' views on fit and scope; with your go-ahead, I'm happy to open a PR implementing it.
HarnessRouter Community Edition solves a problem I have felt myself: running Codex, Claude Code, Hermes, and the other agent harnesses normally means juggling separate CLIs and configs, but this project unifies them behind one self-hosted container and one Responses-compatible API, with per-session workspaces and provider keys that never leave the box. The UHP conformance suite passing at class Full shows the protocol is a real contract, not a slogan.
Because provider choice is already a designed surface here (an integration pairs a provider name with an API key and its models appear in the pickers), an optional gateway fits how the product works. I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter for operators who want more model options behind one key.
Proposal
OrcaRouter would be an optional, purely additive provider. It would not replace or change any existing provider: Anthropic, OpenAI, OpenRouter, Bedrock, TokenRouter, Vercel, and the other connections you already configure keep working untouched. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the natural integration point is the connection/policy path the README documents for OpenAI-compatible endpoints: a provider entry with an API key and a
base_url, served to the backends that already use OpenAI-compatible gateway connections (Codex, Hermes, Pi, DeepSeek Harness, OpenCode, Qwen Code, Cline, Oh My Pi). I have not implemented or tested anything yet; I'd want maintainer input on where a catalogue entry and wiring belong before writing code, following CONTRIBUTING's describe-before-you-build flow.What it adds for self-hosted operators
Open-source ecosystem
OrcaRouter is already adopted across open-source projects, including models.dev / OpenCode, Dify, RAGFlow, and goose. OpenCode in particular is already one of the harnesses HarnessRouter runs.
Disclosure
One disclosure, offered openly: OrcaRouter runs an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for an integration, and I'm glad to follow any disclosure or governance requirements HarnessRouter has.
Next steps
A reference list of OSS integrations lives at https://www.orcarouter.ai/built-with. I'd welcome maintainers' views on fit and scope; with your go-ahead, I'm happy to open a PR implementing it.