DeepSeek Harness Studio is the part of the Harness ecosystem that makes the workbench reachable without a terminal: an Electron app for macOS and Windows that supervises a local dsh web host, so plugin discovery, trusted installation, and the bundled Agent Presets become a few clicks instead of a shell session.
Studio already treats models as a first-class, user-configured surface: the Settings model list accepts DeepSeek and compatible providers, and the local-model flow covers Ollama, vLLM, SGLang, and any custom /v1/chat/completions endpoint, with vision enhancement routing through a verified Bailian or OpenRouter provider. For the desktop users this project targets, one endpoint that fronts many chat, reasoning, and image models is an extension of that same surface rather than a new concept to learn.
I'm an engineer on the OrcaRouter team, and I'd like to propose OrcaRouter as an optional provider in Studio's model settings. It would sit alongside the existing entries; it would not replace or change any current provider.
Why it could fit
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the expected integration point is the abstraction Studio already has: a user-supplied base URL, model id, and API key, the same shape used by the custom /v1/chat/completions provider and the compatible-vision provider list. I am not claiming any code exists or has been tested. This issue is a proposal, and I would expect the change to be one more selectable provider entry rather than a rewrite.
What it would add for Studio users
- Many chat, reasoning, and image models behind a single endpoint and key, so a desktop user configures one provider instead of several.
- Automatic model routing and provider failover, so one upstream hiccup does not stall a long Workflow or SubAgent run.
- Usage tracking and budgets, so spend is visible where models are otherwise just a key stored in Settings.
- Prompt caching, which lowers the cost of the long, tool-heavy sessions the Harness is built around.
Ecosystem
OrcaRouter is already used by open-source projects including Dify, goose, and promptfoo, and is listed in models.dev, so there is prior art for this kind of provider entry.
Disclosure
For transparency: OrcaRouter 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. Taking part is not a prerequisite for the integration, and I am glad to follow whatever disclosure or governance rules the project prefers.
More examples are at https://www.orcarouter.ai/built-with. If this direction fits Studio, I would welcome the maintainers' thoughts, and with your approval I would be happy to submit an implementation PR.
DeepSeek Harness Studio is the part of the Harness ecosystem that makes the workbench reachable without a terminal: an Electron app for macOS and Windows that supervises a local
dsh webhost, so plugin discovery, trusted installation, and the bundled Agent Presets become a few clicks instead of a shell session.Studio already treats models as a first-class, user-configured surface: the Settings model list accepts DeepSeek and compatible providers, and the local-model flow covers Ollama, vLLM, SGLang, and any custom
/v1/chat/completionsendpoint, with vision enhancement routing through a verified Bailian or OpenRouter provider. For the desktop users this project targets, one endpoint that fronts many chat, reasoning, and image models is an extension of that same surface rather than a new concept to learn.I'm an engineer on the OrcaRouter team, and I'd like to propose OrcaRouter as an optional provider in Studio's model settings. It would sit alongside the existing entries; it would not replace or change any current provider.
Why it could fit
OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication, so the expected integration point is the abstraction Studio already has: a user-supplied base URL, model id, and API key, the same shape used by the custom
/v1/chat/completionsprovider and the compatible-vision provider list. I am not claiming any code exists or has been tested. This issue is a proposal, and I would expect the change to be one more selectable provider entry rather than a rewrite.What it would add for Studio users
Ecosystem
OrcaRouter is already used by open-source projects including Dify, goose, and promptfoo, and is listed in models.dev, so there is prior art for this kind of provider entry.
Disclosure
For transparency: OrcaRouter 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. Taking part is not a prerequisite for the integration, and I am glad to follow whatever disclosure or governance rules the project prefers.
More examples are at https://www.orcarouter.ai/built-with. If this direction fits Studio, I would welcome the maintainers' thoughts, and with your approval I would be happy to submit an implementation PR.