[BUG] Skill `model:` frontmatter triggers 429 "Extra usage required" on 2.1.76 when session uses opus[1m]
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
- Claude Code 2.1.76, Max plan,
opus[1m]as session model (default) - Create a skill:
---
name: test-sonnet
description: Test sonnet model switch
model: sonnet
user-invocable: true
---
Say hello.
- 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: sonnetfrom skill frontmatter so everything runs on the session model. Trades speed/cost for reliability.
14 Comments
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:
context: forkin 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 forcontext: conversation./model— all skills withmodel: sonnetwork when the parent isn't on Opus 1M. Obviously not ideal since it means giving up Opus for the main session.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:
More context optimization strategies: https://github.com/Sagargupta16/claude-cost-optimizer/blob/main/guides/02-context-optimization.md
Environment
default_claude_max_5x)claude-opus-4-6[1m])Reproduction
model: sonnetin frontmatterWorkaround
Removing
model:from all skill frontmatter resolved the issue. Skills now inherit the session model.Notes
model: sonnet, all triggered the same errorGot this as well. Looking forward to a fix.
still present in 2.1.77
CLAUDE_CODE_DISABLE_1M_CONTEXT=1 clauderemains a workaround, but with 2.1.77 returning default limits on tokens returned by each tool call makes it hard call/compactmuch more often. Previously mentioned workarounds seem more viable for this version.Still an issue in v2.1.81. Not sure why this takes so long.
Still reproducing on v2.1.83, macOS (Darwin 24.1.0).
Opus and Haiku subagents work fine in the same session.
Also seeing this on v2.1.107
Agree, same issue in ver 2.1.107 r/n
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" />
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" />
Same issue here.
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.
❯ /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.
Different symptom (billing/429) but same root surface —
skills/SKILL.md'smodel: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'scommand_permissionsattachment vs. the actualassistant.message.modelin 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.