Scheduled tasks ignore model setting, always run on Sonnet 4.6

[JasonYeYuhe]

Bug Description

Scheduled tasks always run on Sonnet 4.6 regardless of model configuration. The model setting is not respected through any available mechanism.

Steps to Reproduce

1. Set "model": "claude-opus-4-6" in ~/.claude/settings.json
2. Create a scheduled task via create_scheduled_task API
3. In the Desktop app UI, confirm the task's model is set to Opus 4.6 (via Edit form)
4. Also tried adding model: claude-opus-4-6 to the SKILL.md frontmatter
5. Run the task (either via "Run now" or wait for cron trigger)

Expected Behavior

The task should run using Claude Opus 4.6 as configured.

Actual Behavior

The task always runs on Sonnet 4.6 (visible in the bottom-right corner of the task session window showing "Sonnet 4.6 · High"), regardless of:

• Global settings.json model setting
• UI Edit form model picker selection
• model field in SKILL.md frontmatter (which gets stripped on some tasks)

Environment

• Claude Code Desktop App (macOS)
• Model set to claude-opus-4-6 globally
• Multiple scheduled tasks affected

Impact

Users who need Opus-level reasoning for automated tasks (e.g., code auditing, development, multi-step agentic workflows) cannot configure scheduled tasks to use their preferred model. This is especially impactful for unattended automation where the user cannot intervene.

Additional Context

• The create_scheduled_task and update_scheduled_task APIs do not expose a model parameter
• The SKILL.md frontmatter model field is either stripped or ignored
• The documentation states model can be changed "through the Edit form or ask Claude", but neither method persists the change to actual runtime

[0xbrainkid]

Scheduled tasks ignoring the configured model setting and always running on Sonnet 4.6 is an agent configuration identity failure — the task was configured with a specific model as part of its identity (what capabilities, what context length, what cost profile), and that configuration is being silently overridden at execution time.

From a trust perspective, a user who configures a task to use Opus (for complex reasoning tasks) and sees it run on Sonnet instead has no way to know this happened without checking the run logs. The output may look plausible while being lower quality than the configured model would produce — silent capability downgrade.

Two layers to the fix:

1. Honor the model setting at task execution time. The task's model configuration should be read and applied at the moment the execution environment is allocated, not overridden by a default. If the scheduled runtime cannot fulfill the configured model (e.g., model not available in the execution region), it should fail the task with an explicit error: "Task configured for claude-opus-4-6 but that model is unavailable in this environment" — not silently substitute Sonnet.

2. Log the model actually used in the run record. Even if this is working as intended (e.g., scheduled tasks default to a specific model for cost or availability reasons), the run record should clearly show what model was used. If the user's configured model and the execution model differ, the run record should note this discrepancy.

For debugging: check whether the model override is happening server-side (the execution environment ignores the model field entirely) or client-side (the model field is not being included in the task creation payload). The distinction narrows down whether this is a scheduling configuration bug or a task creation bug.

[github-actions]

Found 3 possible duplicate issues:

1. Scheduled task ignores model setting, always runs Sonnet #36496
2. [BUG] Scheduled task model selection reverts to Sonnet on next automated run #44768
3. Scheduled task model selector has no effect — always runs Sonnet #36754

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

[zikziktao]

Reproduction data from another user (today, 2026-04-17):

Configuration verified in Desktop UI:

• Scheduled task: cosas-reconcile (runs every 2h)
• Model selector: Opus 4.7 ✅ (checkmark shown)
• Adaptive thinking: ON ✅
• Footer shows: Opus 4.7 Adaptive

Observed behavior: When the scheduled task fired at 10:04 IST, the session's system prompt reported You are powered by the model named Sonnet 4.6. The exact model ID is claude-sonnet-4-6.

So the model selection is visibly persisted in the UI (Opus 4.7 with checkmark) but the task runtime still spawns with Sonnet 4.6. Confirming this is still present in the current Claude Code build.

Environment: Desktop app, macOS Darwin 24.4.0, local task (not worktree), isaacattia session scope selected.

Ruling out Adaptive thinking as the cause: per Anthropic docs, Adaptive thinking only controls extended-thinking intensity within the selected model — it does not switch between Opus/Sonnet/Haiku. So this is a scheduler → runtime plumbing bug, not a thinking-mode side effect.

Happy to provide the task's SKILL.md or any additional diagnostics if useful.

[fridlyand]

Adding technical detail from reverse-engineering Claude 1.3109.0 / claude-code 2.1.111 on macOS, in case it's useful for validation. Apologies if any of this is already internal knowledge — posting in case the traces save someone time.

Confirmed root cause (not just symptom):

When a scheduled task's stored model field is unset, the app spawns the Claude Code CLI with literal --model default. Visible via ps -ef on a live task:

/.../claude-code/2.1.111/claude.app/Contents/MacOS/claude --output-format stream-json --verbose --input-format stream-json --model default --permission-prompt-tool stdio ...

The fallback comes from model: t.model || "default" in the extracted .vite/build/index.js. The string "default" resolves server-side to Sonnet 4.6 — it does not consult ~/.claude/settings.json, the project .claude/settings.json, or the SKILL.md model: frontmatter.

The storage schema already accepts model:

iDr = dt({id:LA(), cronExpression:LA().optional(), fireAt:Ii().optional(), enabled:Rt(), filePath:LA(), model:LA().optional(), createdAt:Ii(), lastRunAt:LA().optional(), ...})

So the storage layer is fine. Two things prevent it from being populated in practice:

1. No UI model picker per scheduled task that I could locate in this version
2. create_scheduled_task / update_scheduled_task endpoints don't expose a model parameter

Working workaround (verified on 2.1.111):

1. Fully quit Claude (⌘Q)
2. Edit `~/Library/Application Support/Claude/claude-code-sessions///scheduled-tasks.json` and add `"model": "claude-opus-4-7[1m]"` (or any valid model ID) to the task object
3. Reopen Claude — `loadScheduledTasksFromDisk` parses with the schema above, `model` survives, and the field is then held in memory
4. Subsequent "Run Now" and cron fires use the configured model

Why editing the file without a restart doesn't work:
The app keeps tasks in memory and calls `persistToDisk` (`Array.from(this._scheduledTasks.values())`) after every task update — overwriting any external edit that happened while it was running. Only the startup `loadScheduledTasksFromDisk` path reads the file.

Suggested fix direction (humbly — maintainers have better context):
Either (a) fall back to the normal settings.json resolution chain when `task.model` is unset, instead of hardcoding `"default"`, or (b) expose `model` in the create/update endpoints so the UI can populate it end-to-end.