Support persistent "max" effort level in settings.json

Status Closed — not planned

Maintainer reply None cached

Activity 5 comments · opened Apr 18, 2026 · closed Apr 19, 2026

Summary

The VSCode extension UI exposes five effort levels (low, medium, high, xhigh, max), but the effortLevel setting in ~/.claude/settings.json accepts only four — "max" is excluded from the schema enum, so it can't be persisted as a default. Users who pick "Max" in the UI get it for the current session only; every new tab starts at xhigh.

Repro

Set "effortLevel": "max" in ~/.claude/settings.json.
Open a new Claude tab in VSCode on Opus 4.7.
Observe: tab opens at "Extra high" (xhigh), not "Max". The setting is silently ignored.

Evidence (extension v2.1.114)

claude-code-settings.schema.json — effortLevel enum: ["low","medium","high","xhigh"]
webview/index.js FN0 label map: {low:"Low", medium:"Medium", high:"High", xhigh:"Extra high", max:"Max"} — UI has "max"
No CLAUDE_CODE_EFFORT_LEVEL env var exists to override

Requested change

Either:

(a) add "max" to the effortLevel enum in the schema and CLI validation, or
(b) introduce a defaultEffortLevel setting that accepts all five UI values.

Use case

Max-plan subscriber on Opus 4.7 wants every new tab to start at Max without per-tab manual selection.

View original on GitHub ↗

5 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

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

0xbrainkid · 5 months ago

"max" being missing from the effortLevel enum in settings.json schema while being present in the VS Code extension UI is an inconsistency between the UI and the persistence layer — the UI exposes an option the user can select, but that selection silently resets to xhigh on every new tab because max cannot be stored.

This is the same category of silent config discard as:

#49076: /model persisting effortLevel as a side effect
#49166: /effort not being session-scoped
#50364: /model default resolving to wrong model
#50557 (this report): max not in schema, silently ignored

In all cases, the user's declared configuration is not honored, and they discover this only by observing incorrect behavior.

The fix is a one-line schema change: Add "max" to the effortLevel enum in claude-code-settings.schema.json:

"effortLevel": {
  "type": "string",
  "enum": ["low", "medium", "high", "xhigh", "max"]
}

And ensure the CLI validation also accepts "max" as a valid value (currently it validates against the schema enum).

The broader issue: The UI's effort level label map includes max but the schema does not — this suggests max was added to the UI in one PR and the schema update was missed. A CI test that validates UI-exposed values against the settings schema would prevent this class of discrepancy.

alibi85 · 5 months ago

Workaround:

{
  "env": {
    "CLAUDE_CODE_EFFORT_LEVEL": "max"
  }
}

The env-var route bypasses the schema enum that rejects max on the typed effortLevel field, and it persists across sessions.

Credit @relanderolli — original comment.

Ashkaan · 5 months ago

Closing as duplicate of #35904 — the workaround posted by @alibi85 works. Verified in claude-cli v2.1.114: the binary exposes process.env.CLAUDE_CODE_EFFORT_LEVEL via an internal jMH() reader that accepts "max" and overrides the session effort level (the settings.effortLevel path uses a separate ssH validator scoped to low|medium|high|xhigh, which is why the inconsistency exists).

Thanks @0xbrainkid and @alibi85.