[FEATURE] Expose `model` and reasoning `effort` as settable properties on create_scheduled_task / update_scheduled_task

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

Claude can create and update routines (scheduled tasks) end to end — except the two settings that most determine whether a routine actually works and what it costs: model and reasoning effort. Those live only in the routine's Edit form in the UI.

The tool surface exposed to Claude covers what runs and when, but not how it runs:

• create_scheduled_task accepts: taskId, prompt, description, cronExpression / fireAt, title, notifyOnCompletion
• update_scheduled_task adds only enabled
• Neither has a model or an effort parameter

There is no backing field to write into either: the persisted task at ~/.claude/scheduled-tasks/<taskId>/SKILL.md carries only name: and description: frontmatter.

Two things follow:

1. The setup flow is broken in half. I ask Claude to build a routine, it authors the whole thing, and then I have to finish the job by hand in the Edit form — and remember to redo that on every routine I create.
2. There is no workaround from the agent side. Writing "use Opus 5 at high effort" into the prompt is a no-op, because the prompt is executed inside whatever model and effort were already selected. It cannot change its own runtime.

The failure mode is silent. A routine that quietly runs on a weaker model or a lower effort doesn't error — it just underperforms on schedule, unattended, until someone notices the output got worse.

Concretely: I run a daily 10:00 IST routine that drives a browser through ~50 job applications. Long-horizon browser automation needs a strong model at high effort to stay reliable. Claude can author that entire routine, but cannot pin the one property the routine most depends on.

Proposed Solution

Add two optional parameters to both create_scheduled_task and update_scheduled_task:

| Param | Example values |
|---|---|
| model | claude-opus-5, claude-sonnet-5, claude-haiku-4-5-20251001 |
| effort | low, medium, high, xhigh |

Semantics:

• Optional. Omitted → exactly today's behavior. No change for existing routines.
• Persisted in SKILL.md frontmatter (model:, effort:) so a routine is self-describing, diffable, and editable by hand.
• Returned by list_scheduled_tasks, so Claude can report what a routine will run as — and notice when it's wrong.
• Two-way sync with the Edit form: setting it via the tool shows up in the UI, and editing it in the UI is visible to the tool.
• Validated: an unknown model id or effort value returns a clear error rather than silently falling back.

The experience I want:

"Set up a routine that runs every weekday at 9am on Opus 5 at high effort, and …"

…and it is actually configured that way when Claude finishes — instead of Claude having to end with "now open the Edit form and set the model yourself."

Same for updates: "bump my Naukri routine to xhigh effort" should be a one-line change Claude can make, not a UI errand.

Alternative Solutions

• Set it by hand in the routine's Edit form after every create/update — the current workaround. It works, but it splits one request across two interfaces, and it's easy to forget. A missed toggle degrades the routine silently rather than failing loudly.
• Put the model/effort in the prompt text — does not work, and is worth stating explicitly so it isn't mistaken for a workaround: the prompt runs inside the already-selected model. It has no ability to change its own runtime.
• Hand-edit the task's SKILL.md — nothing to edit. The frontmatter has no such field.
• Rely on the model picker / settings.json being inherited — per #93601 this isn't reliable for scheduled tasks today; and even once fixed, it's a single global default rather than a per-routine value, which doesn't cover the case where two routines need different models at the same time.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. I ask Claude: "Create a routine that runs every weekday at 10:00 IST, drives Chrome through ~50 job applications, and logs each one to a CSV. It needs Opus 5 at high effort — it's a long browser session."
2. Claude calls create_scheduled_task with cronExpression: "0 10 * * 1-5", the full self-contained prompt, and model: "claude-opus-5", effort: "high".
3. Claude confirms: "Created. Runs weekdays 10:00 IST on Opus 5, high effort." Done in one place.
4. Two weeks later: "that routine is getting expensive — drop it to Sonnet on medium."
5. Claude calls update_scheduled_task with model: "claude-sonnet-5", effort: "medium". No UI trip.

Today: step 2 silently drops model and effort, step 3 has to become "…now open the Edit form and set the model yourself," and step 5 isn't possible at all — it's a manual edit every time.

Additional Context

Overlap with #93601, stated plainly

#93601 reports scheduled tasks always launching on Opus 5 regardless of the model picker and settings.json, and proposes as one of its two candidate fixes: "expose a model field on create_scheduled_task / update_scheduled_task." That overlaps with the model half of this request, and I'd rather flag it than have it found later.

I'm filing separately because this differs in two ways — and I'm happy for it to be folded into #93601 if maintainers prefer a single thread:

1. Reasoning effort. I could not find this requested anywhere. For long-horizon routines it matters as much as the model choice does.
2. Framing. #93601 is a bug report about inheritance — routines should pick up my global default. This asks for these to be per-routine properties settable by the agent at create/update time, which is a different capability. A global default can only ever hold one value; a cheap daily digest and a 50-step browser automation legitimately want different models and different effort levels at the same time.

Verified against

Desktop app on macOS (Darwin 25.6.0), 2026-09-17. Parameter lists read directly from the live scheduled-tasks MCP tool schemas; frontmatter confirmed by inspecting ~/.claude/scheduled-tasks/<taskId>/SKILL.md, which contains only name: and description:.