Max plan — separated Sonnet/Opus weekly limits push heavy Sonnet users toward Opus unnecessarily
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
I'm a Max plan subscriber and a heavy Claude Code user. I want to flag a counterintuitive consequence of the separated weekly limits introduced with Opus 4.5.
The current design has two independent buckets: an overall weekly limit (any model) and a dedicated "Sonnet only" limit. I understand the intent — protecting users who burn through Opus from losing Sonnet access entirely. That's a valid concern, but the design fails the inverse case, which is mine.
My workflow is Sonnet-heavy by default: most of my work is execution (refactors, tests, scoped edits, mechanical changes) where Sonnet is more than capable, and I reserve Opus for genuinely hard problems (architecture, complex debugging, planning). This is exactly the usage pattern Anthropic recommends ("plan with Opus, execute with Sonnet", /model opusplan).
The problem: when I exhaust the "Sonnet only" bucket but still have overall weekly limit remaining, I'm effectively forced to switch to Opus to keep working — even for tasks Sonnet would handle perfectly. This is bad for everyone:
For me: Opus burns through the overall limit several times faster per message, so I hit the hard wall much sooner than I would have on Sonnet.
For Anthropic: I'm consuming significantly more server resources running Opus on tasks that don't justify it. The rigid separation incentivizes the most expensive model when the cheaper one would suffice.
Proposed Solution
A better design would be a unified pool with a per-model cap (e.g., "up to X% of your weekly limit can go to Opus"). That preserves the original goal — guaranteeing Sonnet availability for users who blow through Opus — while letting users who don't touch Opus much continue using their remaining quota on Sonnet, where it's cheaper to serve.
As it stands, the current structure punishes the workflow Anthropic itself recommends. Please consider revisiting it.
Thanks.
Alternative Solutions
_No response_
Priority
Critical - Blocking my work
Feature Category
CLI commands and flags
Use Case Example
_No response_
Additional Context
_No response_
4 Comments
This pattern matches a broader shape I've been tracking across other Max plan operators. Anthropic's own /model opusplan recommendation hits a wall the moment the Sonnet bucket empties. The remaining options are to wait for the bucket to reset, burn Opus on tasks Sonnet would handle (at the burn rate you described), or move some of the workload off the Anthropic stack. None of those serve the user, and the second option costs Anthropic the most server-side. That inversion is the structural problem your Issue is pointing at.
A workaround that may buy you headroom while the bucket design stays as it is: route mechanical edits — boilerplate generation, scoped renames, formatter-only changes, file-pattern bulk reads — to
/model claude-haiku-4-5instead of Sonnet. Per-message cost against the overall weekly limit should be materially lower for those tasks (the exact metering depends on how Haiku is bucketed in your specific plan tier, which the published docs are not fully explicit about). The trade is reasoning quality on the mechanical portion, which for the workflow you described should be acceptable. This will not fix the bucket structure, but it should stretch your Sonnet runway noticeably.Two observations on the design itself.
The separated bucket protects the operator who burns Opus from losing Sonnet access, but the inverse case — yours — is the more common shape, given that Anthropic's own usage recommendation is plan-with-Opus-execute-with-Sonnet. The current structure penalizes the recommended workflow more than it penalizes the unrecommended one.
The unified-pool-with-per-model-cap design you propose is essentially how
/model opusplanalready behaves in-session: one quota with an internal split between planning and execution. The weekly limit design contradicts the in-session model's behaviour. That inconsistency, not just the bucket sizes, is the source of the friction.I do not have a fix to offer beyond the Haiku workaround. If you have measured the per-task token-cost ratio between Sonnet and Haiku for your specific mechanical workload, that data would strengthen the Issue's case for anyone reading it.
👍 Upvoting as this is a well-articulated version of the feature request. Just closed #57384 as a duplicate pointing back here.
Thank you.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.