Everroom calls itself a local-first personal context workspace, and the problem it takes on is the part before any useful AI answer: finding the relevant material, separating facts from guesses, and keeping generated work tied to its sources. The Evidence ledger and Context Room model make that credible - a Room gives the Agent a bounded, inspectable scope instead of a global prompt dump, so someone running a long-lived project can trace a summary to its source. That is why it is worth giving more model reach.
Since Everroom already resolves every model call through a provider / model / base URL / API-key tuple, adding OrcaRouter as an option would let its users draw on many models through one credential without disturbing the setup they already have.
With that in mind, I'd like to propose OrcaRouter as an additional, optional provider. It would not replace or change any existing provider. Concretely, Everroom's configuration surface is NXCORE_AI_PROVIDER, NXCORE_AI_MODEL, NXCORE_AI_BASE_URL, NXCORE_AI_API_KEY, with NXCORE_AI_API accepting openai-completions or openai-responses, and I'd expect OrcaRouter to sit behind that existing boundary rather than introduce a new one.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. The capabilities most relevant here are: multiple chat, reasoning, and image/video models through one endpoint and one credential, which suits the several independent roles Everroom already configures (primary, background, cursor completion, knowledge, web search); automatic model routing and provider failover, which fits a project that treats graceful degradation as a design principle; and usage tracking with budgets, which pairs naturally with the existing external-call budget boundary. To be clear, I have not written or tested any code for this - it is a proposal.
I'm an engineer on the OrcaRouter team. OrcaRouter is already present in the open-source ecosystem - RAGFlow, Dify, goose, and OpenCode, the last of which appears in Everroom's own roadmap for replaceable Agent adapters.
In the interest of transparency: we run 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 prerequisite for the integration, and we're glad to follow whatever disclosure or governance requirements the project sets.
More detail is at https://www.orcarouter.ai/built-with. Would the maintainers be open to OrcaRouter as an optional provider? If so, I'd be happy to prepare an implementation PR that aligns with the current contracts after your go-ahead.
Everroom calls itself a local-first personal context workspace, and the problem it takes on is the part before any useful AI answer: finding the relevant material, separating facts from guesses, and keeping generated work tied to its sources. The Evidence ledger and Context Room model make that credible - a Room gives the Agent a bounded, inspectable scope instead of a global prompt dump, so someone running a long-lived project can trace a summary to its source. That is why it is worth giving more model reach.
Since Everroom already resolves every model call through a provider / model / base URL / API-key tuple, adding OrcaRouter as an option would let its users draw on many models through one credential without disturbing the setup they already have.
With that in mind, I'd like to propose OrcaRouter as an additional, optional provider. It would not replace or change any existing provider. Concretely, Everroom's configuration surface is
NXCORE_AI_PROVIDER,NXCORE_AI_MODEL,NXCORE_AI_BASE_URL,NXCORE_AI_API_KEY, withNXCORE_AI_APIacceptingopenai-completionsoropenai-responses, and I'd expect OrcaRouter to sit behind that existing boundary rather than introduce a new one.OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. The capabilities most relevant here are: multiple chat, reasoning, and image/video models through one endpoint and one credential, which suits the several independent roles Everroom already configures (primary, background, cursor completion, knowledge, web search); automatic model routing and provider failover, which fits a project that treats graceful degradation as a design principle; and usage tracking with budgets, which pairs naturally with the existing external-call budget boundary. To be clear, I have not written or tested any code for this - it is a proposal.
I'm an engineer on the OrcaRouter team. OrcaRouter is already present in the open-source ecosystem - RAGFlow, Dify, goose, and OpenCode, the last of which appears in Everroom's own roadmap for replaceable Agent adapters.
In the interest of transparency: we run 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 prerequisite for the integration, and we're glad to follow whatever disclosure or governance requirements the project sets.
More detail is at https://www.orcarouter.ai/built-with. Would the maintainers be open to OrcaRouter as an optional provider? If so, I'd be happy to prepare an implementation PR that aligns with the current contracts after your go-ahead.