Comment by beefsack
13 hours ago
This is how I do it too. I run three levels:
* Orchestrator: Opus 5.5
* Feature lead: GPT 6.1 Sol
* Worker: Muse Spark 1.3 Contributor
As long as you have an appropriate project and sandbox for Muse Spark it's the real secret sauce for my setup and it's dirt cheap on OpenCode Go.
GPT 6.1 Sol is surprisingly efficient too, I've been impressed with it.
My orchestration skill setup is https://github.com/beefsack/processed-beef/
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.
And which agent checks the work that the Worker does? If it's garbage then isn't that just extra tokens consumed by the Orchestrator or Feature lead?
I'd be interested to know what the difference in cost is in this setup on building a complex feature vs using Opus directly.