The Weave Router already solves one of the hardest practical problems in building agentic systems: how to stop guessing which model to use for each request and let a real embedding-based scorer decide. The sub-50ms on-box routing, the BYOK-first design, and the OTel observability out of the box make it the kind of infrastructure that quietly saves teams both money and cognitive load — you wire it once and every tool in your stack benefits from the same smart dispatch. The fact that the router natively speaks Anthropic, OpenAI, and Gemini wire formats while translating between them means it doesn't ask you to standardize your tooling first; it meets you where you are.
That multi-provider surface is exactly where an additional option makes sense. Teams using the router already have OpenRouter, Fireworks, Together, and other OpenAI-compatible endpoints available as upstreams. Adding OrcaRouter as a provider would give users another competitive choice for high-throughput and reasoning workloads — OrcaRouter exposes an OpenAI-compatible API with standard API-key authentication, so it would integrate through the existing openaicompat adapter pathway that the project already maintains. The integration point is well-established: add a ProviderOrcaRouter constant, its APIKeyEnvVars entry, and a registration block in cmd/router/main.go, following the same pattern as the existing OpenAI-compatible providers. No new adapter package is needed, and no existing provider is changed.
I'd suggest a few OrcaRouter capabilities that feel relevant to the router's user base: automatic model routing and provider failover (so the router's own cluster scorer decides which model to use, and OrcaRouter handles per-provider fallback under the hood), usage tracking with budgets for team-level cost control, and prompt caching across supported models. OrcaRouter is already integrated into several open-source projects in the AI tooling ecosystem, including RAGFlow, Dify, goose, and promptfoo — projects that, like the Weave Router, sit between users and LLMs and benefit from multi-model flexibility.
I'm an engineer on the OrcaRouter team. We also run an optional open-source partner program where approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation in the program is not a prerequisite for integration — it's entirely optional, and I'm happy to follow whatever disclosure or governance expectations the project has. More details are at https://www.orcarouter.ai/built-with.
I'd love to hear your thoughts on whether this would be a welcome addition. If so, I'm happy to submit a PR implementing the provider integration.
The Weave Router already solves one of the hardest practical problems in building agentic systems: how to stop guessing which model to use for each request and let a real embedding-based scorer decide. The sub-50ms on-box routing, the BYOK-first design, and the OTel observability out of the box make it the kind of infrastructure that quietly saves teams both money and cognitive load — you wire it once and every tool in your stack benefits from the same smart dispatch. The fact that the router natively speaks Anthropic, OpenAI, and Gemini wire formats while translating between them means it doesn't ask you to standardize your tooling first; it meets you where you are.
That multi-provider surface is exactly where an additional option makes sense. Teams using the router already have OpenRouter, Fireworks, Together, and other OpenAI-compatible endpoints available as upstreams. Adding OrcaRouter as a provider would give users another competitive choice for high-throughput and reasoning workloads — OrcaRouter exposes an OpenAI-compatible API with standard API-key authentication, so it would integrate through the existing
openaicompatadapter pathway that the project already maintains. The integration point is well-established: add aProviderOrcaRouterconstant, itsAPIKeyEnvVarsentry, and a registration block incmd/router/main.go, following the same pattern as the existing OpenAI-compatible providers. No new adapter package is needed, and no existing provider is changed.I'd suggest a few OrcaRouter capabilities that feel relevant to the router's user base: automatic model routing and provider failover (so the router's own cluster scorer decides which model to use, and OrcaRouter handles per-provider fallback under the hood), usage tracking with budgets for team-level cost control, and prompt caching across supported models. OrcaRouter is already integrated into several open-source projects in the AI tooling ecosystem, including RAGFlow, Dify, goose, and promptfoo — projects that, like the Weave Router, sit between users and LLMs and benefit from multi-model flexibility.
I'm an engineer on the OrcaRouter team. We also run an optional open-source partner program where approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation in the program is not a prerequisite for integration — it's entirely optional, and I'm happy to follow whatever disclosure or governance expectations the project has. More details are at https://www.orcarouter.ai/built-with.
I'd love to hear your thoughts on whether this would be a welcome addition. If so, I'm happy to submit a PR implementing the provider integration.