ClawShell is the essential safety harness for the OpenClaw and Hermes Agent ecosystem - it sits between the agent and upstream LLM providers, swapping virtual keys for real ones so the agent never holds a real credential, and scanning request and response bodies for PII before anything crosses the boundary. The design that makes this work is your provider abstraction: a Provider enum, per-provider base URLs under [upstream], and correct header injection - Bearer for OpenAI-compatible upstreams, x-api-key for Anthropic.
That abstraction is exactly why another upstream is a natural fit for ClawShell operators. Users already point OpenClaw or Hermes Agent at several providers; adding one more OpenAI-compatible endpoint that reaches many models from a single virtual key means new model choices without exposing additional real keys or reconfiguring the agent.
Proposal
I'd like to propose adding OrcaRouter as an optional upstream provider. This is purely additive - the existing OpenAI, Anthropic, OpenRouter, MiniMax, and OpenCode providers and existing configs would be untouched. I'm an engineer on the OrcaRouter team.
For ClawShell users, the capabilities that matter most are:
- Many models, one endpoint: chat, reasoning, image, and video models across providers reachable through a single OpenAI-compatible endpoint, so operators can pick the best model per task without maintaining N real keys.
- Automatic routing and provider failover: an
orcarouter/auto mode grades each prompt and routes it, with configured fallback chains so a provider outage doesn't stall an agent run.
- Usage tracking and budgets: per-key request logs with cost per call, spend caps, and team access controls - a natural complement to ClawShell's loopback-only
/admin/stats for operators who want cost guardrails per virtual key.
Expected integration point
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Following the pattern OpenRouter already uses in ClawShell, the expected integration would add a new Provider variant with a default base URL of https://api.orcarouter.ai/v1, an orcarouter_base_url override under [upstream], and virtual-key mappings targeting that provider. Because the proxy already injects Authorization: Bearer for OpenAI-compatible providers, no new auth header handling should be needed. This is a proposal for discussion - no code has been written or tested.
OrcaRouter is already shipping inside a number of open-source projects, including Dify, RAGFlow, promptfoo, and OpenCode (which ClawShell already supports as a provider), so the integration pattern is already in use elsewhere.
Transparency note
For transparency: 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. Taking part is not a prerequisite for the integration itself, and I'm happy to follow whatever disclosure or governance requirements the ClawShell project has.
The built-with page is at https://www.orcarouter.ai/built-with. I'd appreciate maintainers' thoughts on whether OrcaRouter fits ClawShell's model, and with approval I'd be glad to submit an implementation PR.
ClawShell is the essential safety harness for the OpenClaw and Hermes Agent ecosystem - it sits between the agent and upstream LLM providers, swapping virtual keys for real ones so the agent never holds a real credential, and scanning request and response bodies for PII before anything crosses the boundary. The design that makes this work is your provider abstraction: a
Providerenum, per-provider base URLs under[upstream], and correct header injection - Bearer for OpenAI-compatible upstreams,x-api-keyfor Anthropic.That abstraction is exactly why another upstream is a natural fit for ClawShell operators. Users already point OpenClaw or Hermes Agent at several providers; adding one more OpenAI-compatible endpoint that reaches many models from a single virtual key means new model choices without exposing additional real keys or reconfiguring the agent.
Proposal
I'd like to propose adding OrcaRouter as an optional upstream provider. This is purely additive - the existing OpenAI, Anthropic, OpenRouter, MiniMax, and OpenCode providers and existing configs would be untouched. I'm an engineer on the OrcaRouter team.
For ClawShell users, the capabilities that matter most are:
orcarouter/automode grades each prompt and routes it, with configured fallback chains so a provider outage doesn't stall an agent run./admin/statsfor operators who want cost guardrails per virtual key.Expected integration point
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Following the pattern OpenRouter already uses in ClawShell, the expected integration would add a new
Providervariant with a default base URL ofhttps://api.orcarouter.ai/v1, anorcarouter_base_urloverride under[upstream], and virtual-key mappings targeting that provider. Because the proxy already injectsAuthorization: Bearerfor OpenAI-compatible providers, no new auth header handling should be needed. This is a proposal for discussion - no code has been written or tested.OrcaRouter is already shipping inside a number of open-source projects, including Dify, RAGFlow, promptfoo, and OpenCode (which ClawShell already supports as a provider), so the integration pattern is already in use elsewhere.
Transparency note
For transparency: 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. Taking part is not a prerequisite for the integration itself, and I'm happy to follow whatever disclosure or governance requirements the ClawShell project has.
The built-with page is at https://www.orcarouter.ai/built-with. I'd appreciate maintainers' thoughts on whether OrcaRouter fits ClawShell's model, and with approval I'd be glad to submit an implementation PR.