Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Per-model effort level configuration (modelEffort block)

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Expose a way to configure effortLevel per model. Today, CLAUDE_CODE_EFFORT_LEVEL / effortLevel are global, which doesn't compose well with the mixed-model precedence rules (e.g. xhigh is Opus-4.7-only; other models silently fall back to high rather than max).

Root Cause

Users who deliberately mix models (e.g. randomised launch between Opus 4.6 and 4.7, or /model switching during a session based on task type) can't currently get the right effort per model without brittle wrappers. The gap is small in code but surprising in behaviour -- "I set xhigh globally and my Sonnet session got worse than max" is easy to miss.

Related: --effort as a per-invocation flag already works well -- this proposal just makes it declarative in settings.

Fix Action

Fix / Workaround

Export CLAUDE_MODEL (or similar) into the session's process env so SessionStart / PreCompact hooks can read it and set CLAUDE_CODE_EFFORT_LEVEL dynamically. Less clean but more general -- hooks could use it for other model-dependent config (different system prompt patches, different tool allowlists, etc.). Doesn't solve mid-session /model switches on its own.

Code Example

{
  \"effortLevel\": \"high\",
  \"modelEffort\": {
    \"claude-opus-4-7\": \"xhigh\",
    \"claude-sonnet-4-6\": \"max\",
    \"claude-haiku-4-5\": \"high\"
  }
}
RAW_BUFFERClick to expand / collapse

Summary

Expose a way to configure effortLevel per model. Today, CLAUDE_CODE_EFFORT_LEVEL / effortLevel are global, which doesn't compose well with the mixed-model precedence rules (e.g. xhigh is Opus-4.7-only; other models silently fall back to high rather than max).

Problem

Given the current single-knob behaviour:

  • Set max globally -> all models run at max, so Opus 4.7 never uses xhigh.
  • Set xhigh globally -> Opus 4.7 gets xhigh as desired, but Sonnet 4.6 / Haiku 4.5 silently fall back to high (not max).

There's no way today to express "xhigh on Opus 4.7, max on Sonnet 4.6, high on Haiku 4.5" without wrapping the CLI in a shell function that inspects --model before launch. That wrapper approach:

  • breaks when switching models mid-session with /model
  • doesn't apply to the desktop/IDE entrypoints
  • can't be shared via settings.json

Proposed solution: modelEffort block in settings.json

{
  \"effortLevel\": \"high\",
  \"modelEffort\": {
    \"claude-opus-4-7\": \"xhigh\",
    \"claude-sonnet-4-6\": \"max\",
    \"claude-haiku-4-5\": \"high\"
  }
}

Resolution order (highest wins):

  1. --effort CLI flag (session override)
  2. modelEffort[<active-model>]
  3. effortLevel / CLAUDE_CODE_EFFORT_LEVEL (global default)
  4. Model default

This should apply at session start and when the active model changes via /model mid-session.

Alternative: expose CLAUDE_MODEL env var

Export CLAUDE_MODEL (or similar) into the session's process env so SessionStart / PreCompact hooks can read it and set CLAUDE_CODE_EFFORT_LEVEL dynamically. Less clean but more general -- hooks could use it for other model-dependent config (different system prompt patches, different tool allowlists, etc.). Doesn't solve mid-session /model switches on its own.

Why this matters

Users who deliberately mix models (e.g. randomised launch between Opus 4.6 and 4.7, or /model switching during a session based on task type) can't currently get the right effort per model without brittle wrappers. The gap is small in code but surprising in behaviour -- "I set xhigh globally and my Sonnet session got worse than max" is easy to miss.

Related: --effort as a per-invocation flag already works well -- this proposal just makes it declarative in settings.

extent analysis

TL;DR

To fix the issue, introduce a modelEffort block in settings.json to configure effortLevel per model, allowing for more fine-grained control over effort levels across different models.

Guidance

  • Introduce a modelEffort object in settings.json with model-specific effort levels, as proposed in the issue.
  • Define the resolution order for effort levels, with the --effort CLI flag taking highest priority, followed by the modelEffort block, then the global effortLevel, and finally the model default.
  • Consider implementing the proposed resolution order to ensure that effort levels are applied correctly at session start and when the active model changes via /model.
  • Evaluate the alternative approach of exposing a CLAUDE_MODEL env var, which could provide more flexibility for model-dependent configuration, but may require additional implementation to handle mid-session model switches.

Example

{
  "effortLevel": "high",
  "modelEffort": {
    "claude-opus-4-7": "xhigh",
    "claude-sonnet-4-6": "max",
    "claude-haiku-4-5": "high"
  }
}

Notes

The proposed solution assumes that the modelEffort block will be applied correctly at session start and when the active model changes. Additional testing may be necessary to ensure that this implementation works as expected. The alternative approach of exposing a CLAUDE_MODEL env var may require further evaluation to determine its feasibility and potential impact on the existing implementation.

Recommendation

Apply the proposed modelEffort block in settings.json, as it provides a more straightforward and declarative way to configure effort levels per model, and aligns with the existing --effort flag functionality.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#container setup#orchestration issue#cache issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING