A Token-Efficient Workflow for Coding Sub-Agents

I was reading a Hacker News discussion about sub-agents where people were talking about how quickly they burn through tokens. That made me wonder why my experience has been so different.

I use GitHub Copilot in a pretty intentional way. I start with a smaller model, usually GPT-5.4 mini with high reasoning or, more recently, GPT-5.6 Luna with low reasoning. I use that session to inspect the codebase, ask questions, and work out what actually needs to change before I hand the implementation to a stronger sub-agent.

Calling it the smaller model is relative. It is still capable. I just use it for the messy part where I am exploring options and rejecting ideas.

Once the plan feels solid, I dispatch a stronger sub-agent. That might be GPT-5.3-Codex or, more recently, GPT-5.6 Terra with high reasoning. It gets a focused plan instead of a vague request to figure everything out.

The loop is the important part

The handoff is not the end of my session. It is one step in a loop:

1. I plan in the main session.
2. I dispatch that plan to one sub-agent.
3. The sub-agent makes the changes and runs the relevant checks.
4. I review the result, verify the repository, and continue planning from there.

If the result is wrong, I tighten the plan before sending more work. I am still the one deciding what happens next.

On a full coding day, I can go through around a dozen sub-agent handoffs this way. That is not a goal or a recommendation. It is simply what I have observed in my own workflow.

Why my context stays manageable

I have also noticed that my main session does not compact as often. I cannot say exactly how GitHub Copilot packages context internally, but I can see the practical result: my main conversation receives the completed work and what I need to review it. It does not fill up with every file the sub-agent opened, every search it ran, or every intermediate step it took.

That lets me keep the decisions and the larger thread of the work in one place while the implementation effort happens elsewhere.

This is also where I think some of the token savings come from. GPT-5.4 mini handles the early exploration. The stronger model gets a narrower implementation job after much of the uncertainty is gone. Neither part is free, but the more capable model is focused on the work where I value it most.

Why others may see the opposite

If several sub-agents investigate the same bug, read the same files, and run the same tests, token use should climb. The same is true when every sub-agent starts with an open-ended request or an autonomous system keeps spawning more help.

That is a different workflow from mine. I am not launching a swarm. I am making one deliberate handoff, reviewing it, and then deciding what comes next.

My takeaway

Sub-agents are not automatically efficient, but they are not automatically a token disaster either.

For me, the useful pattern is simple: plan with a smaller model, implement with a stronger one, verify the work myself, and repeat. That is how I can use around a dozen sub-agents during a long coding day without losing control of the work or constantly compacting my main session.