Answer
When are subagents a waste of tokens?
When the task is small, when the brief costs as much as the work, or when the result must be re-derived anyway.
When the brief costs about as much as the task, when the subagent needs most of the main context to do it, or when its answer must be re-derived before anyone will act on it. All three are common.
The first waste is the small task. Delegation has a fixed overhead — writing the brief, starting a run, returning and interpreting a result — and below a certain size the overhead exceeds the work. Searching for a single string, reading one file, checking one value: all of these are cheaper inline, and the version with a subagent is slower as well as more expensive.
The second is the context-hungry task. If the delegated run needs the project instructions, the decisions so far, the constraints and the material to do its job, most of the main context is being duplicated into a second run. The token saving was the entire justification, and it has disappeared. This is the case that looks like good structure and is not, and it is worth checking before delegating anything that depends on the situation rather than on a self-contained question.
The third is the unverifiable result. If the returned answer cannot be acted on without checking, and checking means reading what the subagent read, then the work was done twice and the delegation produced only latency. This is the most common failure in practice, and it is usually caused by a brief that specified an output format but not an evidence requirement.
The fourth is speculative parallelism: running several subagents on variations of the same question in the hope that one produces something useful. This is occasionally a legitimate technique and is more often an expensive way to avoid deciding what the question is. The cost is multiplied by the number of runs and the output still requires someone to choose between the results, which is the work that was being avoided.
There is a fifth that is easy to miss because it looks like thoroughness: delegating a task the main run has already done most of. Partway through a job, the remaining piece often looks like a discrete unit and is not, because the main run holds the intermediate state. Handing it over means re-establishing that state in a second run, and the second run does it worse.
The general test is whether the delegation removes more from the main context than it costs to set up. That is a comparison anyone can make in a few seconds before delegating, and it disposes of all five cases above. Where the answer is unclear, inline is the cheaper default, because the failure mode of not delegating is a somewhat larger context and the failure mode of delegating badly is duplicated work with a lossy summary in between.
A subagent that has to be told everything the main run knows has not divided the work, it has copied it.
Siddharth Sharma, Context Theory
Related questions
Is it cheaper to run one large agent or several small ones?
It depends entirely on whether the small ones need the same context. Genuinely independent pieces with self-contained briefs are cheaper divided, because each run holds only what it needs. Pieces that each require the shared situation are more expensive divided, because the shared situation is paid for once per run instead of once.
Do subagents improve quality even when they cost more?
Sometimes, and for a specific reason: a run with a clean context focused on one question is less diluted than the same question asked inside a long session. Where that is why you are delegating, it is a legitimate trade and worth being explicit about, because it is a different justification from token saving and applies in different cases.
METHOD
Every figure below carries its source and the date it was verified. Nothing on this page is asserted.
The numbers on this page.
| What | Value | Specific to |
|---|---|---|
| Sub-15-minute compliance — automated routing vs manual only | 62.5% vs 39.1% | Category-wide |
| Odds of qualifying a lead — replying within the first hour vs after it | 7× | Category-wide |
2026 speed-to-lead benchmark · verified
Oldroyd, McElheran & Elkington, "The Short Life of Online Sales Leads", Harvard Business Review (March 2011) · 1.25M inbound leads across 2,241 US firms · verified
What is specific to this page.
| Kind | Claim | Check it against |
|---|---|---|
| Buying behaviour | Delegation carries a fixed overhead in brief writing, run initiation and result interpretation, so tasks below a certain size cost more and take longer delegated than performed inline. | Comparing total tokens and elapsed time for a single-file lookup performed inline and via a delegated run. |
| Workflow | A delegated task requiring the project instructions, prior decisions and shared constraints duplicates most of the main context into a second run, which removes the token saving that justified the delegation. | Listing what the subagent's brief must contain and comparing it against the main run's standing context. |
| Response | A returned result that cannot be acted on without re-reading what the subagent read means the work was performed twice, and this is usually caused by a brief specifying an output format without an evidence requirement. | Checking whether the returned answer contains references sufficient to spot-check it. |
| Software | Delegating the remaining portion of a task in progress requires re-establishing intermediate state that the main run already holds, so the apparent discreteness of the remaining piece is an artefact of the main run's own context. | Writing the brief for the remaining piece and counting what has to be restated from work already done. |
Each row would be wrong on another industry's page. Where a sourced figure exists it is in the table above instead; these are the constraints that shape the work and do not happen to be numbers.
Start with the measurement.
Reading about a benchmark is not the same as knowing your own number. The audit produces yours, measured rather than estimated.
$497 · delivered in 5 business days · credited against month one