claude-code - 💡(How to fix) Fix Separate effort levels for plan mode vs. execution mode

Problem

The /effort level is a single global value that persists unchanged across plan/execute transitions. Many workflows want maximum reasoning while planning (architecture, trade-offs) but faster, cheaper execution once the plan is approved. Today this requires manually running /effort max before planning and /effort high after — error-prone and easy to forget. There is no hook event for entering/exiting plan mode, so it cannot be automated either.

Existing partial solution

The opusplan model alias varies the model by mode (Opus for plan, Sonnet for execute) but does not control effort independently, and forces a model change you may not want.

Requested feature

A way to set two effort levels that the harness applies automatically based on mode. For example:

• New settings keys: planEffortLevel and executeEffortLevel in settings.json
• Or a /plan-effort <level> command, with /effort continuing to govern non-plan turns
• Falling back to the single effortLevel when the mode-specific key is unset (fully backward compatible)

Why

Plan mode is already a distinct, harness-tracked mode with its own permission semantics; effort is the one reasoning dial that is not mode-aware. Making it mode-aware aligns cost with where deep reasoning actually pays off.