Metis is an agentic AI security framework for deep security code review, built for a very concrete problem: finding subtle vulnerabilities in large or legacy codebases without drowning reviewers in false positives. Instead of hardcoded rules, Metis relies on LLM semantic reasoning, anchors each finding in deterministic, source-local evidence from its tree-sitter-backed CodeGraph, and validates issues from its own analysis and third-party SAST tools. For security reviewers, that is what keeps deep review sessions productive rather than exhausting.
Metis already routes chat through pluggable providers (OpenAI, Azure OpenAI, Anthropic, Gemini, Bedrock, vLLM, Ollama, llama.cpp) configured in metis.yaml. OrcaRouter would slot into that same abstraction as another optional entry, so security reviewers could point Metis at one endpoint and pick among more model families per review run — with no extra per-provider configuration.
Proposal: add OrcaRouter as an optional chat provider
I'd like to propose adding OrcaRouter as an optional provider for Metis. It would be strictly additive — existing providers stay unchanged, and no user would be required to adopt it.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it fits the path Metis already documents in docs/providers/adding-new-provider.md: an orcarouter module subclassing OpenAICompatibleChatProvider from src/metis/providers/openai_compatible.py, a ProviderConfigSpec (base URL, model, API-key env var), and a metis.providers entry point so it appears beside the built-ins. To be clear, this is a proposal — no code has been written or tested against Metis yet.
For Metis users, a few OrcaRouter capabilities stand out:
- One endpoint, many model families — pick a chat or reasoning model suited to each review's language and depth without maintaining separate provider configs.
- Automatic routing and failover — if an upstream model is rate-limited during a long batch review, requests route to an available model instead of aborting the run.
- Cost visibility and control — usage tracking and budgets keep spend predictable for teams running reviews continuously, and prompt caching lowers cost when the same codebase context is reused across findings.
OrcaRouter is already used in the open-source ecosystem — Dify, RAGFlow, and goose ship integrations — and Metis's plugin-friendly design makes it a natural fit.
Full disclosure: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from usage attributed to their integration. It is not a prerequisite for the integration, and I'm happy to follow Metis's disclosure and governance expectations, or decline participation if maintainers prefer.
More examples are at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team — if maintainers are open to this, I'd welcome your view on scope (chat-only vs. also embedding) and, with your go-ahead, would be glad to submit an implementation PR.
Metis is an agentic AI security framework for deep security code review, built for a very concrete problem: finding subtle vulnerabilities in large or legacy codebases without drowning reviewers in false positives. Instead of hardcoded rules, Metis relies on LLM semantic reasoning, anchors each finding in deterministic, source-local evidence from its tree-sitter-backed CodeGraph, and validates issues from its own analysis and third-party SAST tools. For security reviewers, that is what keeps deep review sessions productive rather than exhausting.
Metis already routes chat through pluggable providers (OpenAI, Azure OpenAI, Anthropic, Gemini, Bedrock, vLLM, Ollama, llama.cpp) configured in
metis.yaml. OrcaRouter would slot into that same abstraction as another optional entry, so security reviewers could point Metis at one endpoint and pick among more model families per review run — with no extra per-provider configuration.Proposal: add OrcaRouter as an optional chat provider
I'd like to propose adding OrcaRouter as an optional provider for Metis. It would be strictly additive — existing providers stay unchanged, and no user would be required to adopt it.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it fits the path Metis already documents in
docs/providers/adding-new-provider.md: anorcaroutermodule subclassingOpenAICompatibleChatProviderfromsrc/metis/providers/openai_compatible.py, aProviderConfigSpec(base URL, model, API-key env var), and ametis.providersentry point so it appears beside the built-ins. To be clear, this is a proposal — no code has been written or tested against Metis yet.For Metis users, a few OrcaRouter capabilities stand out:
OrcaRouter is already used in the open-source ecosystem — Dify, RAGFlow, and goose ship integrations — and Metis's plugin-friendly design makes it a natural fit.
Full disclosure: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from usage attributed to their integration. It is not a prerequisite for the integration, and I'm happy to follow Metis's disclosure and governance expectations, or decline participation if maintainers prefer.
More examples are at https://www.orcarouter.ai/built-with. I'm an engineer on the OrcaRouter team — if maintainers are open to this, I'd welcome your view on scope (chat-only vs. also embedding) and, with your go-ahead, would be glad to submit an implementation PR.