Proposal: add OrcaRouter as an optional provider
Claudish is genuinely useful because it solves the lock-in problem every Claude Code user eventually hits. Proxying Claude Code through a local Anthropic-compatible server so it can run on subscription-backed models like Gemini Advanced or ChatGPT Plus/Codex, or fully offline on Ollama, is a design that puts choice and cost first. The provider@model[:concurrency] syntax and the three-layer adapter model (wire format, model dialect, transport) keep one tool current as new model families ship weekly.
That emphasis on choice and cost is why more provider options help your users. Claudish already routes through aggregators like OpenRouter and OpenAI-compatible endpoints (LiteLLM, Cohere, the bundled 25-vendor catalog), so users who prefer one API key over one per vendor have a workflow worth extending. An OrcaRouter entry would fit it as another independent choice.
I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter as an optional provider for Claudish. It would not replace or change any existing provider; it would simply be one more option for users who want it.
OrcaRouter exposes an OpenAI-compatible API with standard API-key authentication and provides access to many chat, reasoning, image, and video models through one endpoint. The capabilities that seem most relevant to Claudish users:
- Automatic model routing and provider failover - a coding session can fall back to another provider instead of dying on an outage or rate limit.
- Prompt caching - repeated context such as a large codebase in every request can be served from cache, cutting latency and cost.
- Usage tracking and budgets - complements Claudish's existing
--cost-track / --cost-audit accounting, especially for teams or heavy automation.
- One endpoint for many model families - an independent aggregator alternative, still behind a single API key.
On the integration point: based on the docs, an OpenAI-compatible provider can register through the existing customEndpoints / predefined-endpoint path (a baseUrl plus an API-key env var) and flow through the OpenAI-format adapter layer, much like LiteLLM and Cohere's OpenAI-compatibility layer already do. I have not implemented or tested anything yet - this issue is to gauge interest and get your read on the right insertion point before any code is written.
OrcaRouter is already used by open-source projects including Dify, RAGFlow, goose, and NocoBase - see https://www.orcarouter.ai/built-with.
One transparent disclosure: 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. Participation is entirely optional and not a prerequisite for this integration, and I'm happy to follow whatever disclosure or governance rules Claudish prefers.
If this sounds useful, I'd welcome your thoughts on where it fits - and with your go-ahead, I'd be glad to submit an implementation PR.
Proposal: add OrcaRouter as an optional provider
Claudish is genuinely useful because it solves the lock-in problem every Claude Code user eventually hits. Proxying Claude Code through a local Anthropic-compatible server so it can run on subscription-backed models like Gemini Advanced or ChatGPT Plus/Codex, or fully offline on Ollama, is a design that puts choice and cost first. The
provider@model[:concurrency]syntax and the three-layer adapter model (wire format, model dialect, transport) keep one tool current as new model families ship weekly.That emphasis on choice and cost is why more provider options help your users. Claudish already routes through aggregators like OpenRouter and OpenAI-compatible endpoints (LiteLLM, Cohere, the bundled 25-vendor catalog), so users who prefer one API key over one per vendor have a workflow worth extending. An OrcaRouter entry would fit it as another independent choice.
I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter as an optional provider for Claudish. It would not replace or change any existing provider; it would simply be one more option for users who want it.
OrcaRouter exposes an OpenAI-compatible API with standard API-key authentication and provides access to many chat, reasoning, image, and video models through one endpoint. The capabilities that seem most relevant to Claudish users:
--cost-track/--cost-auditaccounting, especially for teams or heavy automation.On the integration point: based on the docs, an OpenAI-compatible provider can register through the existing
customEndpoints/ predefined-endpoint path (abaseUrlplus an API-key env var) and flow through the OpenAI-format adapter layer, much like LiteLLM and Cohere's OpenAI-compatibility layer already do. I have not implemented or tested anything yet - this issue is to gauge interest and get your read on the right insertion point before any code is written.OrcaRouter is already used by open-source projects including Dify, RAGFlow, goose, and NocoBase - see https://www.orcarouter.ai/built-with.
One transparent disclosure: 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. Participation is entirely optional and not a prerequisite for this integration, and I'm happy to follow whatever disclosure or governance rules Claudish prefers.
If this sounds useful, I'd welcome your thoughts on where it fits - and with your go-ahead, I'd be glad to submit an implementation PR.