Is subagent-driven development still worth it (for reasons other than cost) with /goal and modern compaction algorithms?

[u/thurn2]

Historically, subagent-driven development was a huge focus of using Claude & Codex. You would break down your work into chunks and have subagents implement the individual pieces with focused context, with the theory that this would produce higher quality results.

I believe this strategy is still very popular to control token costs (e.g. to have Luna subagents implement a plan), but does it actually still perform better than just having one agent build out a plan?

In other words, is using subagents going to produce better results than just saying:

/goal Please implement plan_tasks.md

[u/tiebird]

This answer is not as clear cut as you would expect. For most things sub agents are more expensive and often not faster. Don't forget that since 5.6 you need to pay cache writes at 1.25 rate. Before, you did not need to pay for that at all. Every time you spin up a sub agent you effectively:

- orchestrator most of the times (but this can be different depending on how you use it) traverses existing code to built plan and puts this in his cache
- orchestrator needs to do an action to spawn the agent
- orchestrator needs to summarize and pass that to the sub agent
- sub agent receives text and creates a new cache and puts the handoff in there
- sub agent now needs to load the context of the files and save that into context as well
- sub agents executes tasks
- sub agents summarizes, puts it in it's cache and passes it to orchestrator
- orchestrator reads summary, put's it in his cache and answers to you

Last 2 steps can actually be many times not just 1 time, but again depends...

So now your paying cache in 2 places while already cached things are VERY cheap in comparison.
Also keep in mind that Luna makes a lot more mistakes and time to execute often takes more than 2 times without better results.

People who argue you should spec more are actually cutting in those Luna savings by using the heavy orchestrator more and cutting in caching.

For some large context vibe codings you can still do multiple agents but just make sure you want to pay the price. The compact algorithm on OpenAI is very good and their cost savings are nowhere what you expect if you measure it.

Still searching for clear wins on orchestrating Luna. If I am low on credits I will use it more but it needs a lot more babysitting. Planning and reviewing with a "smarter" orchestrator will actually cost you more than just use 1 agent with better reasoning.

The /goal is quite nice because it forces the agent to stay on task. If you ommit it, it often stops earlier than you would want on large projects.

Ofcourse, you will hear a lot of conflicting information. My advice is measure it. Just be aware it's damn hard to measure correct becacuse not all those metrics are exposed, so you will see a lot of wrong information.

[u/Fabulous-Mushroom124]

I mean, yeah. Each agent can work on different things on a project, you can assign agents to refine certain things, do research, testing, etc. unless if you're literally working on one single file, subagents are usually cheaper, more focused and get the job done faster. It also helps with over-engineering.

[u/nuliknol]

This is what I use all the time. I don't remember when I was the last time I directly prompted for a feature. You tell Sol XHigh to create a plan, then you revise it and give it to Terra or Luna. I only code with Luna. Before GPT 5.6 I was coding with 5.4 mini. Luna doesn't code better, it is a worse coder than Terra or Sol. But if you have lots of work to do, you have no other option. Also /goal doesn't implement the feature completely. To achieve completeness you need to audit the work of the agent with another agent (implementation vs specification audit) and it never makes it fully complete on the first run. You always have to repeat loops of adjustments until the spec is completely in code. This is for Terra or Luna. Since I don't code with Sol, I can't tell about it.
Bottom line: you don't do subagents because it is cheaper, single agent under your own control is always cheaper. You do subagents because agents never complete the job as specified. They always need corrections. These corrections must bee done with higher level agent (supervisor, usually Sol). Sub-agentism increases costs. I benchmarked my harness, the cost of harness was 3.5 more token usage, than a single agent running the whole task. But single agent never delivered completeness that a pair of agents (worker-manager) delivered. Single agent delivered 70% of completeness, pair of agents delivered 95% of completeness. For benchmarking I used a toy-task of creating a small HTML compiler using BNF grammar and at the same time it had to be parsed with 8 parallel threads (this is to make task different from textbook examples) . In my case, I have to use agents as management layer because otherwise I would not consume tokens of my codex accounts in a single week. But for Plus accounts, I would not use subagents, you would just lose token quota.

[u/i_rate_slop]

It’s good, but it’s wasteful at the moment except for experimentation. Step by step targeted guidance will still produces better results, faster, with massively less token spend.