I do the opposite of this, use Qwen3.8-27B as subagents, Opus 5.5 as orchestrator and planner, never implementer, and it cuts my token usage significantly. So it is using Claude to direct Qwen. Never thought of the other way around, will give this a try soon as possible.
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/
My goal was/is to have a local model as a "stable" part of the system, or at least a part of it that you have full control over, and have it reach out to the cloud for some Opus. In practice, to get results, I operate as you say.
At this point if I could do anything with zero effort or time, I would get Opus 5.5 to make a grand scheme, handoff to the local model, and give it ability to reach out to Opus again.
Both of those orchestrations will work for sure.
Smart agent to orchestrate cheaper agents for labour.
Dumber agents to be very explicit about asking smarter agents for requests that require deep information.
This is a thing - the SOTA models really light up the more information you can provide them, and humans are too lazy / incapable of doing that in every prompt.
Entirely depends on what you are trying to do.
Edit: you can also use a smart agent to ask another smart agent, obviously, which is good for personal workflows.