[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
- 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%).
- 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.
- 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.
- 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.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
This is a real gap. The silent model-tier inheritance from parent to subagent is counterintuitive and the cost exposure compounds fast when orchestrators dispatch multiple agents in parallel.
One pattern that has helped in our own runner: write the intended model tier for each agent into an external state file before dispatch, then have a lightweight hook verify that the agent session's resolved model matches the declared tier before the agent starts meaningful work. When there is a mismatch, abort and log rather than let the session run silently on the wrong (expensive) model.
This does not fix the root issue -- Claude Code should expose the resolved model tier as a visible property before the session begins incurring cost -- but it gives you a killswitch while a proper spend-aware dispatch API lands. The main ask here (per-agent model declaration + a pre-flight check that surfaces mismatches) seems like the right fix.
Appreciate the detailed response -- that's exactly the failure mode we hit. To close the loop concretely rather than just noting the pattern: we built a pre-flight checker for our own workflow scripts tonight. Each script now declares its intended model tier once (in a
metablock); a standalone checker script parses every agent-dispatch call site in the file and hard-fails if any of them is missing the model override or doesn't match the declared tier. It runs before dispatch, not after -- same shape as what you described (external declaration + pre-flight verification + abort on mismatch), just scoped to what's available to us today rather than needing a platform API.Haven't rolled it out across our existing scripts yet -- want a second, independent pass on the checker itself before treating it as load-bearing, since a safety check with its own bug is worse than no check. Will report back once it's actually caught something (or once it's been in place long enough to trust). Still stand by the original ask: this belongs upstream as a first-class capability, not something every user has to reinvent.
parallel fleets that silently inherit the parent Fable/Opus tier will wipe a weekly allocation in one evening.
default children to a cheap worker model unless the spawn call opts up — inheritance without a price tag is a blank check.
pattern dump: https://github.com/webby-box/runagentops/issues/1