[BUG] Parallel subagent fleets silently inherit session model tier — burned full weekly Fable + Opus allocation in one evening

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?

Subagents dispatched through Claude Code's multi-agent orchestration (the Agent tool) silently inherit the parent session's current model tier — with no warning, no confirmation, and no visibility into how much of a fixed weekly allocation they're about to consume. I dispatched a 7-agent parallel fleet while my session was on a premium tier (Fable-5) already at 92% of weekly quota; usage went from 92% to fully exhausted with no signal in between. Two of the seven subagents then died outright mid-task with unhandled "reached your limit" API errors — the task simply terminated rather than degrading gracefully. I had to react by manually switching tiers (Opus, then Sonnet) after the fact, with no indication of which tier still had room.

What Should Happen?

Before a large parallel fleet is dispatched, the user should be warned or asked to confirm that N subagents are about to run on the session's current tier against a fixed allocation, especially when that tier is already low. While the fleet runs, there should be some real-time visibility into cumulative consumption, so a user can stop or downgrade before hitting zero. If a tier does get exhausted mid-fleet, an in-progress subagent should fall back to the next available tier (or pause/queue for reset) instead of terminating the task outright.

Error Messages/Logs

Steps to Reproduce

1. Start a Claude Code session on a premium, quota-limited model tier (e.g. Fable-5), with your weekly allocation already partially used (mine was at ~92%).
2. Dispatch several parallel subagents via the Agent tool for a large fan-out task (I used 7), without specifying an explicit per-agent model override.
3. Let the fleet run — each subagent inherits the session's current tier by default, with no warning shown about tier or remaining quota, and no real-time usage indicator as tokens are consumed.
4. Once the tier's weekly allocation is exhausted, any subagent still mid-task terminates immediately with an unhandled API "limit reached" error instead of falling back to another available tier.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.234

Platform

Other

Operating System

macOS

Terminal/Shell

Other

Additional Information

Additional context:

The Agent tool already supports an explicit per-call model override, so the capability to avoid this exists — the gap is that nothing surfaces the need for it before a fleet is dispatched, so the default (silent inheritance of the session's current tier) is what most users will actually hit. I only found this after being burned once and reading the tool schema closely.

None of this is configurable through a settings menu. There's no UI to set a default model/fallback policy for subagent dispatch, per-task-type or otherwise — the only way to influence it is by prompting Claude to pass explicit overrides in its own tool calls, and the only way to make that a standing policy is writing it into a project doc myself and hoping it gets applied consistently. A user who doesn't already know to ask for this has no control surface at all.

This isn't a one-off edge case for me. I'm university faculty using Claude Code to produce course materials on a recurring basis (multiple lecture decks this term alone), and multi-agent fan-out is a natural fit for that kind of work — author N independent sections in parallel, verify, assemble. Any user running agentic/multi-agent workflows on a fixed-cap subscription plan (not pay-per-token) is likely to hit the same wall, probably more than once, since there's no visible signal warning them until the tier is already gone.

As a workaround, I've now built my own policy (which node/task type maps to which model tier, applied via explicit per-call overrides) to avoid re-triggering this — but that took a full evening of lost work and quota to arrive at, and required already knowing the pitfall existed. A settings-level default (per-workflow-type tier + fallback behavior) would have prevented this outright.