New Rate Limits Require Granular Model Selection for Cost-Effective Usage
Co-written with Claude Code AI Agent:
TL;DR - We Need Sub-Agent & Task-Level Model Control NOW
24 Opus hours/week ÷ 4 parallel agents = 6 hours of real work. We MUST have:
- SUB-AGENT LEVEL:
"rust-refactoring-agent": "opus","docs-agent": "sonnet" - TASK/ACTIVITY LEVEL: "When coding Rust → Opus, When writing docs → Sonnet"
- PROMPT LEVEL:
[model:opus]for complex one-off tasks (see #4016) - FILE PATTERN LEVEL:
*.rs → opus,*.md → sonnet - QUOTA MANAGEMENT: Better than "switch at 50%" - need reserves for critical tasks
Current state is BROKEN: /model changes ALL sessions globally - even overriding project settings!
Summary
Without granular model control, the new rate limits (starting August 28) make Claude Code unusable for professional development. Project-level settings aren't enough - we need to optimize EVERY sub-agent, EVERY task type, and EVERY prompt to stretch our 24-40 Opus hours across an entire week.
Example: A single "refactor this codebase" command spawning 4 sub-agents burns through daily Opus quota in 90 minutes. We need to configure which sub-agents actually need Opus vs Sonnet.
Problem Statement
- Harsh Rate Limits: 24 Opus hours per week means only 6 effective hours when running 4 parallel sub-agents
- No Usage Visibility:
ccusagecommand doesn't work for subscription users, leaving us blind to quota consumption - Inefficient Model Deployment: Cannot specify which sub-agents or tasks should use Opus vs Sonnet
- Cost Inefficiency: Sonnet failing on complex tasks and requiring multiple retries can be more expensive than using Opus once
Current Limitations
Even basic project-level model selection is broken:
- While
.claude/settings.jsontheoretically supports project-specific models, the/modelcommand overrides this globally - Changing model in one project/session changes it for ALL projects and sessions
- This makes it impossible to have different model preferences per project
- Users experience model changes propagating across unrelated work
Missing granular controls we desperately need:
- No way to specify model per:
- Sub-agent
- Task type
- Programming language
- Prompt
- Workflow stage
- File pattern
- Complexity level
Proposed Solutions
1. Per-Sub-Agent Model Configuration
TODO
2. Rule-Based Model Selection
TODO
3. Per-Prompt Model Specification (relates to #4016)
[model:opus] Refactor this complex Rust async state machine
[model:sonnet] Explain what this function does4. Workflow-Aware Model Selection
workflow:
planning: sonnet
implementation: opus
testing: sonnet
documentation: sonnet5. Dynamic Model Switching Based on Failure
- Start with Sonnet
- Auto-escalate to Opus after N failures
- Track success rates per task type
6. Smart Quota Management Controls
Current "Default (switch at 50%)" is too crude. We need: Flexible threshold controls, better more fine grained control, etc.
Real-world example: Even writing THIS GitHub issue required switching to Opus! Yet routine tasks like "search for files" or "follow instructions in README","rebase branch" etc, work with Sonnet.
Smart allocation strategies:
- Reserve Opus quota for complex/creative tasks
- Force Sonnet for routine operations (file navigation, basic edits)
- Gradual degradation instead of hard cutoff
- Time-based quotas (more Opus during critical project phases)
Related Issues
- #3842 - Model selection persistence issues (our issue extends this to sub-agent granularity)
- #4016 - Per-prompt model specification (we support and extend this concept)
- #4442 - Hierarchical configuration system (our proposal fits within this framework)
- #3123 -
/modelcommand corrupting settings (critical bug affecting all model management)
Why This Is Urgent
- Timeline Pressure: Rate limits start August 28, 2025 - we need time to:
- Implement the features for those changes
- Test new real workflows
- Update our development practices
- Train teams on new model selection strategies
- Refactor existing automations and scripts
- Adoption Time Required: Users need weeks to:
- Understand their actual Opus vs Sonnet needs
- Configure project-specific rules (once they actually work)
- Optimize sub-agent workflows
- Establish best practices for model selection
- Migrate from current broken global model switching
- Parallel Usage Impact: 4 sub-agents = 4x faster quota consumption
- No Visibility: Without working
ccusage, users will hit limits blindly - Complex Projects: Non-standard architectures REQUIRE Opus, Sonnet fails repeatedly
- Economic Reality: Inefficient model allocation wastes both quota and money
Request for Comment
Please share:
- Your use cases requiring selective model deployment
- Proposed configuration formats
- Priority of different granularity levels
- Workarounds you're currently using
This is an urgent feature request given the upcoming rate limits. Without granular model control, professional Claude Code usage will become severely limited.
9 Comments
AI Assistant:
Additional context from real-world usage:
I wanted to share how the lack of granular model control is already forcing workarounds that shouldn't be necessary. When Sonnet fails on complex tasks (which happens frequently with non-standard architectures, complex Rust async code, or unusual project structures), I often have to:
The irony: Sonnet seems cheaper but often costs MORE because:
What's particularly frustrating: Tasks that clearly differ in complexity all consume the same model:
Without the ability to pre-configure model selection based on task type, we're forced to either:
This isn't just about cost optimization - it's about making Claude Code actually usable under the new limits. The current all-or-nothing approach will force many of us to seek alternatives, which would be unfortunate given how powerful Claude Code can be when it has the right model for the right task.
1.0.64 change log:
Agents: Added model customization support - you can now specify which model an agent should use
maybe can resolve that ?
Co-written with LLMs:
Thanks, @SamPeng87. The 1.0.64 per-agent model option is helpful and should be split out as one sub-ticket we can mark resolved/verified.
My intent with this issue is to act as a master ticket for a bigger, related set of problems that were previously “papered over” by just using Opus more. With Opus time limits, we need the full set of controls as soon as possible; individual sub-tickets can track each piece.
On sub-agents (why agent-level isn’t enough):
We need flexibility because Claude Code is used many ways; enforcing one usage pattern will be limiting. The power comes from choosing the right model per step, not just per agent—especially under quotas and when not everyone can stack multiple Max-20 subscriptions. And because sub-agents never spill context by design, any in-thread model switches or prompt-level overrides must be implemented as separate controls, not via sub-agents alone.
To illustrate why this should be a “master ticket” with sub-issues, here are just a few UX/design directions (not mutually exclusive):
ModelSwitch(opus, max_turns=10),GetCurrentModel./model opus max=5→ after 5 turns auto-switch back to Sonnet./withModel opus Prompt …or/withModel opus max=5 Prompt….{"model_routing_rules":{"opus":["debugging report review","Rust coding","algorithm design","resolving merge or rebase conflicts"],"sonnet":["summarize large files","search for files","run basic CLI commands","make git commits","call FooBar tool"]}}.Escfeels like it interrupts everything, including sub-agents, and resuming is uncertain.) (instead of spawning a new sub-agent—since that one will not see the prior conversation) .--side-car-port 1234so an external controller can receivestream-jsonJSONL event streams and send control commands like “main thread → Opus for 5 turns”, “sub-agent A5 → Sonnet”.What this master ticket should track (proposed sub-tickets):
Highlights (why this matters):
Yes, I think that this topic is related to the Inefficient Token Usage one that you referenced.
This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.
Keeping this alive.
This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.
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.