microsoft / microsoft/vscode

Feature request: Support bring-your-own-model (BYO) routers (e.g. OpenRouter Fusion Router)

Open
#325,844 1 comment 0 reactions 1 assignee Claimed by @vritant24 View on GitHub
Dominant language
TypeScript
Stars
193k
Forks
42.4k
PR merge metrics
PR metrics pending

Description

## Feature request: Support bring-your-own-model (BYO) routers in VS Code

### Summary

VS Code's Chat / language model provider system lets users bring their own API keys for supported providers (OpenAI, Anthropic, Azure, Ollama, OpenAI-compatible endpoints, etc.). Increasingly, though, the useful unit isn't a single model — it's a **router**: an endpoint that accepts one model slug but internally orchestrates *multiple* models (parallel deliberation, judging, fallback, cost/latency routing) and streams back a single response.

I'd like VS Code to first-class support **BYO model routers** so users can point Chat / agent mode at a router endpoint and have it work end-to-end, including tool calling and streaming.

### Motivating example

OpenRouter's **Fusion Router** (`openrouter/fusion`) is a good concrete example:
https://openrouter.ai/docs/guides/routing/routers/fusion-router

With Fusion, you send a request with `model: "openrouter/fusion"`. The router resolves the alias to a real model and attaches a multi-model deliberation tool (`openrouter:fusion`). When invoked, a panel of up to 8 models answers the prompt in parallel (each with web search/fetch), a judge model compares the responses and returns structured analysis (consensus, contradictions, coverage gaps, unique insights, blind spots), and the outer model uses that analysis to write a better final answer. There's also a server-tool form (`{ "type": "openrouter:fusion" }`) and preset variants like `openrouter/fusion-flash`.

The key point: from the client's perspective it's *one* OpenAI-compatible chat completion call to `openrouter/fusion`, but under the hood it fans out to many models. Routers like this (Fusion, plus OpenRouter's auto/nitro routing, and other gateways) are becoming a common way people consume models.

### Problem today

- The model picker and provider config are largely oriented around enumerating concrete models. Router "meta-models" (aliases that don't map 1:1 to a fixed model) don't fit cleanly.
- Behaviors routers rely on — server-side tool injection, provider-defined tool types (e.g. `openrouter:fusion`, `openrouter:web_search`), streaming intermediate/deliberation state, and per-request routing plugins/presets — aren't first-class.
- Users who wire a router in via the OpenAI-compatible path often hit friction around model discovery, tool-calling compatibility, and passing router-specific parameters (`plugins`, `preset`, `tool_choice: "required"`, etc.).

### Proposed capabilities

1. **Router-aware provider config** — let users register a router endpoint + API key and declare/refresh available router slugs (including aliases like `openrouter/fusion`, `openrouter/fusion-flash`) rather than requiring a fixed model list.
2. **Pass-through of router-specific request parameters** — a supported way to attach provider extensions per request (e.g. `plugins`, `preset`, `tool_choice`) without patching the extension host.
3. **Provider-defined / server tools** — accommodate tools the router injects itself (e.g. `{ "type": "openrouter:fusion" }`) so tool calling still works end-to-end.
4. **Streaming of intermediate router state (optional)** — surface deliberation/routing progress in the Chat UI when the router emits it.
5. **Docs/guidance** — a documented, supported recipe for pointing Chat/agent mode at a BYO router.

### Why this matters

Routers meaningfully improve answer quality and reliability for hard prompts (research, expert critique, "compare and contrast", high-cost-of-being-wrong tasks) and let users optimize cost/latency without app-level changes. Making them first-class in VS Code would let the community bring the rapidly-growing ecosystem of model routers directly into Chat and agent workflows.

### Alternatives considered

- Treating the router as a plain OpenAI-compatible model — works partially, but loses router-specific parameters, server-injected tools, and any intermediate-state UX.
- Per-router VS Code extensions — high maintenance burden and fragments the experience.

Thanks for considering!

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.