Desktop scheduled tasks ignore settings.json model: 'Default' silently tracks last-used interactive model (and its effort)

Status Open

Maintainer reply None cached

Activity 3 comments · opened Oct 7, 2026

Summary

In the Claude desktop app (Code tab), scheduled tasks ("routines") whose model is left on Default ignore the model set in ~/.claude/settings.json and instead silently track the last-used interactive session model — including its effort level. After one interactive Fable 5 session, every routine on the account launches on claude-fable-5 at high effort instead of the configured claude-opus-5-5[1m], roughly doubling (or more) the usage of every scheduled run. This value persists across full app restarts and is stored nowhere on disk that we could find, so there is no user-controllable default for routines.

This behavior began with the desktop app update installed 2026-10-06 ~07:58 CT. Before that update, routine session records carried the exact settings.json string (claude-opus-5-5[1m] — alias suffix included), proving routines then read settings.json. After it, the suffix disappeared and the model began following last use.

Environment

Claude desktop app (Code tab), Windows 11 Pro 10.0.26200
App auto-updated 2026-10-06, re-verified current + restarted 2026-10-07 before final repro
~/.claude/settings.json: "model": "claude-opus-5-5[1m]" (unchanged throughout)
Scheduled tasks created via the scheduled-tasks MCP (no model parameter exists there) and via the app UI

Evidence (from the app's own session records: `%APPDATA%\Claude\claude-code-sessions\...\local_<id>.json`, fields `model` / `effort` / `effortInherited`)

| Created (UTC) | Session | model | effort |
|---|---|---|---|
| Oct 4 12:24 | routine | claude-opus-5-5[1m] | medium |
| Oct 6 12:53 | routine | claude-opus-5-5[1m] | medium |
| Oct 6 13:08 | routine (first run after app update) | claude-opus-5-5 (suffix gone) | medium |
| Oct 6 13:56 | interactive | claude-opus-5-5 | high |
| Oct 7 04:20 | interactive | claude-fable-5 | high |
| Oct 7 12:24 | routine | claude-fable-5 | high |
| Oct 7 19:12 | no-op probe routine (after settings.json re-pinned AND /model claude-opus-5-5 run in a session) | claude-fable-5 | high |
| Oct 7 19:44 | no-op probe routine, model "Default" | claude-fable-5 | high |
| Oct 7 19:45 | same probe with Opus 5.5 picked in the routine's Edit form | claude-opus-5-5 | medium |
| Oct 7 ~20:1x | fresh probe created AFTER app re-update + full restart, model "Default" | claude-fable-5 | high |

All routine records show effortInherited: true.

What we ruled out

Not settings.json: pinned to claude-opus-5-5[1m] the whole time; probes still launched Fable.
Not the most-recently-created session: a Sonnet-pinned session was created minutes before a Default probe; the probe still launched Fable (it tracks the interactive/composer model, not session creation).
Not stale in-memory state: survives a full app quit/restart, twice.
Not stored locally: a byte-level scan of %APPDATA%\Claude (Local Storage leveldb decoded, IndexedDB, session stores, .claude.json, task folders) found no per-task model field and no composer-remembered model key. All 22 task folders contain only SKILL.md. The per-task model picked in the Edit form is apparently server-side.

Expected

Either (a) routines honor the settings.json model/effort cascade like other sessions (pre-Oct-6 behavior), or (b) there is a user-visible, documented default-model control for scheduled tasks. The current behavior — an undocumented "Default" that follows whatever model the user last ran interactively — makes scheduled-run costs unpredictable: one late-night Fable session silently converts every daily/weekly/monthly routine to Fable-at-high until the next interactive session.

Workaround we found (confirming the per-task pin works)

Setting the model explicitly in each routine's Edit form pins that routine durably (claude-opus-5-5, effort inheriting the model's default medium) even while interactive Fable sessions run. But it must be clicked per routine, new routines default to the broken "Default", and the scheduled-tasks MCP exposes no model parameter, so it cannot be automated.

Docs gap

https://code.claude.com/docs/en/desktop-scheduled-tasks does not document how a task's model or effort is resolved when left on Default, and no changelog entry describes the Oct-6 behavior change.

View original on GitHub ↗

3 Comments

uncle-barrito · 8 days ago

Three additional data points from continued testing on the same machine (all probe-verified, same session-record method):

