Summary
Windows-Use turns a plain-English request into real Windows GUI actions by reading the screen through the UI Automation API and letting any LLM decide what to click, type, scroll, or run - no computer-vision model required. That design is what makes it broadly useful: the agent stays provider-agnostic, so anyone on Windows can plug in the model they already use and delegate real desktop work, even switching providers or API keys mid-session with \llm and \key.
That same provider-first design is why I'd like to propose OrcaRouter as an optional provider. Windows-Use already ships providers for Anthropic, OpenAI, Google, Groq, Mistral, DeepSeek, OpenRouter, LiteLLM, and more, each an OpenAI-SDK-backed class following the BaseChatLLM protocol. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so a ChatOrcaRouter provider would slot into that same pattern exactly as ChatOpenRouter and ChatOpenAI already do - it would not replace or change any existing provider. I'm an engineer on the OrcaRouter team, and this is a contribution proposal, not a pitch.
For Windows-Use users, the concrete payoff is a single endpoint that fronts many chat, reasoning, and image models, which helps when a cheap flash model is enough for one step of a task while a stronger reasoning model is needed for the next, plus automatic model routing and provider failover. For anyone sharing a team key, prompt caching and usage tracking with budgets round out the picture. Because OrcaRouter is OpenAI-compatible and API-key based, it maps directly onto the project's existing provider/API abstraction: the implementation would be a new provider class plus wiring and a README row, like any of the existing providers.
OrcaRouter is already integrated as an optional provider in open-source projects such as RAGFlow, Dify, goose, promptfoo, and DB-GPT. It also 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 never a prerequisite for integration, and I'd be glad to follow whatever disclosure or governance requirements the project prefers. Examples are listed at https://www.orcarouter.ai/built-with.
To be clear, this is a proposal only: nothing here is implemented or tested in Windows-Use yet. I'd welcome the maintainers' thoughts on whether this fits the project, and with approval I'm happy to submit the implementation PR.
Summary
Windows-Use turns a plain-English request into real Windows GUI actions by reading the screen through the UI Automation API and letting any LLM decide what to click, type, scroll, or run - no computer-vision model required. That design is what makes it broadly useful: the agent stays provider-agnostic, so anyone on Windows can plug in the model they already use and delegate real desktop work, even switching providers or API keys mid-session with
\llmand\key.That same provider-first design is why I'd like to propose OrcaRouter as an optional provider. Windows-Use already ships providers for Anthropic, OpenAI, Google, Groq, Mistral, DeepSeek, OpenRouter, LiteLLM, and more, each an OpenAI-SDK-backed class following the
BaseChatLLMprotocol. OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so aChatOrcaRouterprovider would slot into that same pattern exactly asChatOpenRouterandChatOpenAIalready do - it would not replace or change any existing provider. I'm an engineer on the OrcaRouter team, and this is a contribution proposal, not a pitch.For Windows-Use users, the concrete payoff is a single endpoint that fronts many chat, reasoning, and image models, which helps when a cheap flash model is enough for one step of a task while a stronger reasoning model is needed for the next, plus automatic model routing and provider failover. For anyone sharing a team key, prompt caching and usage tracking with budgets round out the picture. Because OrcaRouter is OpenAI-compatible and API-key based, it maps directly onto the project's existing provider/API abstraction: the implementation would be a new provider class plus wiring and a README row, like any of the existing providers.
OrcaRouter is already integrated as an optional provider in open-source projects such as RAGFlow, Dify, goose, promptfoo, and DB-GPT. It also 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 never a prerequisite for integration, and I'd be glad to follow whatever disclosure or governance requirements the project prefers. Examples are listed at https://www.orcarouter.ai/built-with.
To be clear, this is a proposal only: nothing here is implemented or tested in Windows-Use yet. I'd welcome the maintainers' thoughts on whether this fits the project, and with approval I'm happy to submit the implementation PR.