OrcaRouter provider support for web-dc-api

[zsanig22-dotcom]

web-dc-api is a browser-first, decentralized application SDK that folds server-side machinery into one DC instance - wallet identity, a per-user synced database, shared KeyValue stores, encrypted files, comments and messaging, realtime voice and whiteboards, and payments. The AI design stood out to me: dc.aiproxy keeps the model service, MCP server, auth and quota on the DC side, and callers only need an admin-issued appId / themeAuthor / theme / service tuple to make streaming calls.

Because model choice lives in that admin-managed service config rather than in each client, the developers who ship web-dc-api apps decide which models their agents can reach - so another provider option there helps end users directly. I'd like to propose OrcaRouter as one more optional backend an admin could configure through that same flow.

Proposal

OrcaRouter would be strictly additive: existing providers and the current service-config flow stay untouched. It exposes an OpenAI-compatible API and uses standard API-key authentication, which fits how web-dc-api already models services such as openai-compatible-chat (path, model, and headers/authorization in the DC-side config). An app admin could register OrcaRouter the same way, then point dc.aiproxy callers at it via the service tuple.

Capabilities most relevant to web-dc-api users:

• Multiple chat, reasoning, image and video models behind one stable endpoint, covering both streaming chat/reasoning calls and the async image/video generation flow of GenerateAndPollAIResource.
• Per-team usage tracking and budgets, complementing the quota and usage primitives dc.aiproxy already exposes (GetUserOwnAIProxyUsage, configAuth) with another cost-control lever.
• Automatic model routing and provider failover, so browser agent calls keep working if one upstream model provider has an outage.

OrcaRouter already appears in the open-source ecosystem as an OpenAI-compatible provider - Dify, RAGFlow and goose are examples - so the pattern is established rather than hypothetical.

Disclosure

One disclosure: OrcaRouter runs an optional open-source partner program in which approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Taking part is not a precondition for this proposal, and I'm glad to follow whatever disclosure or governance rules the project prefers.

Closing

I'm an engineer on the OrcaRouter team, and this is a proposal - no code has been written or tested in this repository. Examples of existing integrations are listed at https://www.orcarouter.ai/built-with. If adding an optional OrcaRouter provider would be useful for web-dc-api, I'd appreciate maintainer feedback on where it best fits the configAIProxy service model, and I'd be happy to contribute an implementation PR once approved.

[onexie]

I’m happy to help add OrcaRouter as a provider in web-dc-api. The proposal looks like it can integrate in a non-disruptive way with the existing provider/service configuration flow, and the OpenAI-compatible interface plus routing/usage tracking are definitely useful.

Please feel free to submit a PR for the OrcaRouter integration—happy to review and help align the implementation with the existing configAIProxy / service model. If there are any specific places you’d like feedback on (e.g., parameter mapping or where it should plug into the current configuration), let me know and I’ll do my best to support.