Subagent orchestration: plan with a strong model, execute with cheaper ones
Subagent orchestration means a stronger model plans the work and verifies the result, while cheaper models handle the narrow steps. Done well, it cuts cost without lowering quality. Done by accident, every subagent inherits the most expensive model and the savings disappear.
I use this setup for most big tasks. But I also learned when not to use it. In this article, I explain what a subagent is, why subagents often cost more than expected, and how I split the work between models.
What is a subagent?
A subagent is a separate agent session that the main agent starts for one focused task, like finding where a function is used. It works in its own context window and returns a short result. That keeps the noisy part of the work, like reading many files, out of the main session’s context.
Why do subagents often cost more than expected?
Because of inheritance. If you do not say which model a subagent should use, many setups run it on the same model as the main agent.
In my analysis of 1,674 sessions, 85% of subagents inherited my main model while they were only searching. You can find the details in my token usage analysis on SwiftLee. A reader who ran my cleanup prompt had the same issue. Their subagents made up 33% of their usage, and 92% of that ran on the most expensive model. Their instructions asked for subagents, but never named a model.
A search does not need your strongest model. Paying for one anyway, across dozens of subagents, adds up quickly.
How should you split the work?
| Role | Best fit | Examples |
|---|---|---|
| Orchestrator | Stronger model | Plan the task, split it, review results, decide when it is done |
| Executor | Cheaper or faster model | Search the codebase, apply a well-defined edit, run a command |
| Reviewer | Cheaper model without task context, or a check | Review the diff with fresh eyes, run tests |
Every provider offers a cheaper model for daily work and a high-end model meant for planning and architecture. In my experience, the best approach is not to do everything with one model. I use the smartest model to make the plan and ask it to orchestrate cheaper models, while it stays in charge of the quality.
You do not have to pick the models yourself. I let my agent decide which model is good enough for each subagent. It is good at this. A subagent doing a simple code change can use a cheaper model, while one doing architecture research can get a smarter and more expensive one.
When is orchestration not worth it?
For simple tasks. Subagents add overhead, so I pick one good medium model and let it do the whole task in one go. Orchestration pays off when a task is large, when it involves a lot of reading or searching, or when you want an independent check.
How do you get an independent review?
Ask a cheaper subagent to review the code without giving it the task context. Because it has no context, it has no preferences and is not biased. Its feedback goes back to the main agent, which does have the context. That agent can then decide for each point whether to build it in.
I prefer this over a fully automated loop where a reviewer without context feeds an agent without context. Then every comment is taken seriously, even when the original task made a decision that was never written down. That is a real risk, so keep one side in charge that knows the full story.
What can go wrong with parallel agents?
State. When I ran several subagents in parallel, some in my local directory and others in Git worktrees, I forgot to tell some of them to use a worktree. They stashed my local changes, and a few pull requests ended up containing files from my working directory. It was quite a mess.
It changed how I think about commits. I now treat them as checkpoints instead of polished milestones, and I commit before launching parallel work. Agents are good at reverting and recovering Git state, so frequent commits carry very little risk.
Conclusion
Name the model for each subagent or let your agent choose one, keep the strongest model for planning and judgment, and skip orchestration for simple tasks. Use a reviewer without context for fresh eyes, and keep a main agent with context in charge of the decisions.
To see how your own setup uses models and subagents, run the free token cleanup prompt. For the full approach, including validation, join the waitlist for the AI Fundamentals course. Feel free to contact me or tweet me on Twitter if you have any additional tips or feedback.
Thanks!