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

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.