Describe the solution you'd like?

Add an optional model_id parameter to start_agent when spawning local sub-agents, so that an orchestrating agent can pin a specific model for each child agent rather than always inheriting the parent session's model.

Proposed behaviour:

• When model_id is omitted: existing behaviour — child inherits parent's preferred LLM.
• When model_id is set (e.g. "claude-sonnet-4-5" or "auto"): child starts with that model, validated against the user's available choices (same logic as oz agent run-cloud --model).

This mirrors the pattern that already exists in StartAgentExecutionMode::Remote { model_id: String, ... } — local mode has the field internally (model_id: Option<String>) but it is not exposed to the calling agent.

Is your feature request related to a problem? Please describe.

When building multi-skill orchestration systems on top of Oz, different skills have very different model requirements:

• Mechanical sub-agents (run tests, lint, create branches) — optimal on a fast/cheap model like Sonnet. Running them on Opus burns credits unnecessarily.
• Cognitive sub-agents (architecture review, TDD cycle, planning) — need the reasoning depth of Opus.

Today, all local start_agent calls inherit the parent session's model. The only influence mechanism is prompt-prefix signals ("This is a mechanical task…") that hint at model routing via Warp's auto-genius system, but these are soft suggestions, not guaranteed routing. There is no way for an orchestrating agent to say "run this particular skill on Sonnet" regardless of what model the user has selected in their session.

This matters in practice because:

1. A user selecting Opus for their main session forces all sub-agents — including cheap mechanical tasks — onto Opus, multiplying credit cost 3–5× for no quality gain.
2. Conversely, a user selecting Sonnet for cost efficiency gets cognitive sub-agents degraded from Opus when Opus reasoning would produce a materially better result.

The desired model for each skill is a capability decision (what reasoning level does this task need?), not a user preference (what model do I want to use today?). These are orthogonal concerns that the current inheritance model conflates.

Additional context

• StartAgentExecutionMode::Local { harness_type: Option<String>, model_id: Option<String> } already has the field internally (app/src/ai/agent/api/convert_from.rs, crates/ai/src/agent/action/mod.rs). The field is set only by the orchestration confirmation card UI, not by the agent's tool call.
• oz agent run-cloud --model <id> and the agent config file's model_id field already validate and apply model overrides for remote runs — the same validation logic (validate_agent_mode_base_model_id) could be reused for local sub-agents.
• warp model list exposes available model IDs to the agent, so an orchestrator can enumerate valid choices.
• Requesting this for local-only initially; remote already works via the server-resolved execution profile.

Operating system (OS): macOS

How important is this feature to you? 4