Feature Request: Per-agent model selection for sub-agents

Summary

Add the ability to specify which model a sub-agent runs on, independent of the session's default model. This would unlock cost-tiered multi-agent workflows where cheap tasks run on cheap models and complex tasks run on capable models.

Problem

Kimi Code CLI's sub-agent system inherits the session's default_model for every dispatch. The agent YAML schema (version: 1) supports name, system_prompt_path, tools, exclude_tools, extend, and subagents — but no model field. The Agent dispatch tool has no model parameter.

This means every sub-agent invocation runs on the session's model regardless of task complexity. For users on metered plans or managed subscriptions with weekly quotas, this is a significant cost leak — mechanical implementation tasks (isolated functions, clear specs, 1-2 files) burn the same model as architecture and design work.

Use case

The Superpowers plugin (258k stars, available in Kimi Code's plugin marketplace) implements a subagent-driven-development workflow with explicit model tiering:

• Mechanical implementation → fast, cheap model
• Integration/judgment → standard model
• Architecture and final review → most capable model

Its skill instructions say: "Always specify the model explicitly when dispatching a subagent. An omitted model inherits your session's model — often the most capable and most expensive — which silently defeats this section."

On Kimi Code, this guidance is a no-op. The agent reads the instruction, attempts to select a cheaper model, and finds no mechanism to do so. All sub-agents silently fall back to the session model.

This pattern works on other harnesses:

• Claude Code: model parameter on the Task dispatch tool + per-agent model in sub-agent definitions
• OpenCode: model: field in agent definition files (used by oh-my-opencode orchestrator agents)

Proposed solution

Two complementary additions:

1. model field in agent YAML definitions

version: 1
agent:
  name: cheap-coder
  model: "kimi-for-coding"   # overrides default_model for this agent
  system_prompt_path: ./system.md
  tools:
    - "kimi_cli.tools.shell:Shell"
    - "kimi_cli.tools.file:WriteFile"

When omitted, falls back to default_model (current behavior — fully backward compatible).

2. model parameter on the Agent dispatch tool

Allows the main agent to specify a model at dispatch time without pre-defining a custom agent:

Agent(
  task: "Implement the function per spec in task-3.md",
  model: "kimi-for-coding"
)

When omitted, uses the agent definition's model, or default_model if neither is set.

Benefits

• Enables cost-tiered multi-agent workflows (Superpowers, custom orchestration)
• Reduces unnecessary token spend on metered plans
• Backward compatible — no breaking changes to existing configs
• Aligns Kimi Code with the model-selection patterns already proven in Claude Code and OpenCode

References

• Kimi Code agents docs: https://www.kimi.com/code/docs/en/kimi-code-cli/customization/agents.html
• Kimi Code config docs: https://moonshotai.github.io/kimi-cli/en/configuration/config-files.html
• Superpowers subagent-driven-development skill: https://github.com/obra/superpowers/blob/main/skills/subagent-driven-development/SKILL.md
• Superpowers issue on model selection gap (Claude Code/OpenCode): https://github.com/obra/superpowers/issues/1631

Start with the agent YAML schema and the Agent dispatch tool, then trace how default_model is resolved for sub-agent invocations. Define the precedence between a dispatch-time model, an agent definition's model, and default_model; done means both proposed additions work while existing configurations retain their current behavior.