[FEATURE] Support ``effortLevel`` in *command/agent* frontmatter alongside model field

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

The model: field in command and agent frontmatter works great! It's deterministic and reliable (#7795). We use it daily to switch between `Opus, Sonnet, and Haiku` per command.

But there's currently no way to also set the effort level. Model and effort are orthogonal. So, we should be able to control them independently.

Here's why this matters:

• Cost: Opus at high is cheaper than max — for code review, high is enough
• Quality matching: Sonnet at low for lookups saves tokens without switching to Haiku (which has tool compatibility issues > #14863)
• Reliability: Unlike /effort which propagates intermittently (#26950), frontmatter would be parsed at invocation time. Reliable by design
• Automation: agents with precise depth profiles enable orchestration like scout@low -> analyst@high -> reviewer@max

[The paradise!!]

Proposed Solution

Support effortLevel: in the same frontmatter YAML:

---
name: deep-analysis
model: opus
effortLevel: max
---

---
name: quick-lookup
model: sonnet
effortLevel: low
---

Since model: already works this way (#7795), effortLevel: is the natural next step — and it'd sidestep the intermittent /effort propagation bug entirely (#33000, #26950).

Alternative Solutions

Currently we use model: switching as a proxy for depth: Opus for deep work, Sonnet for quick lookups, Haiku for structural tasks. It works, but it's a blunt instrument. So, we're basically using a model-switch as a proxy for "think harder" ...

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

We built a 3-tier depth control system for a [real-world-domain-driven] specific scientific analysis platform:

| Command/Agent | Model | Desired effort | Use case |
|---------------|-------|----------------|----------|
| /deep | opus | max | Architecture, math algorithms, planning |
| /quick | sonnet | low | Factual questions, config changes |
| /review | opus | high | Code review (deep but not maximum) |
| /scout | haiku | (N/A) | Structural file discovery |
| Default | sonnet | high | Normal implementation work |

Right now we can only switch the model. There's no way to tell `Opus** to think at "high" vs "max", or **Sonnet` at "low" vs "high" per command. Turns out model and effort are genuinely orthogonal dimensions ...

Additional Context

Related issues (we've run into all of these):

• #7795 (model: in frontmatter — already shipped in v1.0.57, direct precedent for this request)
• #11272 (per-command thinking_mode — close ancestor, but boolean on/off, not graduated scale, and commands-only)
• #13159 (thinking: in frontmatter — closed as dup of #11272, same boolean limitation)
• #33000 (/effort returns "Unknown skill" — 26 upvotes, frontmatter would bypass this entirely)
• #32732 (agent model field can be overridden by parent)
• #26950 (effort propagation unreliable)
• #31923 (effort persistence in settings.json — global, not per-command)
• #29612 (flexible plan/execute model pairing)

How this differs from #11272/#13159: those request a boolean thinking: true/false. We're proposing a graduated effortLevel: low/medium/high/max scale — which enables cost/performance tradeoffs, not just on/off. And we include agents frontmatter, not just commands.

Environment: Claude Code for VSCode 2.1.70, Windows 10 Pro