Describe the feature or problem you'd like to solve
Per-mode default model configuration (plan mode vs. autopilot)
Proposed solution
Allow users to configure a default AI model per interaction mode — specifically plan mode and autopilot mode — via the CLI config or a config file (e.g., ~/.copilot/config.json). Today, /model sets a single model for the entire session regardless of mode. Since plan mode is more reasoning-heavy (architecture, task decomposition) and autopilot is more execution-heavy (many sequential tool calls), users benefit from using different models optimized for each purpose — e.g., a premium reasoning model for planning and a faster/cheaper model for autopilot execution.
Example prompts or workflows
- User sets planModel: "claude-opus-4.7" and autopilotModel: "claude-haiku-4.5" in config. On launch, each mode automatically uses the configured model.
- User enters plan mode ([[PLAN]] prefix or Shift+Tab) — the CLI silently switches to the plan model.
- User switches to autopilot (Shift+Tab) — the CLI silently switches to the autopilot model.
- /model still works as an override for the current session
Additional context
This mirrors how some IDEs let you configure different models for different tasks (e.g., chat vs. inline completion). It would reduce the friction of manually switching models when changing modes, and help users manage their premium request quota more intentionally.
Describe the feature or problem you'd like to solve
Per-mode default model configuration (plan mode vs. autopilot)
Proposed solution
Allow users to configure a default AI model per interaction mode — specifically plan mode and autopilot mode — via the CLI config or a config file (e.g., ~/.copilot/config.json). Today, /model sets a single model for the entire session regardless of mode. Since plan mode is more reasoning-heavy (architecture, task decomposition) and autopilot is more execution-heavy (many sequential tool calls), users benefit from using different models optimized for each purpose — e.g., a premium reasoning model for planning and a faster/cheaper model for autopilot execution.
Example prompts or workflows
Additional context
This mirrors how some IDEs let you configure different models for different tasks (e.g., chat vs. inline completion). It would reduce the friction of manually switching models when changing modes, and help users manage their premium request quota more intentionally.