claude-code - 💡(How to fix) Fix [FEATURE] scheduled-tasks MCP: add model parameter to create_scheduled_task / update_scheduled_task

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

Today scheduled tasks inherit the creator session's model — captured at task-creation time. There's no way to (a) select a cheaper model for trivial tasks (refresh-state, apply-mode-change), or (b) pick up newer models without recreating all tasks from a new session. The Agent/Task tool already exposes a model enum (per #47488), so this is a natural extension to the sibling MCP.

Without this feature the scheduled task inherits the model that created it thus cannot upgrade its model to a more capable model nor carry out a simple task with an inexpensive mode.

Proposed Solution

The Agent/Task tool already exposes a model enum (per #47488), so this is a natural extension to the sibling MCP. Expose a parameter for the scheduled task that has a model band like a toml file that allows the most capable model or a specific model.

Alternative Solutions

No response

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

I run various scheduled tasks via mcp__scheduled-tasks__create_scheduled_task for a ops engine. The tasks were created from a Cowork session running Claude Opus 4.7, so all tasks captured that model at creation time and there is no way to change it short of deleting and recreating each task from a new session. This blocks two concrete needs:

1. Mixed-workload model selection. Three of the tasks (apply-mode-change, refresh-state, apply-queue-action) are thin wrappers — each spawns one Python subprocess and reports a one-line summary. The LLM does effectively no reasoning. Running these on Opus 4.7 is meaningful overkill (~$0.03/run on Opus vs. ~$0.002 on Haiku). Five other tasks (Year's Sourcing Plan, Quarterly Rebalance, etc.) genuinely benefit from Opus's deeper reasoning on tax-bracket walks, IRMAA tier checks, lot-level cost-basis logic, etc. I want to mix: Opus for the heavy reasoners, Haiku for the script wrappers, Sonnet for the medium ones.
2. Model upgrade path. When a new Sonnet or Opus ships, my scheduled tasks will not pick it up. The model is captured at task-creation time, and update_scheduled_task doesn't expose a model field, so the only path is to delete + recreate each task from a new session running the new model. With a model parameter on update_scheduled_task, I could roll the fleet over in seconds without touching the cron schedules or prompt files (which live in versioned .md files separate from the scheduled-task config). Suggested shape. The Agent/Task tool already exposes a model enum (opus | sonnet | haiku). A parallel addition to create_scheduled_task and update_scheduled_task with the same enum (plus an unset/inherit default that preserves current behavior) would be a natural extension. If unspecified, fall back to current behavior (inherit from creator session).

Additional Context

No response