I’m not sure how true this is, Opus 5 immediately used 2 subagents on the first task I gave it on Friday. In fact my first thought was how it was similar to Fable in that sense.
In theory. But in practice, in my experience, sub-agents increase cost.
Sub-agent tasks often have overlapping context after the point of dispatch. Example: you tell agent 1 to explore folder A and agent 2 to explore folder B, if they have the same structure a single agent might be able to discover what it's looking for faster in serial mode vs. parallel. And if not faster, likely with fewer tokens.
And as the orchestrator context grows, it also loses out on capturing the nuance from some of the sub-agent context. In theory they pass some of that back, but realistically things get missed, and you can't apply learnings to parallel runs like you can in series.
The latest frontier models are very good at taking the knowledge they've acquired during a session and applying it forward. Sub-agents make more sense in cases where the agent is dumb to begin with and can't make use of the context it learns from serial execution.
So you burn more tokens. I had a situation recently where LLM asked to interpret bitmap inside the source code encoded as glyphs kept calling into Imagegen and generating photorealistic pictures of computer monitors displaying some random example hallucinated logos with captions like "your logo would go here" :o. I had to take over and directly prompt to write javascript that draws the bitmap. LMM generated single page js app performing this task (fillRect to canvas) in less than a second, 10 mines of js.
Anecdotal, I've been running my usual building skills which keep the main agent as the orchestrator and every step from execution, review, bug fix happens via subagents. So far in my 2 days of use of Opus 5 in medium and high effort modes, I haven't not observed it avoid using subagents.
I have also not observed it using less subagents than usual in regular chats. However, that could be due to limited use over a small timeframe.
obviously overriding user intent isn't great. it's probably something you can argue about it with, put in your AGENTS.md oh right oops Anthropic refuses to play well CLAUDE.md in strong letters to insist on.
but i have to say i'm not super shocked or surprised. simply from the perspective of: i don't think subagents are super great to use anymore! they go off and do a bunch of duplicate research, then come back and deliver a cheap facimile of the information the main agent often already knew.
that's definitely not always the case, but i feel like so so so often the main agent would be better just doing the research itself, seeing the things. it can sometimes mean wasting some context on dead-ends. which, in an open model where thinking is actually captured and editable in the api, is not a huge deal. but i don't think claude is capable of the same history editing, afaik, in part probably because it won't actually give you it's thinking trails.
> ... but i have to say i'm not super shocked or surprised. simply from the perspective of: i don't think subagents are super great to use anymore
The author of the pi.dev minimal harness doesn't like subagents. It's interesting to see that now Anthropic hardcodes instructions trying to steer away from subagents.
It could be time for those still believing in those to ponder why that is.
subagents are only useful if the primary agent can construct a strong direction and scoped to a specific change. It keeps the context bloat in the main thread to a minimum but lets the agent flex it's need to re-read things.
A proper harness will learn how to provide better context, existing tool calls, etc and then it's not so wasteful.
Working on a local LLM, subagents are part of how to extend the useful context of the main agent. The other is compaction. Used together, we can get int 1M tokens with only running between 50-85k context.
I’m not sure how true this is, Opus 5 immediately used 2 subagents on the first task I gave it on Friday. In fact my first thought was how it was similar to Fable in that sense.
Why though? They are a cheap way to do something without a whole wall of tokens from the said thing polluting the main context…
One would think it is actually a useful thing both for the users and the LLM providers that are compute constrained at the moment..
In theory. But in practice, in my experience, sub-agents increase cost.
Sub-agent tasks often have overlapping context after the point of dispatch. Example: you tell agent 1 to explore folder A and agent 2 to explore folder B, if they have the same structure a single agent might be able to discover what it's looking for faster in serial mode vs. parallel. And if not faster, likely with fewer tokens.
And as the orchestrator context grows, it also loses out on capturing the nuance from some of the sub-agent context. In theory they pass some of that back, but realistically things get missed, and you can't apply learnings to parallel runs like you can in series.
The latest frontier models are very good at taking the knowledge they've acquired during a session and applying it forward. Sub-agents make more sense in cases where the agent is dumb to begin with and can't make use of the context it learns from serial execution.
>Why though?
So you burn more tokens. I had a situation recently where LLM asked to interpret bitmap inside the source code encoded as glyphs kept calling into Imagegen and generating photorealistic pictures of computer monitors displaying some random example hallucinated logos with captions like "your logo would go here" :o. I had to take over and directly prompt to write javascript that draws the bitmap. LMM generated single page js app performing this task (fillRect to canvas) in less than a second, 10 mines of js.
Anecdotal, I've been running my usual building skills which keep the main agent as the orchestrator and every step from execution, review, bug fix happens via subagents. So far in my 2 days of use of Opus 5 in medium and high effort modes, I haven't not observed it avoid using subagents.
I have also not observed it using less subagents than usual in regular chats. However, that could be due to limited use over a small timeframe.
Maybe a way to do product segmentation or sandbagging? Then later they can claim gains by removing the restriction on sub-agents.
more likely it's a bug where the agent, when told it can use subagents over prescribes them like a doctor gives out opiods.
One of the reasons why in march people started reporting token burn rates with little effort.
https://archive.md/SOf7y
obviously overriding user intent isn't great. it's probably something you can argue about it with, put in your AGENTS.md oh right oops Anthropic refuses to play well CLAUDE.md in strong letters to insist on.
but i have to say i'm not super shocked or surprised. simply from the perspective of: i don't think subagents are super great to use anymore! they go off and do a bunch of duplicate research, then come back and deliver a cheap facimile of the information the main agent often already knew.
that's definitely not always the case, but i feel like so so so often the main agent would be better just doing the research itself, seeing the things. it can sometimes mean wasting some context on dead-ends. which, in an open model where thinking is actually captured and editable in the api, is not a huge deal. but i don't think claude is capable of the same history editing, afaik, in part probably because it won't actually give you it's thinking trails.
> ... but i have to say i'm not super shocked or surprised. simply from the perspective of: i don't think subagents are super great to use anymore
The author of the pi.dev minimal harness doesn't like subagents. It's interesting to see that now Anthropic hardcodes instructions trying to steer away from subagents.
It could be time for those still believing in those to ponder why that is.
What are you saying
subagents are only useful if the primary agent can construct a strong direction and scoped to a specific change. It keeps the context bloat in the main thread to a minimum but lets the agent flex it's need to re-read things.
A proper harness will learn how to provide better context, existing tool calls, etc and then it's not so wasteful.
Working on a local LLM, subagents are part of how to extend the useful context of the main agent. The other is compaction. Used together, we can get int 1M tokens with only running between 50-85k context.
I'm honestly so sick of Anthropic nerfing models, fucking around with the system prompts, just working against me/others.