✨ [Feature Request] Add configuration interface to set sub-agent model in parallel execution scenarios

[bevis-wong]

Overview

When using multiple sub-agents for parallel task execution (e.g., task_create / subagent-driven-development),
there is currently no way to specify which model each sub-agent should use. The main agent can freely choose
its model, but sub-agents default to using the same model as the main agent, with no independent control.

Use Cases

• Main agent uses a high-precision model (e.g., V4) for planning, decision-making, and code review
• Sub-agents use a lighter model (e.g., V4-flash) to execute independent implementation tasks in parallel
  (coding, testing, documentation generation, etc.)
• Cost optimization: low-risk subtasks should use a more cost-effective model
• Throughput optimization: lighter models respond faster, reducing overall completion time

Suggested API Design

    # Option A: Specify model per task
    task_create(
        prompt="Implement driver/adc module...",
        model="V4-flash",       # ← new optional parameter
        mode="agent"
    )
    
    # Option B: Global default model for all sub-agents
    config = {
        "sub_agent_default_model": "V4-flash",
        "sub_agent_fallback_model": "V4"   # fallback when specified model is unavailable
    }
    
    # Option C: Route by task type
    task_config = {
        "task_type": {
            "implementation": {"model": "V4-flash"},
            "code_review":    {"model": "V4"},
            "test_generation": {"model": "V4-flash"}
        }
    }

Requirements

1. Add a model parameter to task_create (or equivalent API) — allow each sub-agent to be assigned an
   independent model
2. Support global default configuration — set the default model for all sub-agents in the config file
3. Model availability detection — provide a clear error message or automatic fallback when the specified model
   is unavailable
4. Backward compatibility — omit model and behavior remains unchanged (inherits the main agent's model)

Priority

P2 — Enhancement. Does not affect existing functionality, but provides significant benefits for large-scale
parallel workflows.

Additional Notes

• This feature is especially valuable for large-scale refactoring, multi-module parallel development, and batch
  test fixing scenarios in DeepSeek-TUI
• Reference implementation: Claude Code's task_create tool already supports a model parameter, which can serve
  as a design reference

[aboimpinto]

Hey @bevis-wong — strong agree on this one.

I just posted my own intro issue (#1770) about building out proper agent/sub-agent infrastructure for DeepSeek TUI, and per-agent model selection is a foundational piece of that puzzle. Being able to route planning/review work to a high-precision model while fanning out implementation tasks to a lighter model is exactly the kind of cost-aware, throughput-optimized workflow that makes parallel agents genuinely useful.

A few thoughts:

• Option A (per-task model parameter) feels like the right starting point — it gives the caller explicit control without adding config complexity. A global default (Option B) could layer on top of that naturally.
• Backward compatibility is well-called-out — omitting model should keep current behaviour, which also makes this safe to land incrementally.
• Model availability detection / fallback is important too, especially for community setups where not everyone runs the same model lineup.

This aligns closely with what I'm hoping to help build. Happy to collaborate on the design or review when this moves forward. Cheers!