What do you want?
Add OrcaRouter as a first-class, named provider in Cebian's Settings → Providers list (the "Via API Key" group), mirroring how OpenRouter is already integrated — rather than requiring users to configure it as an anonymous "OpenAI Compatible" custom provider.
OrcaRouter is an OpenAI-compatible AI gateway at https://api.orcarouter.ai/v1. It exposes a provider/model namespace (anthropic/claude-…, openai/gpt-…, deepseek/…, …) plus its own auto-routing models (orcarouter/auto, orcarouter/fusion, …), and combines adaptive routing, automatic failover, zero-markup inference, observability, guardrails, and agent-tool governance behind one endpoint.
Why?
Cebian's README advertises "OpenAI, Anthropic, Google, and any OpenAI-compatible endpoint via custom providers". A gateway like OrcaRouter is a natural fit as a named provider: users bring their own OrcaRouter API key and get the whole routed model namespace — including the orcarouter/* auto-routing models that don't belong to any single vendor — without manually filling in a custom base URL. This matches the existing OpenRouter experience.
How? (optional sketch)
- Add
{ provider: 'orcarouter', label: 'OrcaRouter' } to APIKEY_PROVIDERS in lib/providers/registry.ts.
- Provide a small local catalog for OrcaRouter's native routing models (
orcarouter/auto, orcarouter/free, orcarouter/fusion, …) since they live outside pi-ai's generated catalog — mirroring the OpenRouter attribution headers.
- Wire the catalog through
resolveModel, listUsableModelGroups, ProviderApiKeyItem, and ProviderSummary.
Alternatives considered
Users today can already add OrcaRouter as a custom OpenAI-compatible provider. The downside is they must know the exact base URL and maintain their own model list, and the orcarouter/* routing models aren't surfaced. A named provider makes it a one-click setup like OpenRouter.
What do you want?
Add OrcaRouter as a first-class, named provider in Cebian's Settings → Providers list (the "Via API Key" group), mirroring how OpenRouter is already integrated — rather than requiring users to configure it as an anonymous "OpenAI Compatible" custom provider.
OrcaRouter is an OpenAI-compatible AI gateway at
https://api.orcarouter.ai/v1. It exposes a provider/model namespace (anthropic/claude-…,openai/gpt-…,deepseek/…, …) plus its own auto-routing models (orcarouter/auto,orcarouter/fusion, …), and combines adaptive routing, automatic failover, zero-markup inference, observability, guardrails, and agent-tool governance behind one endpoint.Why?
Cebian's README advertises "OpenAI, Anthropic, Google, and any OpenAI-compatible endpoint via custom providers". A gateway like OrcaRouter is a natural fit as a named provider: users bring their own OrcaRouter API key and get the whole routed model namespace — including the
orcarouter/*auto-routing models that don't belong to any single vendor — without manually filling in a custom base URL. This matches the existing OpenRouter experience.How? (optional sketch)
{ provider: 'orcarouter', label: 'OrcaRouter' }toAPIKEY_PROVIDERSinlib/providers/registry.ts.orcarouter/auto,orcarouter/free,orcarouter/fusion, …) since they live outside pi-ai's generated catalog — mirroring the OpenRouter attribution headers.resolveModel,listUsableModelGroups,ProviderApiKeyItem, andProviderSummary.Alternatives considered
Users today can already add OrcaRouter as a custom OpenAI-compatible provider. The downside is they must know the exact base URL and maintain their own model list, and the
orcarouter/*routing models aren't surfaced. A named provider makes it a one-click setup like OpenRouter.