[reacharavindh]

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..

[rasz]

>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.

[lwansbrough]

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.