OAI Compatible Provider in VS Code: What Replaced It and How to Configure a Custom Endpoint (2026)

If you are looking for the OAI compatible provider option in VS Code, it no longer exists under that name. According to VS Code's documentation, the OpenAI Compatible provider is deprecated and has been replaced by Custom Endpoint, which supports three API types instead of one. Your endpoint still works — the registration path changed.

What "OAI compatible provider" referred to

The phrase comes from VS Code's Copilot Chat, not from a vendor. It was the entry in the model picker that let you register a third-party endpoint speaking the OpenAI Chat Completions dialect, so Copilot Chat could call a model you supplied rather than only the ones GitHub ships.

It is worth separating two things that share the word "compatible":

• The protocol — the request and response shape an endpoint implements. That is a property of the service you are calling, and it is unchanged by anything VS Code does. If you need the protocol itself explained, what an OpenAI-compatible API is covers the endpoint surface.
• The client-side registration — how one particular editor lets you plug that endpoint in. That is what changed.

Only the second one is affected here. An endpoint that worked before still works; you register it differently.

What replaced it: the Custom Endpoint provider

VS Code's documentation states plainly that the Custom Endpoint provider "replaces the deprecated OpenAI Compatible provider and supports additional API types," and that the github.copilot.chat.customOAIModels setting is deprecated.

The practical upgrade is the API type selection. Custom Endpoint offers three: Chat Completions, Responses, and the Anthropic Messages API. The old provider assumed Chat Completions. That third option matters if your endpoint serves the Anthropic protocol, because it removes the translation layer people used to bolt on.

How to register a custom endpoint

Per the official documentation, the flow is:

1. Open the model picker in Copilot Chat and choose Manage Language Models (the gear icon).
2. Select Add Models, then Custom Endpoint.
3. Enter a group name, a display name, and an API key.
4. Select the API type — Chat Completions, Responses, or Messages.
5. VS Code opens chatLanguageModels.json for you to finish the model entries.

The configuration is a JSON array of provider groups, each holding one or more models:

[
  {
    "name": "My Provider",
    "vendor": "customendpoint",
    "apiKey": "${input:myApiKey}",
    "apiType": "messages",
    "models": [
      {
        "id": "your-model-id",
        "name": "Display Name",
        "url": "https://your-endpoint.example.com/v1/messages",
        "toolCalling": true,
        "vision": true,
        "maxInputTokens": 200000,
        "maxOutputTokens": 64000
      }
    ]
  }
]

Two details in that shape are easy to miss.

The url is the full endpoint, not a base URL. This is the opposite convention from most SDK configuration, where you set a base and the client appends the path. Here you write the complete path you want called. That single difference accounts for a large share of failed setups — the same class of mistake catalogued in what to set for an OpenAI-compatible base URL.

The API key belongs in an input variable. The documentation uses "apiKey": "${input:myApiKey}" rather than a literal string, so the key is prompted for and kept out of a file you might commit. Use that form.

Picking the API type

Match the API type to what your endpoint actually serves, not to what the model is:

A provider may serve more than one of these on different paths, sometimes with different key groups. Selecting the wrong pairing produces an authentication or schema error that reads like a broken key, which sends people down the wrong debugging path entirely.

The declared capability flags — toolCalling, vision — are assertions you are making to VS Code, not capabilities it detects. If you set toolCalling: true against an endpoint whose tool-call implementation is partial, the failure surfaces mid-task rather than at registration. Compatibility badges routinely overstate what is implemented; where OpenAI compatibility actually stops goes through the layers where it breaks.

What a custom endpoint does not cover

Registering your own model does not make the whole editor independent of GitHub. The documentation is specific: semantic search, inline suggestions (code completions), and features relying on embeddings still require a GitHub account.

So a custom endpoint changes which model answers in the chat panel. It does not turn Copilot into a self-contained client, and planning around it as though it does leads to a surprise later.

FAQ

Where did the OpenAI Compatible provider go in VS Code?

It is deprecated. VS Code's documentation says the Custom Endpoint provider replaces it and supports additional API types. The github.copilot.chat.customOAIModels setting is deprecated along with it.

Do I have to change my endpoint when migrating?

No. The deprecation is on the client side. The same endpoint, key, and model identifiers carry over — you re-register them through Add Models, Custom Endpoint, and finish in chatLanguageModels.json.

Should the url field be a base URL or a full path?

A full path. Unlike most SDK configuration, VS Code calls the URL you write. Pointing it at a bare base and expecting a path to be appended is the most common configuration error here.

Can I point VS Code at an Anthropic-protocol endpoint?

Yes. Messages is one of the three supported API types, so an endpoint serving the Anthropic dialect can be registered directly without a translation shim.

Does a custom endpoint replace my GitHub account?

No. Semantic search, inline code completions, and embedding-backed features still require a GitHub account per the documentation. Only chat model selection moves to your endpoint.