Feature Request: Provider-agnostic VS Code Chat framework for enterprise and ecosystem integrations

[ThePlenkov]

Summary

I’d like to propose evolving VS Code Chat into a provider-agnostic framework so the chat UI can be used by multiple extensions/providers (including enterprise and self-hosted models), while GitHub Copilot remains a first-class provider.

Motivation

VS Code is widely valued as an open, extensible development platform. As chat and agentic workflows become central to IDE usage, a neutral chat surface could help consolidate the ecosystem and improve enterprise adoption.

Today, the Chat experience is strongly associated with Copilot account/service enablement. In practice, this can make it difficult for organizations that cannot approve Copilot (for compliance, residency, or procurement reasons) to still use the native VS Code Chat UX with their approved internal models.

Proposal

Introduce a provider-agnostic chat architecture with an extension API that allows multiple providers to plug into the same core chat surface.

Suggested capabilities

1. Core/neutral Chat UI surface in VS Code (or neutral service layer).
2. Open provider registration API for extensions to implement chat backends.
3. Independent provider auth/routing/billing, owned by each provider integration.
4. Policy controls so enterprises can disable Copilot while keeping chat enabled for approved providers.
5. Consistent UX contract (conversation state, tool/agent hooks, streaming, attachments, etc.) across providers.

Why this helps

Enterprises

• Enables internal/self-hosted model adoption with native VS Code UX.
• Better alignment with compliance and data governance requirements.
• Reduces blockers to rolling out AI features in VS Code.

Developers and ecosystem

• Keeps VS Code flexible and extensible.
• Encourages innovation from the broader extension ecosystem.
• Avoids fragmented chat experiences across many disconnected extensions.

Microsoft/GitHub

• Strengthens VS Code’s position as the neutral AI-native development platform.
• Expands enterprise adoption even in mixed-provider environments.
• Lets Copilot compete on quality, reliability, and advanced capabilities rather than exclusive UI coupling.

Strategic perspective

If agentic chat becomes a central IDE interaction model, making the chat surface broadly integrable could increase long-term platform gravity for the VS Code ecosystem and community.

---

If helpful, I can also draft a concrete API sketch (provider registration lifecycle, capability negotiation, and security model) in a follow-up.

[ThePlenkov]

Just wanted to share my own experience also

• i followed BYOK approach and added own API key via excellent LiteLLM extension
• this is own API and is not served by CoPilot, but CoPilot still counts requests as it's served on CoPilot
• singing out from CoPilot blocks access to the chat control..

You need to set up GitHub Copilot and be signed in to use Chat