Scheduled task ignores model setting, always runs Sonnet

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/21679
2. https://github.com/anthropics/claude-code/issues/18346
3. https://github.com/anthropics/claude-code/issues/31490

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Additional Issue: Scheduled task requires user to view the task screen to progress

The scheduled task does not make progress unless the user navigates to the task's session screen in the Desktop app. The task appears to hang indefinitely when running in the background. Only when the user opens the task screen does execution resume.

This defeats the purpose of scheduled/automated tasks, as they require human attention to complete. The task should run to completion regardless of whether the user is viewing the session.

Steps to Reproduce

1. Create a scheduled task with browser automation (Chrome MCP tools)
2. Run the task via "Run now"
3. Do NOT open the task session screen
4. Observe: task makes no progress for 1+ hours
5. Open the task session screen
6. Observe: task immediately starts progressing

Expected Behavior

Task should execute autonomously without requiring the user to view the session screen.

This is a serious issue for users relying on scheduled tasks in production. We run multiple scheduled tasks daily (lead research, customer outreach emails, compliance audits) — all silently downgraded to Sonnet despite Opus being selected. The quality difference matters for customer-facing communications and nuanced lead qualification. This has been open for 3 weeks with 9+ duplicates and no team response. Is there a timeline for a fix?

This is a significant limitation. I'm on the Max $200 plan and cannot run Opus 4.6 (1M) as a scheduled task.

Use Case

I'm building a complex application with 27 domains (CRM, time tracking, scheduling, invoicing, etc.). All research is done and I've perfected the build harness, following Prithvi Rajasekaran's (Anthropic) guide "Harness design for long-running application development". My harness runs as a Claude Code scheduled task that orchestrates multi-sprint builds with structured file handoffs, ACID checkpoints, and separated Generator/Evaluator sessions.

I ran a controlled experiment — same protocol, same benchmark (136 acceptance tests), same domain — with the only variable being the model:

• Opus 4.6 (1M): 129/136 (94.9%)
• Sonnet 4.6: 106/136 (77.9%)

That's a +23 point lift from model alone. Opus hit 10 perfect categories and scored 82.6% on enterprise-tier tests that every Sonnet variant scored 0% on. The difference is not marginal — it's the difference between a production-ready build and one that needs significant rework.

I now need to build the remaining 26 domains. That's 52 scheduled jobs (26 builds + 26 verification passes). Each build is a 6-sprint continuous session running ~1 hour each. This is exactly the kind of long-running, autonomous work that scheduled tasks were designed for.

Workaround
What I'm doing today:

1. Disable the Scheduled job
2. Trigger the scheduled task manually via "Run now,"
3. Immediately switch the model dropdown to Opus 4.6 (1M),
4. Stop the session, then resume it by entering "Proceed" into the prompt. The dropdown change takes effect on the next turn.

This works for now, but it requires me to be present at the keyboard for every job launch. It won't scale to 52 jobs. The whole point of scheduled tasks is unattended execution.

Perspective

I understand this might be intentional — running Opus at scale on scheduled tasks is expensive and Anthropic may not be ready to open that up yet. If that's the case, I'd appreciate transparency on the roadmap. Even a "not planned" label would help me decide how to plan future work.

Anthropic — any advice on how we can build at scale using Opus 4.6?

Adding a 2026-07-25 status update from a 30-task fleet on macOS — desktop app 1.24012.9, claude-code 2.1.219 — because the symptom has changed while the underlying defect has not.

The "always Sonnet" symptom no longer reproduces here. Across ~6 days and 30 scheduled tasks, not one run used Sonnet. A sample of what they used instead:

| run | task | model | effort |
|---|---|---|---|
| 07-24 03:52 | auto-consolidate-nightly | claude-opus-4-8 | high |
| 07-24 08:57 | literary-curation | claude-opus-4-8 | high |
| 07-25 03:28 | comment-concierge-nightly | claude-opus-5 | high |
| 07-25 03:50 | auto-consolidate-nightly | claude-opus-5 | high |
| 07-25 09:49 | broadcast-collision-audit-weekly | claude-opus-5 | high |

That is the same bug wearing a nicer model. Every task flipped 4.8 → 5 on the same date, in lockstep, with no edit from me — they are following the app's rolling default, not any per-task selection. And they are not inheriting a creator session's choice either: my interactive picker default is Fable 5, and not one of the 30 tasks has ever run Fable.

A verification method for anyone else confirming this, since you cannot read the session footer of a 3am cron: every assistant turn is written to ~/.claude/projects/**/<session>.jsonl with message.model, alongside a sibling top-level effort key (high / xhigh / max / medium). So the model and effort of any past run are recoverable after the fact:

jq -r 'select(.message.model) | "\(.message.model) \(.effort)"' <session>.jsonl | sort -u

Match a run to its task by grepping the transcript for a distinctive line from ~/.claude/scheduled-tasks/<id>/SKILL.md.

The gap that remains, stated for the agent surface rather than the UI: the scheduled-tasks MCP (create_scheduled_task / update_scheduled_task) exposes no model or effort parameter and no read-back, so a session can neither set a task's model nor even ask what model that task will run on. Task SKILL.md frontmatter carries only name and description.

The practical consequence of default-tracking at fleet scale: a vendor-side default change silently re-tiers every automated task at once — capability profile and cost profile both — with no changelog entry and nothing for the user to diff against. Happy to supply fuller per-task run data if it would help.

Adding an independent reproduction, since this is closed as not-planned but still live for us: same day, two separate tasks, both with correct/present frontmatter model pins, both still mismatched.

• A task pinned model: claude-fable-5 in its SKILL.md frontmatter fired on Sonnet 5 during a manual "Run now" launch (2026-07-30). Only caught because the task's own prompt had an in-prompt self-check that declined and logged the mismatch — nothing at the platform level surfaced it.
• A second task pinned model: claude-sonnet-5 (hand-verified present via read-back immediately before firing) fired on Opus 5 (1M context) during a manual "Run now" launch the next day (2026-07-31).

Both mismatches were manual Run-now launches specifically. For contrast: we also have roughly 20 auto-fired cron/scheduled runs on a Sonnet-pinned task since 2026-07-26 with zero observed drift. That split is consistent with the theory already in this thread — a task inherits whatever model is active in the launching UI at fire time, not its own frontmatter — and also consistent with create_scheduled_task/update_scheduled_task exposing no model parameter at all (confirmed against the current tool schemas, matches #57216/#62337).

This is a real reliability problem for anyone using scheduled tasks for tier-sensitive work — we ended up building an internal "watch it fire, stop and relaunch if wrong" workflow as the only verified-reliable mitigation, since a self-check gate can catch a bad run but can't fix it. Happy to share more detail if it helps triage. Just wanted to leave a fresh, dated data point on a closed issue that's clearly still affecting people.