[FEATURE] Cowork Dispatch: add `model` parameter to `start_task` so the orchestrator can route child tasks by tier

Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 2, 2026

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

I use Cowork's Dispatch orchestrator to run most of my day-to-day work. Dispatch spawns child task sessions with its start_task tool, and those child sessions do almost all of the real work. start_task currently accepts only prompt, title, directory, attachments, and space_id. There is no way to say which model a child task should run on.

The consequence is that a routing policy cannot bind. Dispatch's own memory carries a tier policy (Haiku for mechanical work, Sonnet as the default worker, Opus for judgment, Fable sparingly) and it already sets model explicitly on every Agent subagent call, where the parameter exists. For start_task it can only write the intended tier into the prompt as prose and hope the child session calibrates. Prose does not route: across 444 local scheduled runs on my machine between 5 Aug and 2 Sep 2026, prompt text asking for "the most capable model" had no measurable effect on the model assigned.

On a Max subscription the cost that matters is the five-hour and seven-day rate-limit windows, not per-token price. Being able to pin a high-frequency child task to Haiku and a weekly judgment task to Opus is how the orchestrator stays inside those windows. Today the tier of every child task is whatever the platform default happens to be, and that default has changed without notice (one task ran Sonnet on every run through 14 Aug, then switched wholesale to Haiku from 15 Aug with no change on my side).

Proposed Solution

Add an optional model parameter to Dispatch's start_task (and start_code_task), accepting the same values the Agent tool already accepts: the aliases haiku, sonnet, opus, fable, or a full model ID. An optional effort parameter alongside it would be ideal, since Anthropic's own guidance is to tune effort before switching models.

When omitted, behave exactly as today. When present, the child task session runs on that model, and the transcript or task card shows which model it ran on so the orchestrator can verify the spawn took.

This mirrors the precedent that already exists elsewhere in the product: the Agent subagent tool has model, and Cowork's server-side scheduled-task modal has an optional "model you want to use" field. start_task is the remaining spawn surface without it.

Alternative Solutions

  • Writing the intended tier into each child prompt as prose ("this is mechanical work, calibrate accordingly"). Measured on my own run history: it does not change the model assigned.
  • Having each child task spawn its own Agent subagent with an explicit model, which works, but the child's parent session still runs at the platform default, so the expensive part is unchanged.
  • Setting CLAUDE_CODE_SUBAGENT_MODEL in ~/.claude/settings.json. This governs Agent subagents in Claude Code sessions and does nothing for Dispatch's task sessions.
  • The same parameter for the local scheduled-tasks MCP (create_scheduled_task / update_scheduled_task) was requested in #57216 and #62337; both are closed. This request is deliberately scoped to the Dispatch start_task surface only, which neither of those covered.

Priority

High - Significant impact on productivity

Feature Category

API and model interactions

Use Case Example

  1. From my phone I tell Dispatch: "Reconcile this week's receipts against the budget sheet and draft the weekly summary."
  2. Dispatch splits it: one child task to extract line items from the receipt PDFs (mechanical, ground-truth checkable), one to reconcile against the sheet (Sonnet-grade), one to write the judgment paragraph about anomalies (Opus-grade).
  3. Today all three children run on whatever the platform default is. If that default is Opus, the extraction task burns Opus budget on a job Haiku does fine. If it is Haiku, the judgment paragraph gets the weakest model.
  4. With model on start_task, Dispatch calls start_task(model: "haiku"), start_task(model: "sonnet"), start_task(model: "opus") respectively, and the run costs what it should.

Additional Context

  • Surface: Claude Desktop on Windows 11, Cowork with Dispatch enabled, Max plan.
  • Dispatch's start_task parameter list was read directly from the live tool schema in an orchestrator session on 2026-09-02.
  • Related but distinct: #54214 (Dispatch child-task completion notifications) and #43960 (Dispatch session visibility). Neither asks for model selection.
  • The 444-run measurement above came from parsing the per-session audit logs under the local-agent-mode-sessions folder. Happy to share the method if useful.
  • Docs reference for the existing subagent mechanism this would mirror: https://code.claude.com/docs/en/sub-agents (model resolution order and CLAUDE_CODE_SUBAGENT_MODEL).

View original on GitHub ↗