Describe the bug
Custom models whose provider-side model ID contains a slash (e.g. deepseek/deepseek-v4.1-flash, z-ai/glm-5.3) appear in the /model picker but cannot be selected, trying to choose one leaves the previous model active. The picker also shows "-" for Context and Reasoning on these entries even though the /models API response includes capabilities.limits.
The CAPI /models response serves the ID with the slash URL-encoded:
"id": "myorg/OpenRouter/deepseek%2Fdeepseek-v4.1-flash",
"custom_model": {"key_name":"OpenRouter","owner_name":"myorg","owner_type":"enterprise","provider":"openaicompatible"},
"supported_endpoints": ["/responses"],
"capabilities": {"limits": {"max_context_window_tokens":1048576,"max_output_tokens":384000,"max_prompt_tokens":664576}, "supports": {"streaming":true,"tool_calls":true}}
Passing the decoded form fails:
copilot --model "myorg/OpenRouter/deepseek/deepseek-v4.1-flash"
✗ Model "myorg/OpenRouter/deepseek/deepseek-v4.1-flash" from --model flag is not available. Using "claude-sonnet-5" instead.
Passing the encoded form works and the model runs fine:
copilot --model "myorg/OpenRouter/deepseek%2Fdeepseek-v4.1-flash"
So the model itself is usable; only the picker's selection/lookup path is broken. It looks like the picker decodes the ID (or constructs one from the display name/path) and then fails to match it against the encoded ID in the catalogue.
Note on the ID format: we do not control this ID. The Github enterprise UI only takes the provider's model name (deepseek/deepseek-v4.1-flash); the myorg/OpenRouter/…%2F… composite ID is generated GitHub-side. OpenRouter model names all contain a /, so every OpenRouter-backed custom model is affected. The fix has to be in the CLI's ID handling (or in how the ID is generated), not in configuration.
Affected version
Copilot CLI v1.0.87 (Linux)
Steps to reproduce the behavior
- In Github enterprise settings, add an OpenAI-compatible API key (OpenRouter base URL) and add model
deepseek/deepseek-v4.1-flash, enable it and grant org access.
copilot logout && copilot login, run /model.
- Observe the model listed with no values for for Context/Reasoning; try to select it and nothing happens.
copilot --model "<enterprise>/<key>/deepseek%2Fdeepseek-v4.1-flash" works.
Expected behavior
Custom models are selectable from /model, show their configured context/reasoning, and --model accepts the ID in the same form the picker displays.
Additional context
Workaround: launch copilot with the URL-encoded ID via --model or set it with /config model.
Describe the bug
Custom models whose provider-side model ID contains a slash (e.g.
deepseek/deepseek-v4.1-flash,z-ai/glm-5.3) appear in the/modelpicker but cannot be selected, trying to choose one leaves the previous model active. The picker also shows "-" for Context and Reasoning on these entries even though the/modelsAPI response includes capabilities.limits.The CAPI
/modelsresponse serves the ID with the slash URL-encoded:Passing the decoded form fails:
Passing the encoded form works and the model runs fine:
So the model itself is usable; only the picker's selection/lookup path is broken. It looks like the picker decodes the ID (or constructs one from the display name/path) and then fails to match it against the encoded ID in the catalogue.
Note on the ID format: we do not control this ID. The Github enterprise UI only takes the provider's model name (deepseek/deepseek-v4.1-flash); the myorg/OpenRouter/…%2F… composite ID is generated GitHub-side. OpenRouter model names all contain a /, so every OpenRouter-backed custom model is affected. The fix has to be in the CLI's ID handling (or in how the ID is generated), not in configuration.
Affected version
Copilot CLI v1.0.87 (Linux)
Steps to reproduce the behavior
deepseek/deepseek-v4.1-flash, enable it and grant org access.copilot logout && copilot login, run/model.copilot --model "<enterprise>/<key>/deepseek%2Fdeepseek-v4.1-flash"works.Expected behavior
Custom models are selectable from /model, show their configured context/reasoning, and --model accepts the ID in the same form the picker displays.
Additional context
Workaround: launch copilot with the URL-encoded ID via --model or set it with /config model.