Hacker News Reader

Comment by wongarsu | Hacker News Reader

Sub agents each have to read part of your code base again to get enough context for the task. And if they take too long, your orchestrator's context is no longer in cache so you pay full price for that again once the subagents finish

If you do it sequentially you only read those files approximately once, and everything hits the same prefix cache

View on HN

Yes but one of the key things about subagents is they keep all of their tool calls and exploration out of the parent context.

If you plan on continuing on in the parent, and aren't going to necessarily be touching the systems the other agents are exploring, it can be worth it.

It's useful in certain situations where the parent context may need the "10,000 foot" view of something without going back in there. But subsystem-specific AGENTS.md/CLAUDE.md files are still superior and accomplish the same thing. The problem with those is they can become stale.

It seems like there could be a useful strategy of writing a plan with a main agent, and then instead of spawning subagents to implement, fork the main context to write each part. Then use one last fork to verify the work. That way you keep reusing the same context without polluting your main context for when you are ready to continue.

I've started doing this by hand in OpenCode and it works pretty well. But there's no UI support for maintaining a tree of related session forks so there's a little bit of manual fussing involved with session naming to keep organized. I also like to end a session with an "AI-friendly terse but detailed summary" (or some equivalent prompt) that I can then dump out to a Markdown file and then the mainline session can still get info back from the branch session. I don't know how much of this is automatable with OpenCode plugins, or in another hackable harness like Pi.

They are just making the point that it makes sense that subagents would use more tokens because they have none of the parent's context.

Right, so it’s a trade off between contexts. There are two reasons to use subagents, parallelism and tailoring of context. For the second, there is the “personality” of the subagents as well as how much context is injected from the main agent. Ignoring the personality, you ideally want the injected context to be small and focused on a single task so the subagent doesn’t get distracted. You want the main agent to be orchestrating all the subagents, but not reading all the same files they are reading, otherwise you’ll be paying for the same tokens in multiple contexts. IMO, this is where prompt engineering comes in, to be able to guide the main agent as to where subagents are desired and where not.

That is true of Anthropic's implementation but not inherent in sub-agents in general.

For the sake of accuracy Claude Code has a "fork" feature which does what you'd expect and based on traces I skimmed this morning it seems under some circumstances you get fork behavior for subagents as well.

Reply on news.ycombinator.com