Claude Code subagents are supposed to get more useful as a task runs, not less. The context is already loaded, the earlier decisions are already made, and in theory the model should just keep building on what it knows. In practice, teams running non-trivial orchestration setups keep hitting the opposite. Past roughly 200,000 tokens of accumulated context in a single subagent session, output quality starts sliding, and the token bill keeps climbing at the same time. Practitioners in the Claude Code community have started calling this the dumb zone.
It is not a bug you can patch and it is not specific to one workflow. It is a structural trade-off in how subagent context accumulates over a long session, and if your team is running dozens of subagent dispatches a day, it is already costing you money whether anyone has noticed the quality drop yet or not. This post walks through what is actually happening inside a subagent session, the decision it forces on every task, and a few concrete patterns worth building into your own Claude Code orchestration rather than working it out case by case under deadline pressure.
What the dumb zone actually is
Every subagent session carries forward everything that has happened in it: the original instructions, every tool call, every file read, every intermediate result. That accumulated context is genuinely useful early on, it is why a subagent that has already explored a codebase answers faster and more accurately than a fresh one. But context does not stay free. Once a session has pulled in enough tool output, file contents, and back-and-forth reasoning, the signal the model actually needs gets buried in noise it does not. Past a rough 200K token mark, teams report the same pattern: answers get vaguer, instructions from earlier in the session get missed or half-applied, and the subagent starts re-deriving things it should already know, at real token cost.
The frustrating part is that none of this shows up as an error. There is no warning, no hard failure. It shows up as output that is subtly worse, on a bill that is quietly higher, which is exactly why it is easy for a team to run in the dumb zone for weeks without diagnosing it.
The decision you are making, every time
Once you know the dumb zone exists, every long-running subagent task forces the same call. Keep working in the same session, where context is already loaded and cached, or spin up a fresh one and pay to re-derive everything it already knew. Stay too long in one session and quality degrades while cost creeps up in the background. Rotate too aggressively and you pay full price re-establishing context you already had, on tasks that did not need a reset at all.
There is no universal threshold that works for every task type, every codebase, or every subagent role. Most teams that run into this end up defining their own rules by trial and error, usually after noticing a subagent quietly getting things wrong on a task it should have handled easily. A few patterns are worth building into your own orchestration rather than treating this as a judgement call every time:
Set a hard context ceiling per subagent, roughly 150K to 200K tokens is a reasonable starting point, and treat crossing it as a trigger to condense context and hand off, not a hard stop mid-task.
Match model tier to task complexity deliberately. Not every subagent needs your most expensive model running the whole way through. Simple, well-scoped work can run on a cheaper tier without a real quality hit.
Keep the handoff summary short and structured: what was done, what is left, and what decisions were already made, so a fresh session does not have to re-derive context from the raw transcript.
None of these are exotic. They are the kind of guardrails a well-run engineering team already applies to code review or deployment gates. Subagent orchestration just has not caught up yet for most teams, because the failure mode is new and does not throw an obvious error.
A cleaner way to apply model-tiering than CLAUDE.md rules
One useful technique here is skipping the instinct to encode this logic as another paragraph in CLAUDE.md. A hook that only activates when a top-tier model spawns a subagent, and leaves cheaper-tier dispatches alone, keeps the orchestration logic out of the main instruction file entirely, and only fires where it is actually relevant.
That is a smaller change than it sounds. It is a few lines of hook configuration rather than a growing wall of conditional instructions that every agent has to parse on every run, regardless of which model is actually doing the work. CLAUDE.md files have a habit of accumulating rules nobody remembers adding, and every rule in there gets read on every dispatch, cheap or expensive. Pushing model-tiering logic into a targeted hook keeps that file lean and keeps the tiering behaviour scoped to exactly the sessions where it matters.
Why this matters for cost, not just quality
For an Australian business running Claude Code across a team, the dumb-zone problem shows up first as a quiet cost leak, well before anyone notices a quality drop. Sessions get kept alive too long "just in case," burning tokens at degraded output quality. Or they get rotated too early and pay full re-derivation cost on tasks that did not need a reset in the first place.
Neither failure mode looks dramatic on its own. A slightly longer session here, an unnecessary handoff there. But both compound across a team running dozens of subagent dispatches a day, and teams we have worked with in Sydney and Melbourne have found this can add up to $300 to $600 AUD a month in wasted token spend on a mid-sized team, without a single obvious incident to point to. It is the kind of cost that never shows up as a line item worth investigating on its own, which is exactly why it survives so long unaddressed.
Signs your team is already in the dumb zone
A quick self-check before you assume this does not apply to you:
Subagent responses start ignoring or half-applying decisions made earlier in the same session, especially on tasks running longer than 30 to 40 minutes.
Context length keeps climbing past 150K to 200K tokens with no condensing or handoff step built in anywhere.
Token spend per task creeps up over a project's life without a matching increase in task complexity.
Nobody on the team can say, off the top of their head, when a subagent session should be rotated versus kept alive.
If two or more of those sound familiar, the dumb zone is probably already costing your team money, not just output quality.
Where to start
You do not need to redesign your whole orchestration setup this week. Start with a context ceiling, even a rough one, and a short structured handoff format for when a subagent crosses it. Add model-tiering as a targeted hook rather than another CLAUDE.md paragraph once the ceiling is in place. Revisit both after a couple of weeks of real usage, because the right numbers for a codebase-heavy engineering team will not be the right numbers for a subagent doing customer support triage.
Automata AI works with Australian businesses to tune Claude Code orchestration for both cost and output quality, including context ceilings, model-tiering hooks, and handoff formats built around how your team actually works. If your subagent bills have been creeping up without a clear reason, get in touch and we will help you find out why.
