If you run background subagents in Claude Code and the usage limit drains faster than the work seems to justify, Anthropic quietly fixed a real piece of that on November 4. Sessions that use background subagents now consume about 5% less of the usage limit, which Anthropic frames as roughly 6% more prompts on the same allowance. The fix is not a bigger limit and not a discount. It is a change to how subagent status lines get written.
What changed on November 4
Anthropic's Claude Code account announced the change on X, and BuilderWithin has a straight writeup. Background subagents are the helpers you hand a scoped job while you keep working in the main session. While one runs, it refreshes its status line every 30 seconds so you can see what it is doing. That refresh, not the subagent's actual work, was the expensive part. The fix is live for everyone on Team and Enterprise and rolling out gradually on Pro, Max, and Ultra. It needs Claude Code 2.1.316 or later, per the official changelog.
The old cost: your history, every 30 seconds
Here is the mechanism. Each status refresh used to re-read the subagent's entire conversation to produce one line of status text. A subagent that runs for an hour refreshes 120 times, and every one of those refreshes paid for the full history again. The longer the subagent ran, the more each refresh cost, because the history only grows. All of it counted against the same session allowance as your real work.
The new mechanism: a small model writes the status
Now Haiku 5.5, Anthropic's small low-cost model, writes the status line from short notes instead of re-reading the transcript. Anthropic says each update costs about 99% less than before. The subagent itself keeps running on whatever model you gave it, unchanged. Nothing about the actual work moved, only the reporting around it.
Back-of-envelope: what 720 updates used to cost
The percentages are Anthropic's, not my measurement, but the arithmetic that motivated the fix is easy to reproduce. Assume three background subagents running two hours each at the default 30-second refresh, with transcripts averaging 20k tokens:
updates per subagent: 2 h * 120 updates/h = 240
combined: 3 subagents * 240 = 720 status updates
re-read tokens: 720 * 20k = 14.4M tokens per session, pre-fix
Fourteen million tokens of re-reading to produce three lines of status text. Even if cache discounts softened that bill, it drew from the same session allowance, which is why a 99% cut per update lands as "only" 5% of the session total. The prefix cache piece I wrote earlier covers why repeated reads of a growing transcript are cheaper than they look but never free: why your agent bills spike mid-task.
What 5% of a limit actually buys
Five percent sounds small next to 99% because they are not the same denominator. The 99% applies to the status-update stream alone. The 5% applies to the whole session: your prompts, the subagents' real work, everything. Anthropic describes the result as about 6% more prompts for the same limit, and the arithmetic checks out, since spending 5% less buys you roughly 1/0.95 of your previous prompt count. Two honest boundaries: sessions without background subagents see no change, and if you already run several helpers in parallel the gain stays a few percent, not a doubling.
How to check you have it
claude --version
# needs 2.1.316 or later
npm install -g @anthropic-ai/claude-code@latest
Version first, because anything older than 2.1.316 cannot have the fix. On Team and Enterprise it should already be live. On Pro, Max, and Ultra the rollout is gradual, so two near-identical sessions can still draw slightly different amounts for a while. Do not try to measure a 5% delta from one session, the run-to-run noise is larger than the signal. Watch your limit drain across a few days of normal work instead.
What this does not fix
The boundary matters. The subagent's own work still costs what it costs, on the model you picked. A long main-session transcript still pays its context bill every turn, cache or no cache. And the five-hour session window still closes when it closes; the wrap-up behavior at the limit is a separate mechanism, and I went through what it does and does not replace when Claude Code started wrapping up at the 5-hour limit. If your real problem is coordinating several agents rather than paying for them, the state-file patterns in running 4 agents in parallel are still the place to look.
The setting that pairs with this
The same 2.1.316 release that carries this fix also made subagent effort a setting, which I covered in the 2.1.316 changes:
export CLAUDE_CODE_SUBAGENT_EFFORT=low
Cheap status reporting plus a tunable effort level changes the economics of handing off scoped work. If you stopped using background subagents because the overhead felt out of proportion to small tasks, that math moved this week. Update, run one background subagent on a job you would normally do inline, and see what the limit meter says after a few days.
Top comments (0)