[Feature]: OrcaRouter as an optional OpenAI-compatible model source for PAIR

User problem

PAIR turns several home computers into one place to send inference requests, aimed at concurrent local workloads such as multi-agent applications. Point an existing Ollama- or OpenAI-compatible tool at the local endpoint and PAIR routes each request to a node that holds the model and has capacity. Prompts and responses stay on the local network whenever every engine is local — the right default for a home router.

The flip side is that a model no local node holds has nowhere to go: when no owner is available, the proxy returns a local 502. For PAIR users who sometimes need a model their GPUs cannot serve, an optional OpenAI-compatible hosted source behind the same endpoint would add a genuinely useful choice without disturbing the all-local default.

Desired outcome

Add OrcaRouter as an optional model source a user can enable for their cluster. It would not replace or change any existing provider: local engines, discovery, pairing, and the default all-local routing stay exactly as they are. When enabled, requests for models no local node hosts would be served through the PAIR endpoint the user already uses.

OrcaRouter exposes an OpenAI-compatible API and uses standard API-key authentication. PAIR already terminates an OpenAI-compatible surface — the LM Studio proxy answers /v1/chat/completions and reads inventory via /v1/models. The natural integration point is a new model-source adapter behind that existing proxy layer, authenticated with a user-supplied API key. Nothing here is implemented; this issue is to gauge maintainer interest before any code.

The OrcaRouter capabilities most relevant to PAIR users:

• Many chat and reasoning models through one endpoint and one API key, so a model no local node holds is no longer a dead end.
• Automatic model routing and provider failover gateway-side, complementing PAIR's scheduler for requests a user explicitly sends off-box.
• Gateway-side prompt caching, which matters once hosted tokens are metered.

OrcaRouter already integrates as an optional OpenAI-compatible provider in open-source projects such as Dify, RAGFlow, and goose.

Compatibility and security implications

Adding a hosted source extends where inference runs, which falls under CONTRIBUTING.md's rule that new model sources and APIs need maintainer alignment first — so I have not opened a pull request. It must be strictly opt-in, visible in settings, and never the default; requests sent to OrcaRouter leave the local network, and PAIR's rule that prompt text and response bodies are never logged would apply unchanged.

Alternatives considered

A user needing a bigger model can pull a quantized model onto a local node when it fits, but models no local GPU can run have no in-product route today.

Validation approach

Maintainer guidance on where the model-source abstraction belongs, then a scoped pull request behind the existing service-contract gates with unit and integration tests, plus documentation.

Disclosure

I'm an engineer on the OrcaRouter team. OrcaRouter also 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 prerequisite for this discussion or any integration, and I will follow whatever disclosure or governance rules PAIR maintainers consider appropriate. More detail is at https://www.orcarouter.ai/built-with. If this direction is welcome, I am glad to refine the design here and submit an implementation PR once approved.

Confirmations

• I searched existing issues for duplicates.
• I agree to follow the Code of Conduct.

CONTRIBUTING.md と、/v1/chat/completions および /v1/models に対する既存の LM Studio プロキシ処理から始めます。モデルソースの抽象化をどこに配置するべきかをメンテナーに確認し、その後、service-contract gates の背後にアダプターの範囲を定めます。完了条件は、厳密に opt-in の設定、変更されていないローカルルーティング、API-key 認証、ユニットテストと統合テスト、およびドキュメントです。