OrcaRouter provider support for deco Studio

deco Studio takes a problem most teams meet late in an AI rollout — giving agents governed access to private systems without copying credentials — and answers it with a single control plane: MCP connections registered once at the organization level, tokens in an encrypted vault, and tool-level access granted by role or agent. Making each agent its own MCP endpoint, callable from Cursor, Claude Desktop, or another agent, is the detail that turns it into a platform rather than another chat UI.

That design only pays off if the model layer stays as interchangeable as the README promises. For the platform teams running Studio internally, adding OrcaRouter as another selectable provider would widen the approved-model menu per agent without disturbing OpenRouter, Anthropic, or any existing option.

Describe the problem you want to solve

Studio already treats models as a swappable layer chosen per agent and per tool, but each upstream costs one credential and one relationship. Teams that want a wide model menu, per-key spend limits, and resilience when a single upstream degrades end up managing that outside Studio.

Propose your solution

Add OrcaRouter as an optional provider in the hosted provider registry, alongside the existing entries. It would not replace or change any current provider — OpenRouter, Anthropic, Google, llmapi, and the custom OpenAI-compatible adapter would all stay exactly as they are.

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it maps onto the existing ProviderAdapter shape with no new auth flow: an adapter under apps/api/src/ai-providers/adapters/ returning a StudioProvider, registered in registry.ts and listed in HOSTED_PROVIDER_IDS, reusing the "api-key" method the custom OpenAI-compatible adapter already uses (base URL + key, chat completions). I have not written or tested this — it is a sketch of where the integration would land, not a claim that it exists.

The capabilities that matter most here:

• Multiple chat, reasoning, image, and video models behind one endpoint, so a per-agent model policy reaches a wider menu without a new credential per vendor.
• Automatic routing and provider failover, keeping agent runs alive when one upstream is degraded or rate-limited.
• Usage tracking and budgets, which would feed the Observability view and the roadmap item "Cost analytics and spend caps" instead of a separate dashboard.
• Prompt caching, which trims the repeated context that agent loops carry.

OrcaRouter is already used across open-source projects including goose, promptfoo, and Dify; more at https://www.orcarouter.ai/built-with.

Worth disclosing up front: 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 optional and not a precondition for this integration — I'm raising the provider idea on its own merits, and glad to follow whatever disclosure or governance rules the project prefers.

I'm an engineer on the OrcaRouter team. I'd like to hear whether this fits your roadmap and how you'd want it shaped — happy to open an implementation PR if the direction is welcome.

Start in apps/api/src/ai-providers/adapters/ and compare the existing custom OpenAI-compatible adapter with the ProviderAdapter and StudioProvider shapes. Then inspect registry.ts and HOSTED_PROVIDER_IDS to see how hosted providers are registered; done means OrcaRouter is selectable alongside the existing providers through the api-key method without changing those providers.