[BUG] Skill `effort:` frontmatter alongside `model:` silently drops the model override

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Version: 2.1.220
Platform: macOS (Apple Silicon)
Plan: Max
Session model: sonnet (settings.json "model": "sonnet")

Summary

A user-invoked skill with only model: opus in frontmatter correctly runs the turn on Opus. Adding any effort: line to the same frontmatter causes the model override to be silently dropped: the completion runs on the session model instead. No warning is shown. Verified with effort: high and effort: medium, in interactive sessions.

The transcript shows the declaration was parsed and resolved correctly, and then not applied:

• the command_permissions attachment for the invocation records "model": "claude-opus-5"
• every subsequent assistant message in the turn records "message": {"model": "claude-sonnet-5", ...}

What Should Happen?

Expected

Per the skills documentation, model: applies for the rest of the current turn, and effort: overrides the session effort level. If a given effort level is unsupported for the resolved model, adjusting the effort is documented; voiding the model override is not. At minimum, dropping a declared model override should produce a visible warning.

Actual

The turn runs on the session model. Nothing in the UI indicates the declared model was not applied; the status line payload continues to report the session model and session effort. The only evidence is in the transcript (declaration vs message.model mismatch).

Impact

Any skill that sets both model: and effort: - a natural pairing for "expensive skill on the big model, cheap skill on the small one" setups - silently runs on the session model. Because there is no warning and cost dashboards do not break down by declared model, this can go unnoticed indefinitely.

Notes

• The command_permissions attachment proves alias resolution succeeded (opus -> claude-opus-5) before the drop, so this is downstream of frontmatter parsing.
• Not tested: whether the same pairing on context: fork skills or on agent frontmatter (Task tool path) is affected.

Error Messages/Logs

Steps to Reproduce

Reproduction

mkdir -p /tmp/skilltest/.claude/skills/modeltest

# Case A: model only - WORKS
printf -- '---\ndescription: model override test\nmodel: opus\ndisable-model-invocation: true\n---\nSay ok and stop.\n' > /tmp/skilltest/.claude/skills/modeltest/SKILL.md
cd /tmp/skilltest && claude
# type /modeltest, wait for the answer, exit, then:
t="$(ls -t ~/.claude/projects/*skilltest*/*.jsonl | head -1)"
jq -r 'select(.type=="assistant") | .message.model' "$t" | tail -1
# -> claude-opus-5

# Case B: model + effort - FAILS
printf -- '---\ndescription: model override test\nmodel: opus\neffort: high\ndisable-model-invocation: true\n---\nSay ok and stop.\n' > /tmp/skilltest/.claude/skills/modeltest/SKILL.md
cd /tmp/skilltest && claude
# type /modeltest, wait for the answer, exit, then:
jq -r 'select(.type=="assistant") | .message.model' "$(ls -t ~/.claude/projects/*skilltest*/*.jsonl | head -1)" | tail -1
# -> claude-sonnet-5

# Case C: model + effort: medium - FAILS the same way
# (rules out "high unsupported on the target model" as the trigger)

Case A also passes in print mode (claude -p "/modeltest"). Cases B/C were verified interactively; print mode not tested for the failing combination.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.220

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_