[BUG] Skill `model:` frontmatter triggers 429 "Extra usage required" on 2.1.76 when session uses opus[1m]

Status Open
Reported on v2.1.76
Maintainer reply None cached
Activity 14 comments · opened Mar 14, 2026

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?

On Claude Code 2.1.76, invoking any skill with model: sonnet in frontmatter from an opus[1m] (1M context) session immediately fails with:

API Error: Rate limit reached

This happens on a fresh session with zero prior API calls. It does not happen on 2.1.75.

What Should Happen?

When opus[1m] is used, the skill using sonnet (sonnet[1m] more specifically) should be invoked without any issue.

Error Messages/Logs

Run `claude --debug`, invoke the skill, check `~/.claude/debug/*.txt`:


[ERROR] API error (attempt 1/11): 429 429 {
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "Extra usage is required for long context requests."
  }
}


The error is not a rate limit — it's an access restriction. The API rejects `sonnet[1m]` because the account doesn't have "extra usage" enabled for sonnet long-context.

Steps to Reproduce

  1. Claude Code 2.1.76, Max plan, opus[1m] as session model (default)
  2. Create a skill:
---
name: test-sonnet
description: Test sonnet model switch
model: sonnet
user-invocable: true
---
Say hello.
  1. Invoke /test-sonnet → immediate 429

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.75

Claude Code Version

2.1.76

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Root cause: Pl6 (SkillModelOverride) in 2.1.76

The 2.1.76 changelog states: "Fixed spurious 'Context limit reached' when invoking a skill with model: frontmatter on a 1M-context session."

This was fixed by adding Pl6, which auto-promotes skill models to [1m] when the session is on a 1M model.

File: cli.js (minified single-file bundle)

| Function | Offset | Purpose |
|----------|--------|---------|
| Pl6 | 10717414 | SkillModelOverride — appends [1m] to skill model |
| Cf | 10718894 | Checks if a model string contains [1m] (/\[1m\]/i.test(A)) |
| gr8 | 10718950 | Checks if model supports 1M context (true for sonnet-4, opus-4-6) |
| Pn8 | 10719150 | Auto-enables 1M for plain sonnet when coral_reef_sonnet flag is set |
| HLA | 1023779 | Reads coral_reef_sonnet from server-side clientDataCache |
| contextModifier | 8358160 | Where Pl6 wraps the skill model assignment in the Skill tool |

// contextModifier in Skill tool (offset ~8358160)

// 2.1.75 — direct assignment, no promotion
if(D) N={...N, options:{...N.options, mainLoopModel:D}};

// 2.1.76 — wrapped with Pl6 auto-promotion
if(D) V={...V, options:{...V.options, mainLoopModel:Pl6(D, N.options.mainLoopModel)}};

Pl6 (offset 10717414):

function Pl6(A, q) {
  if (Cf(A) || !Cf(q)) return A;      // skip if skill model already has [1m] OR session model doesn't have [1m]
  if (gr8(H5(A))) return A + "[1m]";   // promote if model supports 1m
  return A;
}

When session is opus[1m] and skill has model: sonnet:

  • Cf("sonnet") → false (no [1m] suffix)
  • Cf("opus[1m]") → true (session has [1m])
  • gr8("sonnet") → true (sonnet supports 1m)
  • Result: "sonnet" + "[1m]""sonnet[1m]"

The API receives sonnet[1m] and rejects it with 429.

The gap

The 1M context GA announcement states: "Claude Opus 4.6 and Sonnet 4.6 now include the full 1M context window at standard pricing." But for Claude Code, sonnet[1m] is gated behind the coral_reef_sonnet feature flag and requires "extra usage" billing — contradicting the announcement that it's included at standard pricing.

Either sonnet[1m] should be made available to Max plan users to match the announcement, or Pl6 should check account entitlement (HLA()) before promoting sonnet to sonnet[1m].

Version comparison

| Version | Skill contextModifier | Behavior |
|---------|----------------------|----------|
| 2.1.70–2.1.75 | mainLoopModel:D | Skill runs as plain sonnet (200K). Auto-compaction if >200K. |
| 2.1.76 | mainLoopModel:Pl6(D,...) | Sonnet promoted to sonnet[1m]. Rejected if account lacks entitlement. |

Workarounds

  • Stay on 2.1.75 — skill model switching works correctly without auto-promotion. Caveat: if a sonnet skill (200K) is invoked from an opus[1m] session with >200K context, auto-compaction fires or "Context limit reached" occurs (the original bug that 2.1.76 tried to fix).
  • Use opus for all skills — remove model: sonnet from skill frontmatter so everything runs on the session model. Trades speed/cost for reliability.

View original on GitHub ↗

14 Comments

PatrykMoga · 5 months ago

I can confirm the same behavior on v2.1.76, Max plan, Opus 4.6 (1M context), macOS.

Two additional workarounds I found beyond what's listed:

  1. context: fork in skill frontmatter — forked skills don't trigger the promotion since they start a fresh subagent context. Caveat: the skill loses access to conversation history, so it's not a drop-in replacement for context: conversation.
  1. Switch parent session to Sonnet or Haiku via /model — all skills with model: sonnet work when the parent isn't on Opus 1M. Obviously not ideal since it means giving up Opus for the main session.
