Vellum Assistant sets out to deliver a personal AI that "evolves with you" out of the box: eight kinds of memory, identity written during onboarding, and hourly proactive checks that message you only when something is unfinished or due. For anyone who has spent weekends re-hatching an OpenClaw or Claude Code setup, shipping that baseline is genuinely valuable.
That always-on design is why its provider layer matters: the assistant already runs on Anthropic, OpenAI, Gemini, Fireworks, OpenRouter, MiniMax, and Atlas Cloud, plus any OpenAI-compatible endpoint, with local models via Ollama. Adding an optional OrcaRouter endpoint would give users one OpenAI-compatible key that adds automatic failover, budgets, and wider model access, with no change to existing providers.
Problem or use case
Users configure Vellum Assistant through providers and API keys, and the catalog today is fixed. I would like OrcaRouter as an additional, optional provider. It would not replace or alter any existing provider, and current configurations would keep working exactly as they do today.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, fitting the OpenAI-compatible-endpoint abstraction Vellum Assistant already has. Capabilities most relevant to this project:
- Chat, reasoning, image, and video models through one endpoint, broadening the "any OpenAI-compatible endpoint" story into a real catalog.
- Automatic routing and provider failover, so a degraded upstream provider does not interrupt an always-on, schedule-driven assistant.
- Prompt caching, lowering cost for recurring reads of notes and
NOW.md state.
- Usage tracking and budgets, giving self-hosters per-key spend visibility and caps.
Proposed solution
The codebase already documents how a provider is added (assistant/src/providers/inference/adapter-factory.ts): add a PROVIDER_CATALOG entry in model-catalog.ts, implement a client under assistant/src/providers/<id>/, register it in ADAPTER_FACTORIES, and surface the key in cli/src/shared/provider-env-vars.ts. Because OrcaRouter is OpenAI-compatible, a client would plausibly reuse the existing OpenAI chat-completions path the way the OpenRouter provider does, with ORCAROUTER_API_KEY as the env var. This is a proposal only; nothing is implemented or tested, and I would follow CONTRIBUTING.md before writing code.
Ecosystem context
OrcaRouter has entered the open-source LLM ecosystem and is used alongside projects such as Dify, goose, and OpenCode, so its API and auth model are well exercised in agent-style contexts similar to Vellum Assistant.
Disclosure
I'm an engineer on the OrcaRouter team. Transparency note: 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. Participation is not a prerequisite for integrating, and I would follow Vellum Assistant's disclosure and governance preferences either way. See https://www.orcarouter.ai/built-with for how other projects present their integrations.
Closing
Vellum Assistant already supports OpenRouter and arbitrary OpenAI-compatible base URLs, so the differentiators above (failover, budgets, caching, model breadth behind one key) are what would make this earn its place. Would the maintainers be open to an OrcaRouter provider? If so, I would welcome guidance and, once approved, gladly open an implementation PR with tests.
Vellum Assistant sets out to deliver a personal AI that "evolves with you" out of the box: eight kinds of memory, identity written during onboarding, and hourly proactive checks that message you only when something is unfinished or due. For anyone who has spent weekends re-hatching an OpenClaw or Claude Code setup, shipping that baseline is genuinely valuable.
That always-on design is why its provider layer matters: the assistant already runs on Anthropic, OpenAI, Gemini, Fireworks, OpenRouter, MiniMax, and Atlas Cloud, plus any OpenAI-compatible endpoint, with local models via Ollama. Adding an optional OrcaRouter endpoint would give users one OpenAI-compatible key that adds automatic failover, budgets, and wider model access, with no change to existing providers.
Problem or use case
Users configure Vellum Assistant through providers and API keys, and the catalog today is fixed. I would like OrcaRouter as an additional, optional provider. It would not replace or alter any existing provider, and current configurations would keep working exactly as they do today.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, fitting the OpenAI-compatible-endpoint abstraction Vellum Assistant already has. Capabilities most relevant to this project:
NOW.mdstate.Proposed solution
The codebase already documents how a provider is added (
assistant/src/providers/inference/adapter-factory.ts): add aPROVIDER_CATALOGentry inmodel-catalog.ts, implement a client underassistant/src/providers/<id>/, register it inADAPTER_FACTORIES, and surface the key incli/src/shared/provider-env-vars.ts. Because OrcaRouter is OpenAI-compatible, a client would plausibly reuse the existing OpenAI chat-completions path the way the OpenRouter provider does, withORCAROUTER_API_KEYas the env var. This is a proposal only; nothing is implemented or tested, and I would followCONTRIBUTING.mdbefore writing code.Ecosystem context
OrcaRouter has entered the open-source LLM ecosystem and is used alongside projects such as Dify, goose, and OpenCode, so its API and auth model are well exercised in agent-style contexts similar to Vellum Assistant.
Disclosure
I'm an engineer on the OrcaRouter team. Transparency note: 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. Participation is not a prerequisite for integrating, and I would follow Vellum Assistant's disclosure and governance preferences either way. See https://www.orcarouter.ai/built-with for how other projects present their integrations.
Closing
Vellum Assistant already supports OpenRouter and arbitrary OpenAI-compatible base URLs, so the differentiators above (failover, budgets, caching, model breadth behind one key) are what would make this earn its place. Would the maintainers be open to an OrcaRouter provider? If so, I would welcome guidance and, once approved, gladly open an implementation PR with tests.