Berd is a desktop app for getting work done with AI agents — a calm surface where builders keep a persistent agent companion attached to projects, skills, and local context. What stands out is how deliberately Berd treats provider configuration as part of the workflow: it fetches a provider's live model list on connect so the key, URL, and network are verified in one shot, and it maps provider errors to actionable causes so a failed turn stays explainable.
People who add a custom OpenAI-compatible endpoint in Berd already want more model options without more setup friction. An OrcaRouter provider would give them one endpoint spanning many chat and reasoning models, with automatic failover when an upstream provider is down or throttled — a natural extension of the provider choice Berd already champions.
Before filing
Closest existing issue: none found. Is this new, or an improvement? New capability.
The problem, in your terms
People switch models per task across a day, and holding several provider accounts and keys breaks the continuity Berd preserves when one upstream provider is rate-limited or down mid-task.
What you do today
Adding OrcaRouter by hand as a custom OpenAI-compatible provider works but stays undiscoverable — no directory entry or first-class status.
What you'd like to see
Support for OrcaRouter as an optional, discoverable provider via the same seams the directory uses for curated and template providers — without replacing or changing any existing provider. OrcaRouter exposes an OpenAI-compatible API with standard API-key authentication, so the integration point is Berd's existing OpenAI-compatible provider path (base URL/API path + key, live model-list fetch). Its most relevant features: one endpoint across chat and reasoning models, automatic routing with provider failover, and usage tracking with budgets. I'm describing where it would plug in; nothing is implemented or tested yet.
Why this belongs in Berd itself
Provider choice is core surface here, not a skill or automation: Berd already curates Anthropic, OpenAI, Google, and OpenRouter and ships a custom-provider template flow, and a router adding failover strengthens the whole catalog.
Non-goals
No replacement of existing providers, no new auth mechanism, and no partner program as a condition of integration.
Alternatives you considered
Separate provider accounts multiply key management and leave failover to the user. OpenRouter is already promoted as a router; OrcaRouter adds automatic failover across providers plus the open-source partner program below.
Mockups, prior art, or other context
I'm an engineer on the OrcaRouter team. OrcaRouter is already used in the open-source ecosystem — integrations with Dify, promptfoo, and goose (the agent runtime Berd builds on) are in place, with more at https://www.orcarouter.ai/built-with.
We also run an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. That is optional and not a prerequisite, and I'll follow any disclosure or governance expectations Berd has. I'd welcome the maintainers' view on fit; with approval I'm happy to submit an implementation PR through the normal contribution path.
Berd is a desktop app for getting work done with AI agents — a calm surface where builders keep a persistent agent companion attached to projects, skills, and local context. What stands out is how deliberately Berd treats provider configuration as part of the workflow: it fetches a provider's live model list on connect so the key, URL, and network are verified in one shot, and it maps provider errors to actionable causes so a failed turn stays explainable.
People who add a custom OpenAI-compatible endpoint in Berd already want more model options without more setup friction. An OrcaRouter provider would give them one endpoint spanning many chat and reasoning models, with automatic failover when an upstream provider is down or throttled — a natural extension of the provider choice Berd already champions.
Before filing
Closest existing issue: none found. Is this new, or an improvement? New capability.
The problem, in your terms
People switch models per task across a day, and holding several provider accounts and keys breaks the continuity Berd preserves when one upstream provider is rate-limited or down mid-task.
What you do today
Adding OrcaRouter by hand as a custom OpenAI-compatible provider works but stays undiscoverable — no directory entry or first-class status.
What you'd like to see
Support for OrcaRouter as an optional, discoverable provider via the same seams the directory uses for curated and template providers — without replacing or changing any existing provider. OrcaRouter exposes an OpenAI-compatible API with standard API-key authentication, so the integration point is Berd's existing OpenAI-compatible provider path (base URL/API path + key, live model-list fetch). Its most relevant features: one endpoint across chat and reasoning models, automatic routing with provider failover, and usage tracking with budgets. I'm describing where it would plug in; nothing is implemented or tested yet.
Why this belongs in Berd itself
Provider choice is core surface here, not a skill or automation: Berd already curates Anthropic, OpenAI, Google, and OpenRouter and ships a custom-provider template flow, and a router adding failover strengthens the whole catalog.
Non-goals
No replacement of existing providers, no new auth mechanism, and no partner program as a condition of integration.
Alternatives you considered
Separate provider accounts multiply key management and leave failover to the user. OpenRouter is already promoted as a router; OrcaRouter adds automatic failover across providers plus the open-source partner program below.
Mockups, prior art, or other context
I'm an engineer on the OrcaRouter team. OrcaRouter is already used in the open-source ecosystem — integrations with Dify, promptfoo, and goose (the agent runtime Berd builds on) are in place, with more at https://www.orcarouter.ai/built-with.
We also run an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. That is optional and not a prerequisite, and I'll follow any disclosure or governance expectations Berd has. I'd welcome the maintainers' view on fit; with approval I'm happy to submit an implementation PR through the normal contribution path.