claude-code - 💡(How to fix) Fix Max plan — separated Sonnet/Opus weekly limits push heavy Sonnet users toward Opus unnecessarily [1 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• 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