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)

Open
#81,318 5 comments 3 reactions 0 assignees View on GitHub
area:skills
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.