Proposal: add OrcaRouter as an optional provider
routatic-proxy sits between Claude Code and upstream providers, transforming Anthropic-format requests in-flight to OpenAI, Responses, or Gemini so providers like OpenCode Go, AWS Bedrock, and OpenRouter feel native - tool calling, scenario-based model routing, and fallback chains included. That matters to developers who want Claude Code's interface while choosing their own cost or infrastructure trade-offs.
New providers are a first-class extension point here: OpenRouter already joins through the same base_url/api_key config and OpenAI-format transformation path. I would like to propose OrcaRouter as another optional, additive provider - one endpoint and one API key for many chat, reasoning, image, and video models, with usage tracking and budgets in one place. Nothing about existing providers changes unless a user opts in.
Why OrcaRouter fits this project's routing model
- Multiple model families through one endpoint: fits how routatic-proxy already mixes models per scenario (default / thinking / long-context / background).
- Automatic model routing and provider failover: routes to the best available upstream and fails over when one is down, complementing the proxy's own fallback chains and circuit breaker rather than duplicating them.
- Usage tracking and budgets: useful to the same cost-conscious users who reach for
cost_routing and penalty_per_provider.
Integration shape
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Concretely, I would expect an orcarouter provider entry mirroring the existing OpenRouter one in config.json (an api_key and a base_url via env-var interpolation), with models referenced through the existing provider/model-name catalog keys and handled by the OpenAI Chat Completions path the proxy already maintains. I have not written or tested any code - this issue is to gauge interest and agree on the right provider hook before an implementation PR.
Ecosystem context
OrcaRouter is already used from open-source projects such as RAGFlow, Dify, and promptfoo, and appears in registries like models.dev / OpenCode - an established pattern for treating it as one more OpenAI-compatible provider in a toolchain.
Disclosure
I want to be upfront: OrcaRouter runs an optional open-source partner program under which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participating is not a prerequisite for adding the provider, and if the maintainers prefer not to be associated with a commercial arrangement, I am happy to keep the integration independent of the program and follow whatever disclosure or governance rules the project prefers.
More context on projects building with OrcaRouter: https://www.orcarouter.ai/built-with
I'm an engineer on the OrcaRouter team. If this sounds useful, I'd welcome your feedback on the right integration point and am happy to submit an implementation PR once we align on the approach.
Proposal: add OrcaRouter as an optional provider
routatic-proxy sits between Claude Code and upstream providers, transforming Anthropic-format requests in-flight to OpenAI, Responses, or Gemini so providers like OpenCode Go, AWS Bedrock, and OpenRouter feel native - tool calling, scenario-based model routing, and fallback chains included. That matters to developers who want Claude Code's interface while choosing their own cost or infrastructure trade-offs.
New providers are a first-class extension point here: OpenRouter already joins through the same
base_url/api_keyconfig and OpenAI-format transformation path. I would like to propose OrcaRouter as another optional, additive provider - one endpoint and one API key for many chat, reasoning, image, and video models, with usage tracking and budgets in one place. Nothing about existing providers changes unless a user opts in.Why OrcaRouter fits this project's routing model
cost_routingandpenalty_per_provider.Integration shape
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. Concretely, I would expect an
orcarouterprovider entry mirroring the existing OpenRouter one inconfig.json(anapi_keyand abase_urlvia env-var interpolation), with models referenced through the existingprovider/model-namecatalog keys and handled by the OpenAI Chat Completions path the proxy already maintains. I have not written or tested any code - this issue is to gauge interest and agree on the right provider hook before an implementation PR.Ecosystem context
OrcaRouter is already used from open-source projects such as RAGFlow, Dify, and promptfoo, and appears in registries like models.dev / OpenCode - an established pattern for treating it as one more OpenAI-compatible provider in a toolchain.
Disclosure
I want to be upfront: OrcaRouter runs an optional open-source partner program under which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participating is not a prerequisite for adding the provider, and if the maintainers prefer not to be associated with a commercial arrangement, I am happy to keep the integration independent of the program and follow whatever disclosure or governance rules the project prefers.
More context on projects building with OrcaRouter: https://www.orcarouter.ai/built-with
I'm an engineer on the OrcaRouter team. If this sounds useful, I'd welcome your feedback on the right integration point and am happy to submit an implementation PR once we align on the approach.