**Title:** Support multiple model profiles in settings.json for quick switching via `/model`

[LoveSilverWolf-999]

Problem

Currently, settings.json only accepts a single set of model-related configuration:

{
  "model": "deepseek-v4-pro",
  "thinkingEnabled": true,
  "reasoningEffort": "max",
  "temperature": 0
}

When I need to switch between different models (e.g., deepseek-v4-pro with max reasoning for complex tasks, deepseek-v4-flash without thinking for quick edits), I have to manually adjust each field via /model every time — model name, thinking mode, reasoning effort, and temperature. This is repetitive and error-prone.

Proposed Solution

Support a profiles field in settings.json to predefine multiple named configurations:

{
  "profiles": {
    "pro-max": {
      "model": "deepseek-v4-pro",
      "thinkingEnabled": true,
      "reasoningEffort": "max",
      "temperature": 0
    },
    "flash-quick": {
      "model": "deepseek-v4-flash",
      "thinkingEnabled": false,
      "temperature": 0.7
    },
    "coding-plan": {
      "model": "ark-code-latest",
      "baseUrl": "https://ark.cn-beijing.volces.com/api/coding/v3",
      "thinkingEnabled": true
    }
  },
  "defaultProfile": "pro-max"
}

The /model command would then list these profiles for one-click switching.

Use Cases

1. Heavy reasoning tasks (architecture design, debugging) → switch to pro-max
2. Quick edits / boilerplate → switch to flash-quick for speed and cost savings
3. Third-party models (e.g., Coding Plan) → switch to coding-plan without re-entering BASE_URL and API_KEY each time

Expected Behavior

• profiles entries accept: model, baseUrl, apiKey, thinkingEnabled, reasoningEffort, temperature
• defaultProfile (optional) specifies which profile to use at session start
• /model lists all profiles and allows selecting one to apply immediately
• If profiles is not configured, /model behaves exactly as it does today

---

Thanks for the great tool!

[AnkurKumarShukla]

Proposal

I'd like to work on this feature.

My goal is to add support for named model profiles while keeping the current configuration fully backward compatible.

Design

• Introduce an optional profiles field in settings.json.
• Each profile can override any model-related configuration, including:
  • model
  • baseUrl
  • apiKey
  • thinkingEnabled
  • reasoningEffort
  • temperature
• Add an optional defaultProfile field to select the active profile when the CLI starts.
• If profiles is not configured, the CLI will behave exactly as it does today.

Configuration Merging

To reduce duplication, profiles should act as overrides rather than requiring every field to be repeated.

Example:

{
  "temperature": 0,
  "thinkingEnabled": true,

  "profiles": {
    "flash": {
      "model": "deepseek-v4-flash",
      "thinkingEnabled": false,
      "temperature": 0.7
    }
  },

  "defaultProfile": "flash"
}

The runtime configuration would be resolved by merging the selected profile over the global settings, allowing profiles to specify only the fields they need to override.

/model UX

• Display configured profiles in the /model menu.
• Selecting a profile immediately applies its configuration.
• If no profiles are configured, preserve the existing /model behavior.

Backward Compatibility

• Existing settings.json files continue to work without modification.
• All new fields are optional.
• Users who don't use profiles won't notice any behavioral changes.

Implementation Plan

1. Extend the configuration schema to support profiles and defaultProfile.
2. Update the configuration loader to resolve the active profile by merging it with the global configuration.
3. Modify the /model command to display and switch between configured profiles.
4. Add validation and error handling for invalid or missing profiles.
5. Add tests and update the documentation.

If this approach aligns with the project's direction, I'd be happy to implement it, including tests and documentation.