Everything Claude Code is a genuinely useful collection: production-ready agents, skills, hooks, commands, and rules that the author evolved over 10+ months of daily use building real products. It saves Claude Code developers from reinventing disciplined workflows — the /plan, /tdd, /verify cadence is a concrete plan-first, test-first loop, and the session-start/session-end hooks carry context across sessions automatically.
It also treats model choice deliberately: rules/performance.md maps Haiku 4.5, Sonnet 4.5, and Opus 4.5 to task types, and each agent's frontmatter pins a model. Teams running this toolkit already pick models per task, so an optional way to route those requests adds real choice without disturbing the existing Anthropic setup.
Proposal: OrcaRouter as an optional provider
I'd like to propose adding OrcaRouter as an optional provider. This would not replace or modify any existing provider, model pin, or configuration — the current Anthropic defaults and the model: frontmatter on every agent stay exactly as they are.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. One endpoint reaches many chat, reasoning, image, and video models across providers, with automatic model routing and provider failover, prompt caching, usage tracking, budgets, and team access controls.
For a Claude Code audience the most relevant capabilities are multiple models behind one endpoint, automatic routing and failover, and usage tracking with budgets. The repo's own strategy is cost-aware — rules/performance.md recommends Haiku 4.5 to save on frequent calls — so a single place to see and cap spend across models is a concrete win for these users.
The expected integration point is documentation/config-level. This repo already teaches model selection and ships MCP configs with API-key placeholders users fill in, so a natural fit is an optional guide and config example for connecting Claude Code through OrcaRouter's endpoint and mapping per-agent model pins to router-available models. Exact wiring depends on how each user's Claude Code connects to model endpoints, so this would start as documentation the maintainers can steer — I have not implemented or tested anything in this repo, and this issue is to gauge interest first.
OrcaRouter is already entering the open-source ecosystem — projects such as Dify, promptfoo, and RAGFlow are among those using it — which is what prompted this proposal.
Disclosure
OrcaRouter runs an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for integration, and I'd be glad to follow whatever disclosure or governance requirements this project prefers.
Ask
You can see projects already built with OrcaRouter at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team. Would you be open to this as an optional, documented integration? If so, I'm happy to submit an implementation PR once you've confirmed the approach and naming or scope preferences.
Everything Claude Code is a genuinely useful collection: production-ready agents, skills, hooks, commands, and rules that the author evolved over 10+ months of daily use building real products. It saves Claude Code developers from reinventing disciplined workflows — the
/plan,/tdd,/verifycadence is a concrete plan-first, test-first loop, and the session-start/session-end hooks carry context across sessions automatically.It also treats model choice deliberately:
rules/performance.mdmaps Haiku 4.5, Sonnet 4.5, and Opus 4.5 to task types, and each agent's frontmatter pins a model. Teams running this toolkit already pick models per task, so an optional way to route those requests adds real choice without disturbing the existing Anthropic setup.Proposal: OrcaRouter as an optional provider
I'd like to propose adding OrcaRouter as an optional provider. This would not replace or modify any existing provider, model pin, or configuration — the current Anthropic defaults and the
model:frontmatter on every agent stay exactly as they are.OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. One endpoint reaches many chat, reasoning, image, and video models across providers, with automatic model routing and provider failover, prompt caching, usage tracking, budgets, and team access controls.
For a Claude Code audience the most relevant capabilities are multiple models behind one endpoint, automatic routing and failover, and usage tracking with budgets. The repo's own strategy is cost-aware —
rules/performance.mdrecommends Haiku 4.5 to save on frequent calls — so a single place to see and cap spend across models is a concrete win for these users.The expected integration point is documentation/config-level. This repo already teaches model selection and ships MCP configs with API-key placeholders users fill in, so a natural fit is an optional guide and config example for connecting Claude Code through OrcaRouter's endpoint and mapping per-agent model pins to router-available models. Exact wiring depends on how each user's Claude Code connects to model endpoints, so this would start as documentation the maintainers can steer — I have not implemented or tested anything in this repo, and this issue is to gauge interest first.
OrcaRouter is already entering the open-source ecosystem — projects such as Dify, promptfoo, and RAGFlow are among those using it — which is what prompted this proposal.
Disclosure
OrcaRouter runs an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participation is not a prerequisite for integration, and I'd be glad to follow whatever disclosure or governance requirements this project prefers.
Ask
You can see projects already built with OrcaRouter at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team. Would you be open to this as an optional, documented integration? If so, I'm happy to submit an implementation PR once you've confirmed the approach and naming or scope preferences.