Feature Request: Enhanced Model Selection for Sub-Agent Architecture

First, thank you for the recent /model option update that allows using Opus 4.1 for plan mode. This is a great step forward in optimizing model usage!

Current Situation

The new feature allows Opus 4.1 for planning and Sonnet 4 for other tasks, which is excellent for balancing performance and usage.

Feature Request

I'd like to propose extending model selection capabilities for the Sub-Agent architecture:

1. Orchestration Agent Model Selection

• Allow Opus 4.1 to handle not just planning but also Sub-Agent orchestration
• The orchestration layer is crucial for maintaining task coherence and autonomous decision-making over extended periods

2. Granular Sub-Agent Model Assignment

• Enable model selection for specific Sub-Agent roles (e.g., requirements definition, architecture design, implementation, testing)
• For example: Assign Opus 4.1 for critical tasks like system requirements definition while using Sonnet 4 for implementation tasks

3. Flexible Configuration Options

Proposed configuration example:
- Main orchestrator: Opus 4.1
- Requirements Agent: Opus 4.1  
- Design Agent: Sonnet 4
- Implementation Agent: Sonnet 4
- Testing Agent: Sonnet 4

Expected Benefits

• Enhanced autonomy: Better orchestration leads to more coherent long-running tasks
• Optimized resource usage: Allocate premium models only where most needed
• Improved accuracy: Critical decision points handled by the most capable model
• Greater flexibility: Users can customize based on their specific use cases

Use Case Example

In complex software engineering projects, having Opus 4.1 manage orchestration and requirements would ensure architectural consistency, while Sonnet 4 handles implementation efficiently.

Points for Discussion

1. Configuration Priority Hierarchy

Proposed priority order for model selection:

Individual Sub-Agent settings > Sub-Agent defaults > Global defaults

This would allow maximum flexibility while maintaining sensible defaults. Would this hierarchy meet most use cases?

2. Dynamic Heuristics for Model Escalation

Consider implementing automatic model upgrades based on runtime conditions:

• Retry threshold: Switch to Opus 4.1 after N failed attempts
• Task duration: Escalate to Opus 4.1 for tasks exceeding time thresholds
• Uncertainty metrics: Upgrade when confidence scores fall below certain levels
• Complexity indicators: Auto-detect complex architectural decisions requiring Opus 4.1

Example scenario:

if (retryCount > 3 || taskDuration > 30min || uncertaintyScore > 0.7) {
    temporarilyEscalateToOpus();
}

3. Recommended Configuration Recipes

Documentation could include battle-tested patterns:

Recipe A: "Opus Conductor Pattern"

• Orchestrator: Opus 4.1
• All Sub-Agents: Sonnet 4
• Best for: Long-running, complex projects

Recipe B: "Critical Path Pattern"

• Orchestrator: Opus 4.1
• Requirements & Architecture Agents: Opus 4.1
• Implementation & Testing Agents: Sonnet 4
• Best for: Mission-critical systems

Recipe C: "Adaptive Pattern"

• Start with Sonnet 4 for all
• Dynamic escalation based on heuristics
• Best for: Cost-conscious experimentation

4. Open Questions

• Should model selection be modifiable mid-task?
• How to handle model availability/quota limitations gracefully?
• Should there be a cost estimation preview for different configurations?

Would love to hear thoughts from the team and community on this enhancement!