Proposal: optional OrcaRouter provider for OpenCode Manager
OpenCode Manager targets a pain point I know well: once OpenCode agents run on a server or in Docker, watching a session, checking a diff, or triggering a job from your phone is no longer trivial. A mobile-first PWA with real-time chat, multi-repo Git, and scheduled jobs — plus the ocm CLI to attach a local TUI — makes that workflow feel natural. It's why I'd like to propose one more provider option.
That workflow is built on real model choice: Settings > Providers stores per-provider API keys, with OAuth for Anthropic and GitHub Copilot, and models flow into the chat switcher as provider/model pairs. Since OpenCode Manager already treats providers as swappable, adding another OpenAI-compatible endpoint expands options for its users without changing how the app works.
I'm an engineer on the OrcaRouter team, and I'd like to propose supporting OrcaRouter as an optional provider in OpenCode Manager. It would sit entirely alongside the existing providers — nothing is replaced, and current keys and OAuth flows are untouched.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, routing requests for many chat, reasoning, and image/video models through one endpoint, with automatic model routing and provider failover, prompt caching, usage tracking, and budgets. Two of these feel especially relevant here: failover matters for Schedule jobs that run unattended against a repo, and usage tracking/budgets align with the Cost/Analytics theme in your contributing guide — a single view of spend across the models your agents use.
On integration, because the API is OpenAI-compatible with a plain API key, the expected path is the provider machinery OpenCode Manager already has: an API key stored as today under Settings > Providers, with the endpoint and models registered in the underlying OpenCode provider config so they surface through the provider/model resolution your app already uses. This is a proposal only — no code has been written or tested.
OrcaRouter is already part of the open-source agent ecosystem, with integrations such as models.dev (which feeds OpenCode model discovery), promptfoo, and goose, among others. More examples are at https://www.orcarouter.ai/built-with.
One transparent note: OrcaRouter runs an optional open-source partner program where approved projects can receive a 5% revenue share from usage attributed to their integration. Participation is not a prerequisite for integrating, and I'm happy to follow whatever disclosure or governance rules you prefer.
If this sounds useful, I'd welcome your thoughts — and with your go-ahead I'd be glad to submit an implementation PR.
Proposal: optional OrcaRouter provider for OpenCode Manager
OpenCode Manager targets a pain point I know well: once OpenCode agents run on a server or in Docker, watching a session, checking a diff, or triggering a job from your phone is no longer trivial. A mobile-first PWA with real-time chat, multi-repo Git, and scheduled jobs — plus the
ocmCLI to attach a local TUI — makes that workflow feel natural. It's why I'd like to propose one more provider option.That workflow is built on real model choice: Settings > Providers stores per-provider API keys, with OAuth for Anthropic and GitHub Copilot, and models flow into the chat switcher as provider/model pairs. Since OpenCode Manager already treats providers as swappable, adding another OpenAI-compatible endpoint expands options for its users without changing how the app works.
I'm an engineer on the OrcaRouter team, and I'd like to propose supporting OrcaRouter as an optional provider in OpenCode Manager. It would sit entirely alongside the existing providers — nothing is replaced, and current keys and OAuth flows are untouched.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, routing requests for many chat, reasoning, and image/video models through one endpoint, with automatic model routing and provider failover, prompt caching, usage tracking, and budgets. Two of these feel especially relevant here: failover matters for Schedule jobs that run unattended against a repo, and usage tracking/budgets align with the Cost/Analytics theme in your contributing guide — a single view of spend across the models your agents use.
On integration, because the API is OpenAI-compatible with a plain API key, the expected path is the provider machinery OpenCode Manager already has: an API key stored as today under Settings > Providers, with the endpoint and models registered in the underlying OpenCode provider config so they surface through the provider/model resolution your app already uses. This is a proposal only — no code has been written or tested.
OrcaRouter is already part of the open-source agent ecosystem, with integrations such as models.dev (which feeds OpenCode model discovery), promptfoo, and goose, among others. More examples are at https://www.orcarouter.ai/built-with.
One transparent note: OrcaRouter runs an optional open-source partner program where approved projects can receive a 5% revenue share from usage attributed to their integration. Participation is not a prerequisite for integrating, and I'm happy to follow whatever disclosure or governance rules you prefer.
If this sounds useful, I'd welcome your thoughts — and with your go-ahead I'd be glad to submit an implementation PR.