Feature Description
Wingman AI does something few other projects manage well: it makes voice-driven AI genuinely useful in games and everyday apps, letting users talk to a Wingman, have the conversation routed through whatever provider they configured, and trigger real actions — keystrokes, macros, skills — from natural speech instead of exact phrases. The provider layer is a big part of why this works. Between the ConversationProvider enum (OpenAI, Mistral, Groq, OpenRouter, Azure, Google, Cerebras, Perplexity, X.AI, local LLMs) and the OpenAi client wrapper that every conversation provider reuses, Wingman users already have more model choice than most apps, and non-developers get all of it through the client without touching YAML or worrying about per-call costs.
I'd like to propose adding OrcaRouter as another optional conversation provider. OrcaRouter is an LLM routing and governance gateway that exposes an OpenAI-compatible API at https://api.orcarouter.ai/v1 and authenticates with a standard API key, so it fits the same OpenAi(api_key=..., base_url=...) pattern Wingman already uses for local_llm, Groq, Perplexity and friends. It would be purely additive — no existing provider is replaced or changed, and users who don't enable it see no difference. I'm an engineer on the OrcaRouter team, and I'd like to understand whether the maintainers see value in this before any implementation is attempted.
Motivation / Use Case
The capability that maps most directly to Wingman's users is routing with automatic failover: the gateway grades each prompt and sends it to the model most likely to answer well, and falls back to another provider if one is down. For gamers mid-session that is a meaningful reliability win — a Wingman that stops talking because a provider rate-limited or went down is a Wingman that ruins the immersion. Prompt caching is also useful here, because latency matters when a character is supposed to sound natural, and per-request usage tracking addresses the cost concern Wingman's own README calls out for its audience.
Proposed Solution
As an integration point, this would follow the existing provider wiring: a new ConversationProvider.ORCAROUTER enum entry, an OrcaRouterConfig model (conversation model + endpoint, mirroring OpenRouterConfig), a validate_and_set_orcarouter in OpenAiWingman that builds the standard OpenAi client against the OrcaRouter base URL, and the matching secrets.yaml entry for the API key. I have not written or tested any of this code — this issue is scoped to gauging maintainer interest, and I'd welcome your input on where it should slot in. If the direction sounds right, I'd be happy to prepare an implementation PR against develop, linked to this issue per CONTRIBUTING.md, and to coordinate on Discord first as the guide suggests for new integrations.
Alternatives Considered
- Adding it via the generic "any OpenAI-compatible API" local-LLM path already works today — a user can point it at the OrcaRouter base URL with their key. This proposal is about making it a first-class, discoverable provider in the client UI with the same tool-support checks the OpenRouter provider already does.
Additional Context
OrcaRouter is already integrated into several open-source projects (e.g. RAGFlow, Dify, goose, promptfoo, DB-GPT, CAMEL), and the project keeps a "Built with OrcaRouter" showcase at https://www.orcarouter.ai/built-with. There is also an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. To be clear, participating in that program is not a condition for the integration — the feature stands on its own — and I'm happy to follow whatever disclosure or governance rules Wingman AI wants to set for something like that. I'll wait for maintainer feedback before proceeding.
Feature Description
Wingman AI does something few other projects manage well: it makes voice-driven AI genuinely useful in games and everyday apps, letting users talk to a Wingman, have the conversation routed through whatever provider they configured, and trigger real actions — keystrokes, macros, skills — from natural speech instead of exact phrases. The provider layer is a big part of why this works. Between the
ConversationProviderenum (OpenAI, Mistral, Groq, OpenRouter, Azure, Google, Cerebras, Perplexity, X.AI, local LLMs) and theOpenAiclient wrapper that every conversation provider reuses, Wingman users already have more model choice than most apps, and non-developers get all of it through the client without touching YAML or worrying about per-call costs.I'd like to propose adding OrcaRouter as another optional conversation provider. OrcaRouter is an LLM routing and governance gateway that exposes an OpenAI-compatible API at
https://api.orcarouter.ai/v1and authenticates with a standard API key, so it fits the sameOpenAi(api_key=..., base_url=...)pattern Wingman already uses forlocal_llm, Groq, Perplexity and friends. It would be purely additive — no existing provider is replaced or changed, and users who don't enable it see no difference. I'm an engineer on the OrcaRouter team, and I'd like to understand whether the maintainers see value in this before any implementation is attempted.Motivation / Use Case
The capability that maps most directly to Wingman's users is routing with automatic failover: the gateway grades each prompt and sends it to the model most likely to answer well, and falls back to another provider if one is down. For gamers mid-session that is a meaningful reliability win — a Wingman that stops talking because a provider rate-limited or went down is a Wingman that ruins the immersion. Prompt caching is also useful here, because latency matters when a character is supposed to sound natural, and per-request usage tracking addresses the cost concern Wingman's own README calls out for its audience.
Proposed Solution
As an integration point, this would follow the existing provider wiring: a new
ConversationProvider.ORCAROUTERenum entry, anOrcaRouterConfigmodel (conversation model + endpoint, mirroringOpenRouterConfig), avalidate_and_set_orcarouterinOpenAiWingmanthat builds the standardOpenAiclient against the OrcaRouter base URL, and the matchingsecrets.yamlentry for the API key. I have not written or tested any of this code — this issue is scoped to gauging maintainer interest, and I'd welcome your input on where it should slot in. If the direction sounds right, I'd be happy to prepare an implementation PR againstdevelop, linked to this issue per CONTRIBUTING.md, and to coordinate on Discord first as the guide suggests for new integrations.Alternatives Considered
Additional Context
OrcaRouter is already integrated into several open-source projects (e.g. RAGFlow, Dify, goose, promptfoo, DB-GPT, CAMEL), and the project keeps a "Built with OrcaRouter" showcase at https://www.orcarouter.ai/built-with. There is also an optional open-source partner program: approved OSS projects can receive a 5% revenue share from OrcaRouter usage attributed to their integration. To be clear, participating in that program is not a condition for the integration — the feature stands on its own — and I'm happy to follow whatever disclosure or governance rules Wingman AI wants to set for something like that. I'll wait for maintainer feedback before proceeding.