[Feature Request] Per-Mode Model Configuration for CLI Custom Modes

[benzntech]

Problem

Currently, the Kilocode CLI uses a single global provider/model configuration for all modes. When switching between custom modes (e.g., from senior-architect to intern), the model remains the same. This limits the effectiveness of the mode hierarchy where:

• Architect/Senior modes benefit from more capable (and expensive) models for complex reasoning
• Junior/Intern modes could use faster, cheaper models for straightforward implementation tasks

Proposed Solution

Add optional preferredProviderId and preferredModelId fields to the ModeConfig schema, allowing per-mode model configuration in custom_modes.yaml:

customModes:
  - slug: senior-architect
    name: Senior Architect
    preferredProviderId: openai-local
    preferredModelId: claude-opus-4
    roleDefinition: ...
    groups:
      - read
      - mcp

  - slug: intern
    name: Intern
    preferredProviderId: openai-local
    preferredModelId: gemini-2.5-flash-lite
    roleDefinition: ...
    groups:
      - read
      - edit
      - command

When switching modes via /mode <slug>, the CLI would automatically switch to the specified provider/model.

Prior Art

Aider implements this pattern with their architect/editor mode configuration:

• editor_model_name - specifies a different model for code editing
• Allows powerful models for planning, faster models for implementation

Reference: https://aider.chat/docs/config/adv-model-settings.html

Implementation Scope

1. packages/types/src/mode.ts - Add preferredProviderId and preferredModelId to modeConfigSchema
2. cli/src/commands/mode.ts - Switch provider/model when mode changes
3. cli/src/config/customModes.ts - Parse new fields from YAML

Benefits

• Cost optimization by using appropriate models per task complexity
• Better alignment between mode capabilities and model capabilities
• Seamless workflow when delegating from orchestrator to specialized modes
• Feature parity with competitor tools (Aider)

Backward Compatibility

Both fields would be optional. Existing configurations without these fields would continue to work with the global provider/model setting.

[SergioNR]

Bump

[suvitdas]

Hello @benzntech , Saw your ask for per-mode model config to keep costs down — that manual per-mode picking is the exact friction I'm building away: a VS Code agent that auto-routes each turn to the right model so you never hand-bind per mode. I'm pulling ~20 people who've actually hit this into a private beta before launch — OK if I DM you the details?