New tasks process is a mess in my opinion. they take 3 to 4 times the time taken for the same task in main agent. it burns token, nor verified but a feeling as the time taken for same tasks in sub agent is so long compared to main agent.
Its not funny but even if the main agent is free, some commands go into sub agents and they get into their loopy work.
I am giving instruction now every time with every prompt that it needs to be built in main agent. and its frustrating. I even wrote to support to send this to product team. I think if there is a toggle in setting asking us to approve use of sub agent or shut it down it will help. if someone needs it they can activate it else shut it down.
Your instinct about the token burn is right, and there’s a structural reason for it rather than it just being slower.
A sub-agent starts without your main session’s context. Before it does anything useful it has to re-read the project to work out what it’s looking at, and that read is billed. On a task the main agent could have done immediately because it already had the context loaded, you pay for the rediscovery first. That’s also why the loops happen. When the sub-agent doesn’t find enough to be sure, it guesses, checks, guesses again. Three or four times the duration for the same task is exactly what that looks like from the outside.
So sub-agents are worth it only when the task is genuinely separable and long enough that the setup cost amortises. For a small edit inside code the main agent already understands, it’s pure overhead, which matches what you’re seeing.
Until there’s a toggle, what tends to work better than repeating the instruction is making the task explicitly small and scoped in the prompt, since what pushes work into a sub-agent is the task looking large or parallelisable. Have you noticed whether it’s a particular kind of request that gets handed off, or does it look arbitrary?