Problem
The `create_scheduled_task` and `update_scheduled_task` MCP tools have no `model` parameter. When a scheduled task fires, it uses whatever model the Claude Code application currently has selected globally — there is no way to pin a task to a specific model (e.g. Haiku for a lightweight nightly check, Sonnet for a more complex weekly scan).
As a workaround, users add a `model:` field to SKILL.md frontmatter — but this field is silently ignored at runtime. The task always runs on the global model, leading to expensive Opus burns on tasks that only needed Haiku.
Expected behaviour
`create_scheduled_task` and `update_scheduled_task` should accept an optional `model` parameter (e.g. `"claude-haiku-4-5-20251001"`, `"claude-sonnet-4-6"`) that is persisted and used when the task fires, regardless of the global model setting.
Impact
- All scheduled tasks currently run on whatever model the user last selected in the UI
- If a user switches to Opus for interactive work and forgets to switch back, all overnight scheduled tasks burn Opus tokens
- Users trying to be cost-conscious by specifying `model: haiku` in SKILL.md get no benefit — the field is ignored
- No API-level workaround exists today
Proposed API change
create_scheduled_task(taskId, prompt, description, cronExpression?, fireAt?, model?)
update_scheduled_task(taskId, model?)
The `model` value should accept the same strings accepted by `--model` flag / `settings.json "model"` field (aliases like `"haiku"` or full IDs like `"claude-haiku-4-5-20251001"`).
Problem
The `create_scheduled_task` and `update_scheduled_task` MCP tools have no `model` parameter. When a scheduled task fires, it uses whatever model the Claude Code application currently has selected globally — there is no way to pin a task to a specific model (e.g. Haiku for a lightweight nightly check, Sonnet for a more complex weekly scan).
As a workaround, users add a `model:` field to SKILL.md frontmatter — but this field is silently ignored at runtime. The task always runs on the global model, leading to expensive Opus burns on tasks that only needed Haiku.
Expected behaviour
`create_scheduled_task` and `update_scheduled_task` should accept an optional `model` parameter (e.g. `"claude-haiku-4-5-20251001"`, `"claude-sonnet-4-6"`) that is persisted and used when the task fires, regardless of the global model setting.
Impact
Proposed API change
The `model` value should accept the same strings accepted by `--model` flag / `settings.json "model"` field (aliases like `"haiku"` or full IDs like `"claude-haiku-4-5-20251001"`).