Feature request: fast-mode dispatch for Agent() subagents (model=opus-fast or fastMode flag)

Feature request: model=opus-fast (or equivalent) for Agent() subagent dispatch

Summary

/fast mode toggles the main session to Opus 4.6 with faster output (no model downgrade). There is no equivalent for subagent dispatch via the Agent tool — model accepts sonnet | opus | haiku, with no way to request the Opus-4.6/fast-output variant for a spawned subagent.

In the orchestrator/worker pattern that Claude Code increasingly encourages — a thin coordinator dispatching specialized subagents in parallel for heterogeneous workloads — most of the substantive compute happens in the subagents. Without fast-mode dispatch, the parent can be on /fast while every dispatched worker reverts to default Opus 4.7 latency. Fast-mode latency wins land where the work isn't.

Use case

Common pattern: a session-level orchestrator partitions a job into heterogeneous subtasks and fans them out to subagents differentiated by role and capability. Subtasks that need frontier-tier reasoning (multi-step analysis, structured synthesis, expert-domain judgment) are routed to Opus subagents; mechanical work (search, formatting, extraction, summarization) is routed to Sonnet. These dispatches are typically backgrounded — wall-clock latency for the longest Opus worker dominates time-to-result.

The natural API shape would let the orchestrator pick the fast variant per dispatch — exactly as /fast does for the main session — without sacrificing model class.

Proposed shape

Either:

• model accepts opus-fast as an additional symbolic value (or opus-4-6 if exposing the model ID directly is preferred), OR
• Agent({ fastMode: true, ... }) parameter that pairs with model: "opus" to select the fast variant.

Should compose cleanly with run_in_background: true (where these dispatches typically live) and isolation: "worktree".

Why this matters now

Subagent fan-out is the dominant scaling axis for Claude Code usage as fleets and agent teams expand. Fast-mode benefit on the parent applies to roughly 1/N of the actual reasoning compute when N specialized subagents are in flight — exactly inverse to what a power user wants. Closing this gap is a single API surface change with broad benefit across orchestration-style usage.

Workarounds considered

• Routing reasoning through Sonnet: real quality regression on tasks that genuinely require Opus class.
• Pre-decomposing Opus-class work into a Sonnet pass + an Opus pass: partial mitigation; the Opus pass still pays full latency.
• Running the reasoning in main context: defeats the orchestration architecture, blocks the parent, and burns parent context window.
• Pinning a model ID literal: model enum validation rejects model-ID strings; no documented escape hatch.

Affects

Agent tool dispatch, the run_in_background workflow (subagent latency dominates background turnaround), and any orchestration framework built on the Claude Agent SDK.