new_task tool should take Provider as an optional prameter

[kitaekatt]

The new_task tool takes 'mode' and 'message' as parameter. I am proposing their is an optional third parameter 'provider' that would resolve to a confirgured provider. Ideally this resolution could be fuzzy so, for example, you should specify gemini2.5 and have the closest matching provider be selected, falling back to default when there is no match.

Context:

For the most efficient flow, it is great to enable the orchestrator to spawn subtasks, and for subtasks to return automatically to the orchestrator. This relies on the orchestrator's effective use of the new_task tool.

Often the type of llm to work depends on the subtask. One can achieve this goal by (for example) having a separate code mode for every llm you want to use, and providing context to the orchestrator on which code mode to use given the type of problem. This results in mode bloat.

If the orchestrator could specify the llm to use, this would allow for fewer modes to exist. The default mode can remain, and be the default. This would allow users to communicate with the orchestrator about the best mode for the task using natural language, or through rules, establish a clear process for llm selection.

[WhiteR4bbitt]

I was thinking of this too, but not sure its worded the greatest or passing the provider manually being more complex. Since there are so many too choose from, it would be easier to just choose from your existing dropdown (not passing a param). So the new_task would have to have a signal sent so it knows to wait for user to "Start Subtask"

Simply put: When starting a sub-task, allow the user to choose a Provider/Model before actually running the task as to not have it auto-start with the wrong Model.

Title: Choose Model for Subtask with Orchestrator