OPFOR's framing of adversary emulation — the opposition force that plays the enemy so the rest of the army learns what real attacks feel like — is a stance more AI teams should adopt. Where most red-team tooling is good at one thing, Opfor red-teams the whole agent surface — prompts, tools, MCP servers, memory, and multi-turn reasoning — in a single tool.
That breadth is what makes the five entry points worth having. The CLI, browser extension, MCP server, Skills, and SDK share the same evaluators, attack templates, and judge logic, so a PM or security analyst can red-team a deployed chatbot with no code while an engineer runs the identical suite in CI. Teams doing that need attacker and judge models they can trust and afford.
Area
Other (LLM provider configuration)
Problem or motivation
Adding an optional provider today means editing providerRegistryData in core/src/providers/factory.ts, so the cost of a new provider is one entry plus a few derived mirrors. Teams that want to pick attacker and judge models on price — the report already breaks testing cost down per model — currently have a fixed menu (OpenAI, Anthropic, Groq, Google, DeepSeek, Azure).
Proposed solution
Add OrcaRouter as an additional, entirely optional provider. It would not replace or change any existing provider.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it fits the existing abstraction directly: a providerRegistryData entry with displayName, defaultModel, envVar, and a build using createOpenAICompatible — the same pattern already used for Groq. Per CONTRIBUTING.md that also implies the PROVIDERS named constant, the .env.example / AGENTS.md row, EXPECTED_PROVIDER_TAG, and the SDK ProviderName union. I have not written or tested any of this yet.
Capabilities most relevant here:
- Multiple chat and reasoning models through one endpoint — one key to compare attacker vs judge models.
- Automatic model routing and provider failover — long multi-turn scans are less likely to die on a single provider hiccup.
- Usage tracking and budgets — fits the per-model testing-cost reporting Opfor already surfaces.
OrcaRouter already appears in the open-source ecosystem, including RAGFlow, Dify, and promptfoo. Examples of other integrations are at https://www.orcarouter.ai/built-with.
For transparency: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from usage attributed to their integration. Participating is not a prerequisite for the integration, and I'm glad to follow any disclosure or governance requirements this project has.
I'm an engineer on the OrcaRouter team. Would you be open to this as an optional provider? If it fits your roadmap, I'm happy to submit an implementation PR after you approve the approach.
OPFOR's framing of adversary emulation — the opposition force that plays the enemy so the rest of the army learns what real attacks feel like — is a stance more AI teams should adopt. Where most red-team tooling is good at one thing, Opfor red-teams the whole agent surface — prompts, tools, MCP servers, memory, and multi-turn reasoning — in a single tool.
That breadth is what makes the five entry points worth having. The CLI, browser extension, MCP server, Skills, and SDK share the same evaluators, attack templates, and judge logic, so a PM or security analyst can red-team a deployed chatbot with no code while an engineer runs the identical suite in CI. Teams doing that need attacker and judge models they can trust and afford.
Area
Other (LLM provider configuration)
Problem or motivation
Adding an optional provider today means editing
providerRegistryDataincore/src/providers/factory.ts, so the cost of a new provider is one entry plus a few derived mirrors. Teams that want to pick attacker and judge models on price — the report already breaks testing cost down per model — currently have a fixed menu (OpenAI, Anthropic, Groq, Google, DeepSeek, Azure).Proposed solution
Add OrcaRouter as an additional, entirely optional provider. It would not replace or change any existing provider.
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so it fits the existing abstraction directly: a
providerRegistryDataentry withdisplayName,defaultModel,envVar, and abuildusingcreateOpenAICompatible— the same pattern already used for Groq. Per CONTRIBUTING.md that also implies thePROVIDERSnamed constant, the.env.example/AGENTS.mdrow,EXPECTED_PROVIDER_TAG, and the SDKProviderNameunion. I have not written or tested any of this yet.Capabilities most relevant here:
OrcaRouter already appears in the open-source ecosystem, including RAGFlow, Dify, and promptfoo. Examples of other integrations are at https://www.orcarouter.ai/built-with.
For transparency: OrcaRouter runs an optional open-source partner program where approved OSS projects can receive a 5% revenue share from usage attributed to their integration. Participating is not a prerequisite for the integration, and I'm glad to follow any disclosure or governance requirements this project has.
I'm an engineer on the OrcaRouter team. Would you be open to this as an optional provider? If it fits your roadmap, I'm happy to submit an implementation PR after you approve the approach.