[FEATURE] scheduled-tasks MCP: expose model + effort on create/update_scheduled_task, and make them readable

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

First, genuine thanks — scheduled tasks are the feature that turned Claude Code from something I use into something that works while I sleep. Thirty of them run my week. This request comes from leaning on them hard.

The gap: a scheduled task runs on whatever the app's current default model is, and the session that creates and maintains those tasks can neither set that nor read it. The scheduled-tasks MCP tools (create_scheduled_task, update_scheduled_task, list_scheduled_tasks) expose taskId, prompt, description, cron/fireAt, enabled and notifyOnCompletion — nothing about model or effort. Task SKILL.md frontmatter accepts only name and description. The per-task dropdown in the desktop Edit form is a human-only lever.

Concrete, from a 30-task fleet (macOS, desktop 1.24012.9, claude-code 2.1.219, individual Max account). None of the 30 has an explicit per-task model. Reading what they actually ran — message.model plus the sibling top-level effort key in ~/.claude/projects/**/<session>.jsonl — every task ran claude-opus-4-8 @ high through 2026-07-24, then claude-opus-5 @ high from 2026-07-25. The whole fleet re-tiered in lockstep on a default change, unannounced. Some of those tasks are trivial pollers that belong on Haiku; some are reasoning-heavy audits that belong at the top tier and xhigh effort. Neither can be expressed.

This was asked once before, as #62337, and was auto-closed by the duplicate bot on the day it was filed (state "completed", 0 reactions, now locked) against two bug reports about the UI dropdown being ignored — a related but different problem. Re-filing with the effort dimension and the read-back added.

Proposed Solution

1. Add optional model and effort to create_scheduled_task and update_scheduled_task, using the same enums the Agent/Task tool already accepts. Omitted = exactly today's behavior, so nothing existing changes.
2. Return them from list_scheduled_tasks, so a session can audit a whole fleet without doing transcript forensics.
3. Honor model: / effort: in a task's SKILL.md frontmatter (currently stripped), so a task's tier lives beside its prompt and is version-controllable.
4. Ideally, an explicit "default" sentinel that is distinct from unset — so "follow the app default" becomes a choice a user made, rather than the absence of one.

Alternative Solutions

• settings.json model / effortLevel — global, so it re-tiers every interactive session too. Wrong granularity.
• The per-task dropdown in the desktop Edit form — works (per the 2026-07-08 report in #68924), but it is manual, does not scale to 30 tasks, and cannot be audited or bulk-corrected by the agent that manages them.
• Delegating inside the prompt — have the task immediately hand its work to a subagent with a model override. This is my current workaround and it does work, but it pays for a top-tier orchestrator turn just to perform the handoff, and it cannot lower the effort of the task session itself.
• Parsing ~/.claude/projects/**/*.jsonl after the fact — good enough for observability, since model and effort are both recorded there, but it is forensics rather than configuration: it can only tell you what already ran, at whatever tier it already cost.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

1. gmail-triage-3day — classify ~40 emails against a fixed rubric, three times a week. Wants Haiku at low effort. Currently runs on the top tier.
2. rebuild-audit-weekly — a subtractive audit across a large document tree where a wrong call is expensive to undo. Wants the strongest model at xhigh. Also runs at whatever the default happens to be that week.
3. Fleet audit: "Claude, list any scheduled task that isn't on my chosen model and effort, and fix them." Impossible today at both ends — cannot read, cannot set.

Additional Context

Related issues: #62337 (this ask, bot-closed same-day, locked, 0 votes) · #36496 (per-task dropdown ignored — the older bug) · #68924 (individual-account default model) · #43326 (auto-select model/effort by complexity) · #43083 (configurable effort for subagents — the sibling surface where this was already requested).

The asymmetry that makes this read as an oversight rather than a decision: the Agent/Task tool already accepts both model and effort per call. Scheduled tasks are the one agent-spawning surface that does not — and they are the surface where it matters most, because nobody is watching when they fire.

Environment: macOS (Darwin 25.5.0), Claude desktop app 1.24012.9, claude-code 2.1.219, individual Max account, 30 active scheduled tasks.