Feature: Add configuration parameter to new_task tool

[xynova]

Feature Request: Add configuration parameter to new_task tool

Problem Description

Currently, the new_task tool only accepts mode and message parameters, which means all sub-tasks inherit the same API configuration (model, provider, settings) as the parent task. This creates several limitations:

1. No Model Flexibility: Users cannot specify different models for different types of sub-tasks (e.g., use a fast model for simple tasks, expensive model for complex ones)
2. No Configuration Control: Users cannot leverage existing API configuration profiles for specific sub-tasks
3. Inefficient Resource Usage: Users must manually switch configurations or create separate tasks to use different models
4. Workflow Interruption: Users have to pause their workflow to change global settings for different task types

Expected Behavior

Users should be able to specify an API configuration profile when creating new tasks, allowing them to:

• Use different models for different sub-tasks without changing global settings
• Leverage existing named configuration profiles (e.g., "fast-model", "accurate-model", "debug-model")
• Maintain workflow continuity by specifying configurations inline
• Optimize costs by using appropriate models for different task types

Proposed Solution

Add an optional config parameter to the new_task tool that accepts the name/slug of an existing API configuration profile.

Updated Tool Description

## new_task
Description: This will let you create a new task instance in the chosen mode using your provided message and optionally specify an API configuration profile to use.

Parameters:
- mode: (required) The slug of the mode to start the new task in (e.g., "code", "debug", "architect").
- message: (required) The initial user message or instructions for this new task.
- config: (optional) The slug/name of the API configuration profile to use for this task (e.g., "claude-3-5-sonnet", "gpt-4-debug", "fast-model"). If not specified, uses the default configuration for the mode.

Usage:
<new_task>
<mode>your-mode-slug-here</mode>
<message>Your initial instructions here</message>
<config>optional-config-slug-here</config>
</new_task>

Implementation Details

1. Parameter Validation: Verify the specified configuration profile exists
2. Configuration Loading: Use the existing ProviderSettingsManager.getProfile() method
3. Task Initialization: Apply the configuration to the new task before mode switching
4. Error Handling: Gracefully fall back to default configuration if specified profile doesn't exist
5. User Feedback: Provide clear success/error messages indicating which configuration was applied

Example Use Cases

1. Cost Optimization:

   <new_task>
   <mode>code</mode>
   <message>Write unit tests for the authentication module</message>
   <config>fast-model</config>
   </new_task>
   

2. Quality vs Speed Trade-off:

   <new_task>
   <mode>architect</mode>
   <message>Design the database schema for the new feature</message>
   <config>accurate-model</config>
   </new_task>
   

3. Debugging with Different Models:

   <new_task>
   <mode>debug</mode>
   <message>Analyze the performance bottleneck in the API</message>
   <config>debug-model</config>
   </new_task>
   

Technical Implementation

Files to Modify

1. src/core/prompts/tools/new-task.ts: Update tool description
2. src/core/tools/newTaskTool.ts: Add config parameter handling
3. src/core/webview/ClineProvider.ts: Leverage existing configuration management

Implementation Approach

// In newTaskTool.ts
const config: string | undefined = block.params.config

// If a specific config was requested, load and apply it
if (config) {
    try {
        const providerSettingsManager = provider.providerSettingsManager
        const configProfile = await providerSettingsManager.getProfile({ name: config })
        
        // Apply the configuration to the new task
        newCline.api = buildApiHandler(configProfile)
    } catch (error) {
        // Log error but continue with default config
        console.warn(`Failed to load config ${config} for new task:`, error)
    }
}

Benefits

1. Enhanced Flexibility: Users can optimize model selection per task
2. Cost Control: Use appropriate models for different task types
3. Workflow Efficiency: No need to interrupt workflow to change global settings
4. Leverages Existing Infrastructure: Uses the established configuration management system
5. Backward Compatibility: Optional parameter doesn't break existing usage

Related Issues

• Issue Configuration profile selection switching between VS Code workspaces #5512: Configuration profile selection switching between VS Code workspaces
  • This issue addresses workspace-level configuration management
  • Our feature would complement it by adding task-level configuration specification

Acceptance Criteria

• new_task tool accepts optional config parameter
• Parameter validation ensures specified configuration exists
• New tasks use specified configuration when provided
• Graceful fallback to default configuration on errors
• Clear user feedback about which configuration was applied
• Backward compatibility maintained for existing usage
• Documentation updated with new parameter
• Tests added for new functionality

Implementation Priority

This feature would be particularly valuable for users who:

• Work with multiple models for different task types
• Need to optimize costs by using appropriate models
• Want to maintain workflow continuity without manual configuration switching

The implementation leverages existing infrastructure and follows established patterns, making it a low-risk, high-value enhancement.

[daniel-lxs]

Hey @xynova, Thank you for creating this proposal. Currently, you can create different custom modes (like junior dev, senior dev, etc.) and assign different profiles to them so that they can be used with the new_task tool. Unfortunately, we currently don't have plans to implement something like this.

Feel free to continue the discussion!

[xynova]

Hey @xynova, Thank you for creating this proposal. Currently, you can create different custom modes (like junior dev, senior dev, etc.) and assign different profiles to them so that they can be used with the new_task tool. Unfortunately, we currently don't have plans to implement something like this.

Feel free to continue the discussion!

not a problem, would there maybe be a way of having modes that are not directly useable but part of other modes? So im coming from the idea where id like to present a clean mode interface to the user but for example in the case of an Auditor mode, some tasks are needle in the haystack type and could use a pattern matcher fast llm, but other tasks are contrarian thinking and planning and that could use a slower one. Not sure if that makes sense