Memex is a refreshing take on journaling: instead of asking people to sit down and write polished daily entries, it lets them capture life in fragments (text, photos, and voice) while a multi-agent system organizes those fragments into timeline cards, a P.A.R.A. knowledge base, and insight cards. The local-first design is what makes it work: records and knowledge stay on the device, and no Memex server holds your journal.
Because users bring their own LLM keys, that privacy promise depends on real model choice. Memex already treats OpenAI-compatible providers such as Kimi, Qwen, DeepSeek, and OpenRouter as first-class options and lets each agent use a different model independently. An optional provider speaking that same OpenAI-compatible language would slot straight into the workflow, which is why I'd like to propose OrcaRouter.
Provider name
OrcaRouter, an optional OpenAI-compatible model gateway. This is purely additive: it would not replace or change any existing provider such as Gemini, Claude, OpenRouter, or Ollama.
API compatibility
OpenAI-compatible.
Why OrcaRouter for Memex users
- Many model families, one endpoint: chat, reasoning, image, and video models from multiple upstreams behind a single key, so users can cover more agent roles without adding a provider entry per model family.
- Model routing and provider failover: if an upstream is down or overloaded, requests route to a healthy provider, which matters for unattended background agents such as auto-commentary and memory curation.
- Usage tracking and budgets: users who pay their own providers can watch spend across Memex agents.
Provider documentation
https://www.orcarouter.ai and the built-with directory https://www.orcarouter.ai/built-with.
Authentication and base URL
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. The expected integration point is the OpenAI-compatible adapter path already used by Kimi, Qwen, DeepSeek, and OpenRouter in lib/llm_client/, with users supplying their own key and base URL so credentials stay explicitly user-configured. This is a proposal only; no code has been written or tested.
OrcaRouter is already adopted by open-source projects including RAGFlow, Dify, goose, and promptfoo. I also want to be transparent that OrcaRouter runs an optional open-source partner program: 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'm happy to follow Memex's disclosure and governance requirements.
I'd welcome your thoughts on whether this fits Memex's provider direction. If maintainers are open to it, I'm an engineer on the OrcaRouter team and would be glad to submit an implementation PR once you've reviewed the design.
Privacy check
Memex is a refreshing take on journaling: instead of asking people to sit down and write polished daily entries, it lets them capture life in fragments (text, photos, and voice) while a multi-agent system organizes those fragments into timeline cards, a P.A.R.A. knowledge base, and insight cards. The local-first design is what makes it work: records and knowledge stay on the device, and no Memex server holds your journal.
Because users bring their own LLM keys, that privacy promise depends on real model choice. Memex already treats OpenAI-compatible providers such as Kimi, Qwen, DeepSeek, and OpenRouter as first-class options and lets each agent use a different model independently. An optional provider speaking that same OpenAI-compatible language would slot straight into the workflow, which is why I'd like to propose OrcaRouter.
Provider name
OrcaRouter, an optional OpenAI-compatible model gateway. This is purely additive: it would not replace or change any existing provider such as Gemini, Claude, OpenRouter, or Ollama.
API compatibility
OpenAI-compatible.
Why OrcaRouter for Memex users
Provider documentation
https://www.orcarouter.ai and the built-with directory https://www.orcarouter.ai/built-with.
Authentication and base URL
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. The expected integration point is the OpenAI-compatible adapter path already used by Kimi, Qwen, DeepSeek, and OpenRouter in
lib/llm_client/, with users supplying their own key and base URL so credentials stay explicitly user-configured. This is a proposal only; no code has been written or tested.OrcaRouter is already adopted by open-source projects including RAGFlow, Dify, goose, and promptfoo. I also want to be transparent that OrcaRouter runs an optional open-source partner program: 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'm happy to follow Memex's disclosure and governance requirements.
I'd welcome your thoughts on whether this fits Memex's provider direction. If maintainers are open to it, I'm an engineer on the OrcaRouter team and would be glad to submit an implementation PR once you've reviewed the design.
Privacy check