Problem
Atom builds governed, self-hosted AI agent workforces — a platform squarely aimed at the problem your README names: 88% of AI agent pilots never reach production. Atom's answer is autonomy that is earned, not assumed: agents advance through the STUDENT-to-AUTONOMOUS maturity tiers only after verified, outcome-checked runs, with a default-on postcondition oracle and sandbox. That lets teams delegate real work to governed agents while keeping data and keys on their own infrastructure.
Because Atom is already deliberately provider-neutral — BYOK keys for 16+ providers, plus any local OpenAI-compatible server (Ollama, LM Studio, vLLM) — an optional new provider fits the existing design instead of fighting it. For teams already relying on Atom's cost-aware routing and fallback, an OpenAI-compatible gateway that also exposes additional chat and reasoning models through a single key is simply one more choice in Settings > AI, alongside OpenAI/Anthropic/OpenRouter today.
Proposed Solution
Add OrcaRouter as an optional provider. It would not replace or change any existing provider — only add a choice for users who want it.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. In Atom's terms, it should slot into the BYOK pattern Atom already uses for unified gateways: an API key configured via Settings > AI, resolved by the existing routing and fallback layer that handles OPENROUTER_API_KEY today. Nothing here is implemented or tested — this is a proposal, and maintainers would decide where a provider fits best in the codebase.
For Atom users, the capabilities worth highlighting:
- One endpoint and key across many chat, reasoning, and image models — extending Atom's no-lock-in stance.
- Automatic model routing and provider failover — resilience at the provider layer that complements Atom's own cost-aware router and fallback.
- Prompt caching, usage tracking, and budgets — helpful for teams running many governed agents that want predictable spend, in line with Atom's existing cost-tracking and budget-alert features.
OrcaRouter is already used by open-source projects such as Dify, RAGFlow, goose, and NocoBase; the full list is at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team.
One transparent 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 the integration, and I'm happy to follow Atom's disclosure and governance requirements either way.
Alternatives Considered
- Do nothing — OrcaRouter models stay unreachable through Atom's provider UI.
- Let users point at OrcaRouter as a generic OpenAI-compatible custom endpoint; it works but is not a first-class, documented provider option in Atom.
I'd welcome maintainers' views on whether this is worth adding and, if approved, I'd be glad to submit an implementation PR following CONTRIBUTING.md.
Problem
Atom builds governed, self-hosted AI agent workforces — a platform squarely aimed at the problem your README names: 88% of AI agent pilots never reach production. Atom's answer is autonomy that is earned, not assumed: agents advance through the STUDENT-to-AUTONOMOUS maturity tiers only after verified, outcome-checked runs, with a default-on postcondition oracle and sandbox. That lets teams delegate real work to governed agents while keeping data and keys on their own infrastructure.
Because Atom is already deliberately provider-neutral — BYOK keys for 16+ providers, plus any local OpenAI-compatible server (Ollama, LM Studio, vLLM) — an optional new provider fits the existing design instead of fighting it. For teams already relying on Atom's cost-aware routing and fallback, an OpenAI-compatible gateway that also exposes additional chat and reasoning models through a single key is simply one more choice in Settings > AI, alongside OpenAI/Anthropic/OpenRouter today.
Proposed Solution
Add OrcaRouter as an optional provider. It would not replace or change any existing provider — only add a choice for users who want it.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. In Atom's terms, it should slot into the BYOK pattern Atom already uses for unified gateways: an API key configured via Settings > AI, resolved by the existing routing and fallback layer that handles
OPENROUTER_API_KEYtoday. Nothing here is implemented or tested — this is a proposal, and maintainers would decide where a provider fits best in the codebase.For Atom users, the capabilities worth highlighting:
OrcaRouter is already used by open-source projects such as Dify, RAGFlow, goose, and NocoBase; the full list is at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team.
One transparent 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 the integration, and I'm happy to follow Atom's disclosure and governance requirements either way.
Alternatives Considered
I'd welcome maintainers' views on whether this is worth adding and, if approved, I'd be glad to submit an implementation PR following CONTRIBUTING.md.