Sagargupta16 · 5 months ago

While this bug gets fixed, a practical workaround to avoid hitting 1M context limits and 429s: keep your input under 200K tokens where possible.

When input crosses 200K, the 1M context pricing kicks in and all tokens get billed at 2x, which can also trigger rate limits faster. Strategies:

  • Run /compact when sessions get long
  • Use .claudeignore to exclude node_modules, dist, lock files
  • Keep CLAUDE.md under 150 lines
  • Start fresh sessions for new tasks instead of reusing long ones

More context optimization strategies: https://github.com/Sagargupta16/claude-cost-optimizer/blob/main/guides/02-context-optimization.md

bouob · 5 months ago

Environment

  • Plan: Claude Max 5x (default_claude_max_5x)
  • CLI: v2.1.76
  • OS: Windows 11 Pro
  • Session model: Opus 4.6 1M (claude-opus-4-6[1m])

Reproduction

  1. Create a skill with model: sonnet in frontmatter
  2. Start a session on Opus 1M
  3. Invoke the skill → immediate 429 "Rate limit reached"

Workaround

Removing model: from all skill frontmatter resolved the issue. Skills now inherit the session model.

Notes

  • Had 10 skills with model: sonnet, all triggered the same error
  • Extra usage toggle was already enabled
  • Fresh conversation, minimal usage — not an actual rate limit
baswenneker · 5 months ago

Got this as well. Looking forward to a fix.

rooterkyberian · 5 months ago

still present in 2.1.77

CLAUDE_CODE_DISABLE_1M_CONTEXT=1 claude remains a workaround, but with 2.1.77 returning default limits on tokens returned by each tool call makes it hard call /compact much more often. Previously mentioned workarounds seem more viable for this version.

baswenneker · 5 months ago

Still an issue in v2.1.81. Not sure why this takes so long.

limsaehyun · 5 months ago

Still reproducing on v2.1.83, macOS (Darwin 24.1.0).

  • Plan: Claude Max
  • Parent session model: claude-opus-4-6[1m]
  • Subagent model: sonnet (via skill frontmatter or Agent tool model parameter)
  • Error: API Error: Rate limit reached — instant failure, not an actual rate limit

Opus and Haiku subagents work fine in the same session.

msnelling · 4 months ago

Also seeing this on v2.1.107

koznov · 4 months ago

Agree, same issue in ver 2.1.107 r/n

bingcheng45 · 4 months ago

bro same issue, i have did everything on reddit to cap 200k or disable thinking to switch to standard context, it does not work. When i enable extra-usage is worked but cost me $2 even thou i am at 12% barefully using up my 5 hour limit.

2.1.108 --version

<img width="1736" height="172" alt="Image" src="https://github.com/user-attachments/assets/10c3b8b7-9420-499b-8329-d7d8c87eea98" />

davidarces · 4 months ago

I have the same problem. I'm using Opus 4.7 1M and when I use a skill with Sonnet I get this error:

<img width="1200" height="104" alt="Image" src="https://github.com/user-attachments/assets/5afab59a-caa0-42f7-ba97-9000741ba58e" />

missoutlaw · 3 months ago

Same issue here.

rooterkyberian · 2 months ago

there is some weird behavior with model:. It seems that if my session runs Opus, it doesn't autoload Sonnet files as skills but tries to read them instead?
They do work, but I have doubts they truly use sonnet at this point.

$ cat ~/.claude/skills/repro-34296-*/SKILL.md
---
name: repro-34296-no-model
description: Control for claude-code issue 34296 — user-scope skill without model frontmatter
user-invocable: true
---

Say hello without model override
---
name: repro-34296-sonnet
description: Repro for claude-code issue 34296 — skill with model sonnet invoked from a 1M-context session
model: sonnet
user-invocable: true
---

Say hello to sonnet
claude --model opus --permission-mode default
Claude Code v2.1.173 Opus 4.8 with xhigh effort ...

❯ /repro-34296-sonnet                                                                                                                                                                     

⏺ Reading 1 file… (ctrl+o to expand)
  ⎿  ~/.claude/skills/repro-34296-sonnet

────────────────
 Read file

  Read(XXX/.claude/skills/repro-34296-sonnet)

 Do you want to proceed?                                                                                                                                               
 ❯ 1. Yes
   2. Yes, allow reading from repro-34296-sonnet/ during this session
   3. No

````

alternatively, in fresh session:

❯ /repro-34296-no-model

⏺ Hello! 👋

This is the control case for issue 34296 — a user-scope skill with no model frontmatter, so I'm running on whatever model the session is using (Opus 4.8) with no override applied.

No prompts.
PHPCraftdream · 1 month ago

Different symptom (billing/429) but same root surface — skills/SKILL.md's model: frontmatter override. Worth noting the override's reliability has regressed further since this was filed: as of v2.1.220, it now silently fails to switch the model at all (rather than switching and hitting a quota error), even for direct user-typed invocation — verified via the session transcript's command_permissions attachment vs. the actual assistant.message.model in the same turn.

Filed a broader report with full repro/evidence for the current failure mode: #81318. Not claiming this reproduces your specific 429 — flagging in case the two turn out to share a cause once someone looks at the override pathway itself.