Feature request: opt-in model discovery for BYOK / custom providers

[aosama]

Is your feature request related to a problem? Please describe.

When using GitHub Copilot CLI in BYOK ("custom provider") mode, the user is required to set COPILOT_MODEL (or pass --model) to a provider-specific model identifier before launching a session. The CLI does not appear to query the provider for available models, so users must know the exact model string ahead of time and manage it in a separate step (shell aliases, wrapper scripts, provider documentation, etc.). This is particularly inconvenient for OpenAI-compatible endpoints whose /models endpoint already exposes the supported model IDs.

For comparison, when running on the default GitHub Copilot path, the CLI lists models from GitHub and lets the user select one interactively. BYOK users currently do not get equivalent convenience.

Describe the solution you'd like

When COPILOT_PROVIDER_BASE_URL is set and points to an OpenAI-compatible provider (COPILOT_PROVIDER_TYPE=openai or unset), the CLI should optionally call GET <base_url>/models and use the returned data[].id values to populate the /model picker and --model completions. For other provider types (azure, anthropic) this could be supported later where a standard listing API exists.

To keep the behavior safe and backward-compatible, model discovery should be opt-in via an environment variable or command-line flag, e.g.:

COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1 \
COPILOT_PROVIDER_DISCOVER_MODELS=1 \
  copilot

or

COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1 \
  copilot --discover-models

When discovery is enabled:

1. On startup the CLI calls GET /models at the configured provider.
2. If the call succeeds, the returned model IDs populate the /model interactive picker and --model completions.
3. If the call fails (network error, 403, unsupported provider type, etc.), the CLI falls back to the current behavior: require COPILOT_MODEL and display the existing warning about unknown models.
4. Token limits are still resolved as documented: manual env vars take precedence, then the built-in catalog, then safe defaults.

Describe alternatives you've considered

• Wrapper scripts / shell aliases: This is what many BYOK users do today. It works but duplicates provider-specific knowledge outside the CLI and does not integrate with the /model picker.
• Manual COPILOT_MODEL only: Current behavior; works but is unfriendly for endpoints whose model list changes frequently (e.g., local Ollama, Azure AI Foundry, vLLM).
• Always discover automatically: Could break users whose providers reject unauthenticated /models calls or return huge lists. Making it opt-in keeps BYOK mode predictable.

Additional context

• Version tested: GitHub Copilot CLI 1.0.62
• Provider path tested: OpenAI-compatible (COPILOT_PROVIDER_TYPE=openai, COPILOT_PROVIDER_WIRE_API=completions)
• copilot help providers documents COPILOT_PROVIDER_MODEL_ID / COPILOT_PROVIDER_WIRE_MODEL for matching a well-known model identity to a provider-specific wire name. Model discovery would be a natural complement: the discovered ID can serve as the wire model, while the existing catalog/override mechanism continues to handle token limits and agent behavior.
• The OpenAI /models response shape is already widely supported by OpenAI-compatible servers (Ollama, vLLM, Azure AI Foundry /openai/v1/ deployments, LiteLLM, etc.), so the implementation cost for the openai provider type should be low.

Example workflow this would enable

# Ollama local server already exposes /v1/models
export COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1
export COPILOT_PROVIDER_TYPE=openai
export COPILOT_PROVIDER_DISCOVER_MODELS=1

# User launches copilot and types /model to pick from locally pulled models
copilot

# Non-interactive: choose the provider's first available model automatically
COPILOT_PROVIDER_BASE_URL=https://api.example.com/v1 \
COPILOT_PROVIDER_API_KEY=sk-... \
COPILOT_PROVIDER_DISCOVER_MODELS=1 \
  copilot -p "Refactor this file" --model auto --allow-all-tools

# Azure AI Foundry OpenAI-compatible endpoint also exposes /models
export COPILOT_PROVIDER_BASE_URL=https://my-resource.openai.azure.com/openai/v1/
export COPILOT_PROVIDER_API_KEY=...
export COPILOT_PROVIDER_DISCOVER_MODELS=1
export COPILOT_PROVIDER_WIRE_API=responses

copilot

Thank you for considering this!