ANTHROPIC_MODEL is ignored for scheduled-task sessions. With "env": {"ANTHROPIC_MODEL": "claude-opus-5-5[1m]", "CLAUDE_CODE_EFFORT_LEVEL": "medium"} in ~/.claude/settings.json, a Default-model task still launched claude-fable-5 — but at medium effort. So CLAUDE_CODE_EFFORT_LEVEL reaches the task session while ANTHROPIC_MODEL does not. The likely mechanism: the task launcher passes the server-side "last used" model as an explicit --model-level override, which outranks the env var. This means the task model is unreachable from every client-side config surface (settings model, env, SKILL.md).

A session cannot repair itself: mcp__ccd_session_mgmt__set_session_model / set_session_effort on "self" are refused ("Refusing to change this session's own model or effort"), so a prompt-level workaround ("switch yourself to Opus first") is also closed.

The scheduled-tasks MCP (create_scheduled_task / update_scheduled_task) exposes no model or effort parameter, and Claude is (correctly) barred from driving the app's own Edit-form UI — so the per-task pin cannot be automated at all; a user with many routines must click each Edit form by hand, and must remember to do so for every new routine, or it silently runs on whatever model they last used.

Feature asks that would resolve this: (a) honor the settings cascade (env/model) when a task's model is "Default", or (b) expose a model/effort field in the scheduled-tasks MCP, or (c) an account/app-level "default model for routines" setting.

imagiclondon · 8 days ago

Same behaviour on macOS, measured from the session transcripts.

Environment

Claude desktop app 2.26454.0 (updated 6 Oct 2026), Claude Code 2.1.286, macOS 27.0.1 (26A434)
Max (20x) plan, 67 enabled Code-tab routines, all with the model picker left on Default
No model key in ~/.claude/settings.json or any project settings file

What happened

Until 7 Oct 13:26 (UTC+8), every routine run used claude-opus-5-5 at effort medium (18 of 18 runs overnight 6 to 7 Oct).
From the 14:11 run on 7 Oct, every routine run used claude-fable-5-1 at effort high (18 of 18 runs overnight 7 to 8 Oct, and every run up to 8 Oct 09:27).
Model and effort changed together, between two consecutive routine runs.
One interactive Code-tab session had been switched to claude-fable-5-1 with /model at 12:44, about 40 minutes BEFORE the last Opus routine run. So the change did not follow the /model command immediately. Something later moved the routines' Default, and I could not identify what.
On 8 Oct at 09:57 the same interactive session was switched back to Opus 5.5 with /model. The next routine run, at 10:27, used claude-opus-5-5 at effort medium again. So routines on Default do follow the interactive choice, but with an unexplained lag the first time (40+ minutes on 7 Oct, under 30 minutes on 8 Oct).

Impact
About 11% of the separate weekly Fable allowance went in roughly 8 hours of unattended routine runs, with no interactive activity. Nothing in the app showed that the routines had changed model.

Expected
A routine on Default should run on a stable, documented default, never on the model last used in an interactive session. Any change to a routine's model or effort should be visible in the Routines list.

Workaround in use
Setting an explicit model in each routine's Edit form, which this issue reports holds.

Related, making the workaround hard

The Edit form offers only explicit models, with no "Default" option, and no effort control.
For some routines the Edit form shows no model picker at all (for example a weekly routine last run on 3 Oct), so those cannot be pinned (compare #91884).
There is no bulk way to set the model (not in the scheduled-task tools, SKILL.md or settings), and the Routines list cannot be sorted or searched, so pinning 67 routines means finding each one by hand.

Observation on the Routines list order (not confirmed, offered in case it helps others)
The list is not in creation order (as #59624 reported for an earlier build). On 8 Oct, 12 of the top 15 entries were in exact order of most recent run, newest first, so the list re-sorts itself as routines run. Exceptions: a routine currently running sat at the top, and two others sat above more recently run ones, apparently because their sessions had been touched after their last run. Because the order moves under you, finding 20 specific routines to re-pin them by hand is slow; a sort option or a search box would help.

runvouch · 5 days ago

Until it's fixed, treat the model as an output of the run, not a setting. Your session records already carry model and effort, so a small check that reads the newest routine record and compares those two fields with the previous routine's record catches the switch on the first run, not after a night of 18. We do the same for our own scheduled jobs: the per-run log stores which model actually answered, and a change between consecutive runs pages, separate from any spend threshold. Spend thresholds were too slow here, since one doubled run still sits under any sane daily cap and the damage only shows as a trend.

Also, imagiclondon's table suggests the live repair is switching an interactive session back with /model, which is fragile to rely on across 67 routines.

RunVouch covers this part for us: https://runvouch.com