Comment by nextaccountic
12 hours ago
Just one thing
Does anyone have any evidence that having the most powerful model being the orchestrator, and other sub agents being progressively less powerful, is optimal? Is this just common sense or it has been measured somehow?
For me it could be that this scheme may make the code itself poorly written, verbose or faulty
https://www.nature.com/articles/s42256-026-01268-y/ This is probably what you're looking for. TLDR; weaker orchestrator + strong workers scored higher than the reverse. Caveat with that, old paper: "High-capability models: GPT-5, Claude Sonnet 4.5, Gemini-2.5 Pro; low-capability: GPT-5 nano, Claude Sonnet 3.7, Gemini-2.0 Flash."
With that said, there is evidence that we recently crossed over a line for 'best practices' when it comes to systems of multiple agents. Comparing the shapes of 'n agents working collaboratively' vs '1 agent spawning n agents to handle distinct work', Opus 5.5[1] and Opus 5[4] performs better with the former, Sonnet 5.5[2] and Opus 4.8[3] performs better with the ladder.
[1] https://www-cdn.anthropic.com/fc1b44717c85dc068bc6ba50242199...
[2] https://assets.claude.com/870c8f525702625d2c62fc6dd04c857e32...
[3] https://assets.claude.com/0f0c97ad20d8005706296bd92aa1c27c6b...
[4] https://assets.claude.com/ceaf5c7ff2783855203fde8208ec311252...
I think whether it's bottom-up or top-down, the core principle is still that you use cheap models for grunt work and use frontier models for expertise and direction.
In my setup, the orchestrator also drives a lot of the design and planning, and the less capable models get inputs from the more capable models by responding back up the chain. The more capable models also review everything that is produced by the cheaper models.
I've also had systems that invert this and allow cheaper models to call out to more capable models when they need to, but in my observation I found them quite bad at knowing even when to call out and I find wrapping the cheap models a bit more reliable in that problems tend to get caught before they bubble up to the user.
It sure saves tokens and even the 100$ subscriptions provide massive amounts of dev power. Also fair to note - mixing models is perhaps a good idea anyway as this way the entropy in them mixes and this supposedly improves result quality.