claude-code - 💡(How to fix) Fix [FEATURE] Expose model configuration for subagents in dynamic workflows

Preflight Checklist

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

Problem Statement

With the launch of dynamic workflows in Opus 4.8 (/effort ultracode), the orchestration engine forces all spawned subagents to inherit the orchestrator's premium model (claude-opus-4-8). There is currently no mechanism to route mechanical or low-complexity subtasks (e.g., bulk linting, file extraction, routine search) to faster, cheaper models like Sonnet or Haiku.

The dynamic workflows capabilities should allow users to configure downstream workflow tasks to be delegated to other models.

Because this script is generated and executed on the fly, developers cannot intervene to configure the individual subagents. The runtime forces every spawned worker to inherit the orchestrator's premium model (claude-opus-4-8). For high-volume parallel workloads, this hardcoded inheritance creates a massive token burn rate, triggers rapid rate-limiting, and makes codebase-wide workflows financially unviable.

Proposed Solution

We need a way to control the model tier of auto-spawned subagents without having to manually edit the generated JavaScript workflow scripts.

The runtime should expose a configuration layer that dictates the model used by background subagents spawned during a workflow. Ideally, this would be handled via:

1. A CLI Flag: e.g., claude --workflow-subagent-model claude-haiku
2. Environment Variable / Settings: e.g., CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL or a key in settings.json.

When the workflow runtime executes the auto-generated orchestration script, it should honor this setting—keeping the core orchestrator on Opus 4.8 for planning, while forcing the parallel fan-out workers onto the specified cheaper/faster model.

Alternative Solutions

Current workarounds are non-viable for scale:

• Manually saving the workflow to .claude/workflows/, opening the auto-generated JS script, hardcoding the model parameters, and re-running it. This completely defeats the purpose of "dynamic" autonomous workflows and creates massive friction for standard tasks.
• Forcing the orchestrator to run tasks sequentially or heavily limiting context scope to avoid massive API cost acceleration.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Scenario: Codebase-wide Standard Audit (100+ files)

1. A developer initiates a dynamic workflow: claude --workflow-subagent-model claude-haiku-4-5 "Audit this repository for standard compliance"
2. The primary orchestrator (claude-opus-4-8) handles high-level planning and generates the background script.
3. The script autonomously spawns 100 parallel subagents to do the file extraction and basic linting. Because the CLI flag was passed, the runtime restricts these workers to claude-haiku.
4. The low-cost Haiku subagents return structured findings to the Opus orchestrator, which compiles the final audit report, saving millions of premium tokens.

Additional Context

• Enabling heterogeneous routing directly resolves the "ultra-token-consumption" bottleneck currently reported by the community on large codebases since the Opus 4.8 launch.
• It brings Claude Code into alignment with standard enterprise multi-agent design patterns (Orchestrator-Worker), where expensive reasoning models must be able to delegate to cheap, fast worker models.