OrcaRouter provider support for DarkMoon (optional OpenAI-compatible LLM provider)

[putraperdana1207-pixel]

DarkMoon is an open-source AI penetration testing platform for security teams and DevSecOps engineers. Instead of a score-based scanner, it runs a full assessment on its own: 50 specialist agents chain real exploits through a controlled MCP layer and return the exact command and raw output behind every finding.

DarkMoon funnels LLM configuration through one seam, .opencode.env, written by install.sh for a cloud provider, local Ollama/llama.cpp, or an OpenAI-compatible base URL. Its Privacy Gateway tokenizes real IPs and credentials into placeholders, so a cloud model never sees the live perimeter; the docs warn model quality decides whether the autonomous loop survives. For continuous-scanning teams, OrcaRouter adds a real option there: one OpenAI-compatible endpoint over many chat and reasoning models, with failover so a campaign doesn't die on a provider outage.

Proposal

OrcaRouter exposes many chat and reasoning models through one OpenAI-compatible API with standard API-key authentication. I propose adding it as an optional LLM provider for DarkMoon; it would not replace or modify any existing provider (Anthropic, OpenRouter, OpenAI, Ollama and llama.cpp all stay as they are).

DarkMoon already centralizes LLM settings in .opencode.env, so the expected integration point is that same seam: a base URL, an API key and a model name, matching how DarkMoon's documented OpenAI-compatible endpoint option is configured. Nothing here is implemented or tested yet; this is a proposal for your feedback first.

Why it could matter for DarkMoon users

• Automatic routing and provider failover. An autonomous campaign makes many sequential model calls; when one provider rate-limits or fails, traffic continues on another model instead of losing the run.
• Prompt caching. Long multi-agent sessions repeat a lot of context, and caching can cut cost on exactly that workload.
• Usage tracking and budgets. Useful for teams driving continuous scans from CI/CD who need per-team or per-campaign cost visibility.

Ecosystem fit

OpenAI-compatible routing is an established pattern in the tooling around DarkMoon: OrcaRouter is used with goose, promptfoo, and models.dev / OpenCode, the agent runtime DarkMoon uses as its AI brain.

Transparency

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 condition for integration, and I'm happy to follow any disclosure or governance requirements DarkMoon has.

Ask

If this seems like a good fit, I'd value your opinion on the integration point and on how OrcaRouter should appear in the install.sh provider options. You can see how other open-source projects present the integration at https://www.orcarouter.ai/built-with. With your go-ahead, I'd be glad to submit an implementation PR.

I'm an engineer on the OrcaRouter team.

[MBK-fr]

Thanks for the detailed writeup, and for being upfront that you are on the OrcaRouter team.

The short version: this already works today, with no code change on our side. DarkMoon routes all LLM configuration through one OpenAI-compatible seam in .opencode.env (base URL, API key, model). Any OpenAI-compatible endpoint, OrcaRouter included, works by pointing that base URL at it. So users who want OrcaRouter's routing, failover, caching or budgets can already use it as of today.

Because of that, we would rather not add a dedicated named provider or merge a provider-specific PR. A per-vendor entry is something we deliberately avoid: the generic OpenAI-compatible option is what keeps us vendor neutral and keeps the install path small. The features you list (failover, prompt caching, usage tracking) are real, but they live entirely on the router side and need nothing from DarkMoon to be used.

What we are happy to do is a short documentation note that the OpenAI-compatible option accepts any such gateway, with a couple of neutral examples (LiteLLM, OrcaRouter, and similar). That gives your users a clear pointer without singling out one commercial provider inside the tool itself.

On the revenue share: thank you, but we will pass. For a security tool we prefer to keep provider choice free of any commercial incentive on our side, so there is no conflict of interest in what we recommend to operators.

One point specific to DarkMoon, in case it helps your users: our Privacy Gateway tokenizes real IPs, hostnames, domains and credentials before anything reaches the model, so a router placed in front of the model only ever sees placeholders, never the live perimeter. That holds regardless of which OpenAI-compatible endpoint is configured.

Leaving this open in case you want the documentation note. We would take a small docs-only PR for that if you would like to send one.