[Feature] Persist ultracode/max effort as a persistent default for new sessions (currently session-only, silently resets to xhigh)
What I'm requesting
A supported, persistent way to make new sessions start at ultracode (or max) effort by default - one that survives app restarts and model switches.
Today effortLevel in settings.json only accepts up to xhigh. max and ultracode are session-only, so there is currently no way to make "always start at full capability" stick. Users who rely on Ultracode must re-apply it manually in every new session.
Current behavior (tested on the desktop app, Windows 11 ARM64, app 0.14.5)
settings.jsonwitheffortLevel: "xhigh"persists correctly across restarts. Good.max/ultracodecannot be written tosettings.json(documented as session-only).- The desktop app stores the UI effort state in
claude_desktop_config.json->preferences.epitaxyPrefs.ccd-effort-level. - I manually set
ccd-effort-levelto"ultracode", then force-killed the app (Stop-Process -Force, so no graceful shutdown ran) and relaunched it. - On restart, the value had been reset to
"xhigh". - Because it was reset even though the app was force-killed, the app appears to normalize
ccd-effort-levelto the settingseffortLevel(xhigh) at startup, discarding anyultracode/maxvalue.
Net effect
Every app restart or model switch silently drops the session back to xhigh, and the previously selected Ultracode is lost. The user must re-run /effort ultracode in each new session - and because the reset is silent, they often do not notice they have lost the dynamic-Workflow capability.
Proposed
Provide a persisted default for the top effort tiers, e.g.:
- accept
"effortLevel": "max"insettings.json, and/or - a dedicated
"ultracode": truesetting,
honored on every new session, surviving restarts and model switches.
Why it matters
Manually re-applying the effort each session is easy to forget, and the silent reset means users lose capability without realizing it. A persistent default would make "start every session at full capability" reliable.
Related
Similar pain points, but those are general "effort resets" bug reports - this request is specifically about persisting the top tiers (max/ultracode) as a default:
- #11531
- #12873
- #11522
3 Comments
Confirming this is still relevant on Claude Code v2.1.197 (VS Code extension, macOS / darwin arm64) — so it's not Windows-specific.
Repro: with
"effortLevel": "max"in~/.claude/settings.json(no project/local override), a brand-new session starts athigh, notmax.Root cause (from the shipped bundle): the extension's own
claude-code-settings.schema.jsonenumerateseffortLevelaslow | medium | high | xhighonly, while the webview effort map islow:1, medium:2, high:3, xhigh:4, max:5with level 5 labeled "Max". Somaxis a real, selectable tier that simply can't be persisted — writing"max"to settings is discarded and reset tohighat startup (watched the file get rewrittenmax → high). Note it resets tohigh, notxhigh.Request: let
effortLevel: "max"(or an equivalent persistent key) survive restarts so new sessions can default to Max. Same underlying gap as #65651.+1, same experience on Windows 11.
effortLevel: xhighpersists reliably for me, but ultracode never survives into a new session — and because the drop back to xhigh is silent, it's easy not to notice the dynamic-workflow capability is gone until several turns in. A persisted top tier — accepting"effortLevel": "ultracode"or a dedicatedultracode: truein settings.json — would fix it.Thanks for the detailed writeup. Part of this is possible today:
maxcan be made persistent by setting theCLAUDE_CODE_EFFORT_LEVELenvironment variable tomax(for example in theenvblock of yoursettings.json), which takes precedence over theeffortLevelsetting. Docs: https://code.claude.com/docs/en/model-config#adjust-effort-levelUltracode is currently session-only on purpose (
/effort ultracodeorclaude --effort ultracodeon the CLI), so a persistent default for it — and the desktop app resetting it on restart — is still an open request. Leaving this open for that part.🤖 Generated with Claude Code