Feature Request: Separate parallelTasksCount for Planning and Execution Modes

Resolved 💬 5 comments Opened Jun 25, 2025 by Atomzwieback Closed Jan 7, 2026

Problem Statement

Based on extensive usage of Claude Code for complex software projects, I've noticed that parallelTasksCount has fundamentally different value propositions during planning versus execution phases:

  • During planning: Multiple perspectives are invaluable for architectural decisions
  • During execution: Single-threaded implementation is optimal for speed and consistency

Currently, this requires manually exiting Claude Code and reconfiguring between phases, which severely disrupts developer workflow.

## Observed Behavior

Through experimentation with different parallelTasksCount values:

### With parallelTasksCount = 3:

  • Planning phase: Excellent! I get three different architectural approaches to consider
  • Execution phase: Problematic - the same edits appear to be attempted multiple times, causing significant slowdown

### With parallelTasksCount = 1:

  • Planning phase: Limited - only one perspective on complex architectural decisions
  • Execution phase: Optimal - fast and efficient implementation

## Real-World Use Cases

### 1. Refactoring Legacy Systems
When refactoring a monolithic authentication system, I need:

  • Planning: Multiple architectural proposals (microservices vs modular vs hybrid)
  • Execution: Single, focused implementation of the chosen approach

Currently, I must interrupt my workflow to reconfigure between these phases.

### 2. Database Migration Strategy
For a complex database migration:

  • Planning: Want to see gradual migration vs big-bang vs blue-green approaches
  • Execution: Need efficient implementation without redundancy

### 3. Performance Optimization
When optimizing a slow application:

  • Planning: Benefit from diverse optimization strategies (caching vs query optimization vs CDN)
  • Execution: Want sequential, non-conflicting implementation

## Proposed Enhancement

Allow mode-specific configuration:

``json
{
"parallelTasksCount": {
"planning": 3, // Multiple perspectives when designing
"execution": 1, // Efficient when implementing
"default": 1 // Backward compatibility
}
}
``

Why This Matters

  1. Workflow Continuity: No need to exit and reconfigure mid-task
  2. Optimal Resource Usage: Multiple agents only when diversity adds value
  3. Better Outcomes: Comprehensive planning without execution penalties
  4. Developer Experience: Maintains flow state during complex tasks

Current Workarounds Are Insufficient

  1. Manual reconfiguration: Breaks concentration and workflow
  2. Keeping it at 1: Misses valuable planning insights
  3. Keeping it at 3: Makes execution unnecessarily slow
  4. Asking for "multiple approaches": Doesn't feel as comprehensive as true parallel planning

Expected Benefits

  • 3-5x faster execution when not running redundant parallel tasks
  • Better architectural decisions from multiple planning perspectives
  • Seamless workflow without configuration interruptions
  • Cost efficiency in token usage

User Story

"As a software architect using Claude Code, I want to receive multiple architectural perspectives during planning mode without sacrificing execution speed, so that I can make informed decisions and implement them efficiently without workflow interruptions."

Conclusion

This enhancement would make Claude Code significantly more powerful for complex software engineering tasks that require both thoughtful planning and efficient execution. The ability to configure different parallelization strategies for different modes would be a game-changer for professional development
workflows.

Would the team consider implementing this mode-aware configuration capability?

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