Add OrcaRouter as an optional AI provider in Mix Space

Mix Space already treats model choice as configuration rather than a hardcoded dependency: AIProviderConfig, per-feature assignments (providerId, model, reasoningEffort), and an aggregator preset category mean a self-hosted blog can run AI summaries, translation, comment moderation, and the writer agent on different models. For someone running a personal site, that flexibility is the point — AI features stay tied to their own budget and uptime rather than one vendor's.

Because that abstraction already resolves an OpenAI-compatible endpoint from a preset, OrcaRouter would slot in as one more provider rather than a new integration surface. For self-hosters who would rather hold a single key than several, it adds routing with failover across models and providers — useful when a summary job and a moderation job want different cost/quality tradeoffs.

I'm an engineer on the OrcaRouter team, and I'd like to propose adding OrcaRouter as an optional provider. It would not replace or change any provider you already support — the existing presets, per-feature assignments, and custom-endpoint flow all stay as they are.

Three capabilities seem most relevant to Mix Space's users:

• Automatic model routing and provider failover — one endpoint that grades each request and picks a model, with fallback chains when an upstream is unavailable. That pairs well with an instance where different AI features have different requirements.
• Prompt caching — cached input tokens bill at the provider's cache rate, which matters for the repeated system prompts in summary, translation, and moderation flows. It complements the gateway-scoped caching already designed for the OpenAI-compatible runtime.
• Usage tracking and budgets — per-key spend caps and request logs, so a self-hoster can see what each AI feature actually costs.

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it should fit the existing AIProviderConfig shape (endpoint, apiKey, type: openai-compatible) and the preset registry the way the current aggregator entry does. I have not implemented or tested anything here — this is a proposal only.

OrcaRouter is already used across open-source projects including Dify, RAGFlow, and goose, which may be useful reference points for the integration shape.

One transparency note: we run an optional open-source partner program where approved projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. Participating is not a condition of adding the provider, and I'm happy to follow whatever disclosure or governance rules this project has.

Details on existing integrations: https://www.orcarouter.ai/built-with

Would you be open to this? If it fits your direction, I'm glad to prepare an implementation PR for the preset and any config or docs changes you'd want reviewed first.

Start by locating AIProviderConfig, the preset registry, and the existing aggregator entry. Check how the OpenAI-compatible endpoint, API key, and provider type are represented, then compare the requested optional provider with that path. Done means OrcaRouter can be selected without changing existing presets, per-feature assignments, or custom endpoints, with any needed tests or documentation updated.