Repository navigation
Allow /model to switch between multiple models, including BYOK/local providers, in one session #3709
Description
Describe the feature or problem you'd like to solve
BYOK mode pins a session to a single model through COPILOT_MODEL, and the /model picker only lists GitHub-hosted models. It does not list the models served by a configured local BYOK provider. As a result, I cannot select a local model from /model, and I cannot switch models without quitting the CLI and re-exporting COPILOT_MODEL. I would like the CLI to know about models from both sources, GitHub-hosted and local, and let me switch between all of them in-session through /model.
Proposed solution
Make the CLI aware of multiple models across sources and selectable at runtime through /model. Today BYOK and offline mode (#1219) pin a session to one model, so there is no way to switch in-session or to mix a fast local model with a remote one in the same conversation. A suggested approach:
- Enumerate BYOK models from the provider's
/v1/modelsendpoint (OpenAI-compatible) and merge them into the/modelpicker alongside GitHub-hosted models, with a source label:/model gpt-5.1 (github) claude-opus-4.8 (github) google/gemma-4-12b (local) qwen3-coder-30b (local) - Allow an explicit list or opt-out for users who do not want auto-enumeration, for example a
modelsarray in~/.github/copilot-cli.jsonorCOPILOT_MODELS="github/gpt-5.1,local/google/gemma-4-12b". - In-session switching through
/model <name>re-points subsequent requests to the chosen model and provider, with no restart and no loss of conversation context. - Coexistence of remote and local: when not in
COPILOT_OFFLINE=true, list both GitHub-hosted and local BYOK models together; in strict offline mode, list only the local provider's models.
Benefit: users get the same model-switching experience they already have with GitHub-hosted models, extended to local endpoints, so they can pick the right model for cost, speed, or privacy per task without restarting or re-exporting environment variables.
Example prompts or workflows
export COPILOT_PROVIDER_BASE_URL="http://127.0.0.1:1234/v1"
export COPILOT_PROVIDER_API_KEY="local"
# not setting COPILOT_OFFLINE so remote and local are both available
export COPILOT_MODELS="github/gpt-5.1,local/google/gemma-4-12b"
copilot/model # lists github models and local models
/model google/gemma-4-12b # switch to a local model, no restart
/model gpt-5.1 # switch back to a remote model mid-session
- Quick refactor on a local model, then switch to a remote model for a complex design discussion in the same session with the same context.
- Keep sensitive code on a local model while still being able to reach for a remote model when needed.
Additional context
Related issues: #1219 (offline mode, which gave us environment-variable BYOK but a single model), #3624 (BYOM registration for local endpoints, which was closed but the picker gap remains), and #3682 (BYOK credential refresh, which is complementary and a different problem).
Activity
juancarlosjr97 commentedon Jun 7, 2026
Another idea was to have something around
COPILOT_PROVIDER_BASE_URL_LOCAL, where local matches thelocal/google/gemma-4-12bfor multiple local tools, but unclear, just giving more ideaseddedre commentedon Jul 10, 2026
+1 for this feature. I am using BYOK and I have several models on my provider and I would like to be able to switch between them, another use case is to have sub agents also be abled to use these other models my provider has available.
karolsawiczjti commentedon Aug 3, 2026
similar issue #3282
+1 it is definately needed
coder-free commentedon Aug 21, 2026
+1 for this feature.
Jianshui commentedon Aug 22, 2026
+1 for this feature.
calexandre commentedon Aug 26, 2026
+1
Starefossen commentedon Sep 2, 2026
This thread asks for a choice of models inside one provider. The subagent case raised above has a second half: one agent in the session on a different endpoint, not only a different model. I have filed that separately as #4703, with measurements, rather than restate it here.
One data point for this thread. On 1.0.83-3 the per-agent model id from
.agent.mdfrontmatter, and thetasktool'smodeloverride, both reach the provider verbatim. A recording server atCOPILOT_PROVIDER_BASE_URLshowed the main agent's requests carrying the session model and the subagent's request carrying its own. The documented fallback is what hides a mistake here. An id the provider cannot honor drops to the session model instead of erroring, so a model id that never arrived looks exactly like one that worked.kvnloo commentedon Sep 27, 2026
I think this becomes much easier to reason about if the router treats a model as a capability-bearing route, not just a model-name string.
For each selectable route, keep something like
(provider, endpoint, model, context_limit, capabilities)and make/modelswitch that whole route atomically. That avoids a local model id accidentally inheriting GitHub provider behavior.Two invariants seem worth testing:
I would also make unknown/incompatible routes fail loudly rather than falling back to the session model. Silent fallback makes routing bugs almost impossible to detect.
danielgerlag commentedon Oct 8, 2026
Adding a concrete use case: I fine-tuned a coding model on my C# style with Unsloth Desktop and want to use its local OpenAI-compatible endpoint alongside GitHub-hosted models.
My workflow is:
All three steps should happen in the same running session, with the conversation and workspace context preserved.
The documented BYOK setup uses
COPILOT_PROVIDER_BASE_URLand related environment variables at launch. Exiting, changing that configuration, and resuming the conversation is too disruptive for frequent switching. Exposing the local model as an MCP tool is also a different workflow: I want to switch the main model, not delegate a call to another tool.The proposed combined
/modelpicker would solve this. It should show GitHub and configured local models with clear provider labels, route each selection to the correct endpoint, and report unsupported models or connection failures rather than silently fall back to another model.This would make locally fine-tuned models useful within an existing Copilot workflow without requiring users to choose between local inference and GitHub models for the entire session.
Jianshui commentedon Oct 16, 2026
Adding a concrete LiteLLM use case to this request:
Please allow GitHub-hosted Copilot models and models served by a LiteLLM (OpenAI-compatible) endpoint to coexist in one Copilot CLI session and in the
/modelpicker. Selecting a model should route subsequent requests to its associated provider (clearly labeled, such as GitHub or LiteLLM) without relaunching the CLI or changing process-wideCOPILOT_PROVIDER_BASE_URL; conversation and tool context should remain intact.Example workflow: plan with a GitHub-hosted model, implement with a LiteLLM-served model, then switch back to a GitHub-hosted model for review.
Ideally, users could configure one or more BYOK provider profiles and select them alongside GitHub models, with credentials kept out of plaintext config (for example, through environment or secret references). This is model/provider selection for subsequent requests, not simultaneous fan-out to multiple models.