Custom endpoint language models display id instead of name in model picker

[albayrakonur]

Does this issue occur when all extensions are disabled?: Yes

customendpoint language models display id instead of name, causing duplicate-looking models in picker and Manage Language Models

I tested the BYOK language model changes introduced in VS Code v1.122, especially around local/custom models.

I configured my chatLanguageModels.json according to the documentation here:

https://code.visualstudio.com/docs/copilot/customization/language-models#_add-a-custom-endpoint-model

For models configured with:

"vendor": "customendpoint"

the displayed model name appears to be taken from the model id instead of the name field.

This also occurs other vendors.

As a result, I cannot add the same underlying model twice with the same id but different name values and different configuration parameters, because both entries are shown with the same visible name. This causes the models to look duplicated/colliding in both the model picker and the Chat: Manage Language Models UI.

Repro Steps

1. Open VS Code v1.122.0.
2. Configure chatLanguageModels.json with a customendpoint vendor.
3. Add two models with the same id but different name values.
4. Open the model picker or run Chat: Manage Language Models.
5. Observe the displayed model names.

Example configuration:

[
  {
    "name": "example",
    "vendor": "customendpoint",
    "apiKey": "${input:chat.lm.secret.example}",
    "apiType": "chat-completions",
    "models": [
      {
        "id": "Qwen3.6-27B",
        "name": "Qwen3.6-27B",
        "url": "https://example.com/v1",
        "toolCalling": true,
        "vision": true,
        "maxInputTokens": 229376,
        "maxOutputTokens": 32768,
        "thinking": false,
        "streaming": true,
        "zeroDataRetentionEnabled": false,
        "reasoningEffortFormat": "chat-completions"
      },
      {
        "id": "Qwen3.6-27B",
        "name": "Qwen3.6-27B-thinking",
        "url": "https://example.com/v1",
        "toolCalling": true,
        "vision": true,
        "maxInputTokens": 180224,
        "maxOutputTokens": 81920,
        "thinking": true,
        "streaming": true,
        "zeroDataRetentionEnabled": false,
        "reasoningEffortFormat": "chat-completions"
      }
    ]
  }
]

Actual Behavior

Both customendpoint models are displayed using the id value:

Qwen3.6-27B
Qwen3.6-27B

This happens in:

• Model picker
• Chat: Manage Language Models

Because of this, two entries with the same id and different name values are indistinguishable in the UI.

Expected Behavior

The visible model name should use the name field, as it does for other vendors.

For the example above, the UI should show:

Qwen3.6-27B
Qwen3.6-27B-thinking

This would allow users to register the same underlying model more than once with different parameters, such as different context size, output token limits, thinking mode, or other endpoint-specific options.

Additional Notes

This seems all vendor behave same like vendor: "customendpoint". Other vendor configurations don't appear to respect the name field for the visible model name.

VS Code Version

Version: 1.122.0 (system setup)
Commit: 6a49527b96e326fe62fbdb56f60e16877c9aa724
Date: 2026-05-27T14:03:01-07:00
Electron: 39.8.8
ElectronBuildId: 13870025
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.22631

[vritant24]

Thanks for reaching out with this issue. I think the problem here would be that the fact that the IDs are the same are the same and we aren't handling it well. We today don't have a way to share ids with models in the same group.

A good workaround may be to change it to the following, you should see both models then

[
  {
    "name": "example",
    "vendor": "customendpoint",
    "apiKey": "${input:chat.lm.secret.example}",
    "apiType": "chat-completions",
    "models": [
      {
        "id": "Qwen3.6-27B",
        "name": "Qwen3.6-27B",
        "url": "https://example.com/v1",
        "toolCalling": true,
        "vision": true,
        "maxInputTokens": 229376,
        "maxOutputTokens": 32768,
        "thinking": false,
        "streaming": true,
        "zeroDataRetentionEnabled": false,
        "reasoningEffortFormat": "chat-completions"
      },
    ]
  },
 {
    "name": "example thinking",
    "vendor": "customendpoint",
    "apiKey": "${input:chat.lm.secret.example}",
    "apiType": "chat-completions",
    "models": [
     {
        "id": "Qwen3.6-27B",
        "name": "Qwen3.6-27B-thinking",
        "url": "https://example.com/v1",
        "toolCalling": true,
        "vision": true,
        "maxInputTokens": 180224,
        "maxOutputTokens": 81920,
        "thinking": true,
        "streaming": true,
        "zeroDataRetentionEnabled": false,
        "reasoningEffortFormat": "chat-completions"
      }
    ]
  }
]

[albayrakonur]

Thanks, I tried the suggested workaround.

Splitting the two entries into separate top-level customendpoint provider definitions does make both models appear in the chat model picker, and both entries are selectable and work for chat.

However, I noticed another issue with this setup. VS Code logs the following warning:

[ProductionEndpointProvider] chat.utilityModel override 'customendpoint/Qwen3.6-27B' matched 2 models; ignoring (override is ambiguous).

So while the picker can display both models after splitting them into separate provider definitions, the internal override resolution still appears to identify them by vendor/modelId, not by the top-level provider name or the model name.

In this case both entries still resolve to:

customendpoint/Qwen3.6-27B

which makes settings such as chat.utilityModel ambiguous.

This means the workaround only solves the picker/display part, but duplicate model ids across customendpoint definitions can still collide for model overrides.

For my use case, I want to expose the same underlying model with different parameters, such as different maxInputTokens, maxOutputTokens, or thinking settings. The picker workaround works, but there does not seem to be a stable way to uniquely reference each variant in settings/overrides.

Would the intended solution be to require unique id values for each configured variant, even when they point to the same underlying model endpoint? Or should the model identity include the top-level provider name so that separate customendpoint entries are not ambiguous?

2026-05-29 00:37:38.646 [warning] [ProductionEndpointProvider] chat.utilityModel override 'customendpoint/Qwen3.6-27B' matched 2 models; ignoring (override is ambiguous).
2026-05-29 00:37:52.750 [warning] [ProductionEndpointProvider] chat.utilitySmallModel override 'customendpoint/Qwen3.6-27B' matched 2 models; ignoring (override is ambiguous).

[vritant24]

Yes this is a known issue we are looking into, thanks for providing another use case for us to consider.