anthropics / anthropics/claude-code
[BUG][REGRESSION] model:/effort: frontmatter override silently broken for BOTH commands/*.md and skills/SKILL.md (v2.1.220, worked on v2.1.197)
- Dominant language
- Python
- Stars
- 145k
- Forks
- 23.1k
- PR merge metrics
- PR metrics pending
Description
## This is not a duplicate — please don't auto-close it as one
I know this looks similar to several older reports, and I want to head that off explicitly: this is a **fresh, broader regression**, confirmed today on the **current version (v2.1.220)**, and it's more severe than any single prior report because it now affects **both** mechanisms at once (`commands/*.md` **and** `skills/SKILL.md`), for the simplest possible case (direct, user-typed slash invocation — no Agent/Task tool involved). The stale-bot auto-closed every prior related report without a fix (see "Related reports" below) — please don't repeat that here without someone actually looking at it. If maintainers confirm it's truly the same root cause as one of those, I'm happy to have this merged/redirected there instead of closed outright — I'd just like a human to make that call, since the stale-bot closures previously buried this without resolution for months.
## Summary
Setting `model:` and/or `effort:` in the frontmatter of a custom slash command (`~/.claude/commands/.md`) or a skill (`~/.claude/skills//SKILL.md`) no longer switches the model/effort for that invocation. The override is **silently ignored** — no error, no warning — and the turn silently runs on the session's default model/effort instead. This removes a basic, previously-reliable control surface: there is currently no working way to pin a specific model/effort to a specific slash command.
## Severity / impact
This is a sharp *regression*, not a missing feature: the exact same override mechanism worked correctly in the same long-lived session on **v2.1.197** (2026-07-02) and fails on **v2.1.220** (2026-07-26). Anyone who built tooling around per-command model/effort selection (multi-model workflows, cost-tiering cheap/expensive models per task, reasoning-effort tiering) has lost that control with no warning that anything changed.
## Context
Found this while building [`cc-arch-hands`](https://github.com/PHPCraftdream/cc-arch-hands) — an open-source installer that generates per-model/per-effort slash commands and sub-agents for Claude Code (e.g. `/oh`, `/o1h`, `/sx` in the repro below are its generated commands). The whole tool's value proposition depends on this override actually working, which is how the regression surfaced so clearly.
## Repro — `commands/*.md`
`~/.claude/commands/o1h.md`:
```yaml
---
model: claude-opus-4-8
effort: high
---
$ARGUMENTS
```
Invoke `/o1h test` in a session whose default model is `claude-sonnet-5` (no `/model` switch in between). Repeated for a few variants in the same sitting:
| Command | frontmatter `model:` | frontmatter `effort:` | actual model used | actual effort used |
|---|---|---|---|---|
| `/o1h` | `claude-opus-4-8` | `high` | `claude-sonnet-5` | — |
| `/oh` | `claude-opus-5` | `high` | `claude-sonnet-5` | — |
| `/sx` | `claude-sonnet-5` | `xhigh` | `claude-sonnet-5` | `high` |
## Repro — `skills/SKILL.md`
`~/.claude/skills/cah-model-switch-test/SKILL.md`:
```yaml
---
name: cah-model-switch-test
description: diagnostic skill
model: claude-opus-4-8
effort: high
---
Reply with exactly this text and nothing else: "skill override test ok".
```
Invoked directly by the user typing `/cah-model-switch-test` (not via the assistant calling the `Skill` tool programmatically — i.e. the invocation path some other reports say *should* work). Same failure.
## Evidence it's a real execution mismatch, not just a display bug
The session transcript (`~/.claude/projects//.jsonl`) records an `attachment` entry of type `command_permissions` at invocation time, capturing the *requested* override, e.g.:
```json
{"type":"attachment","attachment":{"type":"command_permissions","allowedTools":[],"model":"claude-opus-4-8"},"timestamp":"2026-07-26T07:03:21.540Z","version":"2.1.220"}
```
But every subsequent `assistant` entry in that same turn (`thinking`, `tool_use`, `text`) — starting from the very first one — reports `"message.model":"claude-sonnet-5"`. The API call itself ran on the session default, not the requested override. This isn't the status bar mislabeling something: the field that identifies which model actually produced the tokens says session-default, for the entire turn, both for `commands/*.md` and for `skills/SKILL.md`.
The same holds for `effort:`, tracked separately via the statusLine envelope's `effort.level` field: requested `xhigh`, observed `high` (the session default) for the full turn.
## Before/after (this exact mechanism used to work)
In the same long-lived session, on **v2.1.197** (2026-07-02), the identical `command_permissions` → subsequent-`assistant`-entries pattern correctly switched to `claude-opus-4-8` for an entire multi-tool-call turn — several consecutive `assistant` entries all showed `"model":"claude-opus-4-8"` right after the override attachment. So this isn't "frontmatter override was never reliable" — it demonstrably worked, on this exact machine/session, 24 days ago.
## Related reports (older, narrower, auto-closed by the stale-bot — not fixed)
- #63599 — `effort:` ignored in `commands/*.md` (claimed skills honor it; that's no longer true either, see above)
- #56819 — `model:` frontmatter override inconsistent for slash commands (closed as dup of #45191)
- #45191 — Skill frontmatter `model:` field ignored at runtime
- #79664 / #79661 / #79654 — Skill frontmatter `model:` override ignored specifically when invoked via the `Skill` tool (works when user types `/skill-name`) — this report shows it now fails even for the user-typed path
- #81313 — Skill frontmatter `effort:` applied on slash-command invocation but ignored via the `Skill` tool
None of these were resolved — they were auto-closed for inactivity by the stale-bot, most are now locked, so I couldn't comment on them directly. I left detailed reproduction data (raw transcript excerpts) as comments on #63599 before opening this — linking here for anyone who wants the fuller trace: https://github.com/anthropics/claude-code/issues/63599#issuecomment-5082484411 and https://github.com/anthropics/claude-code/issues/63599#issuecomment-5082495834
## Environment
- Claude Code v2.1.220 (regression window: v2.1.197 → v2.1.220)
- Windows 11
- Reproduced across `claude-opus-4-8`, `claude-opus-5`, `claude-sonnet-5` as the target override
## Ask
If you've hit this too — a 👍 on this issue (rather than a duplicate comment) helps signal how many people currently have zero working way to pin model/effort per command. Happy to attach fuller transcript excerpts or a minimal repro repo if useful.
Contributor guide
No contributing guide indexed for this repository
Research direction
Reproduce v2.1.220 with ~/.claude/commands/o1h.md and ~/.claude/skills/cah-model-switch-test/SKILL.md, then inspect the session JSONL entries under ~/.claude/projects//. Compare the command_permissions attachment with subsequent assistant model fields and effort.level values; done means both frontmatter overrides are applied for direct slash invocations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- cli, tooling
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100