The Break-Even Point of Delegation

Delegation carries a price tag denominated in a multiple. And the cost isn't a side effect of delegating — it's the mechanism itself: delegation works because it lets more tokens get poured into the problem. So the question isn't whether the work can be split, but whether it's worth paying the multiple.

Problem

Delegation decisions tend to run on instinct — the task looks big, so it gets split. But the cost of delegating jumps higher than instinct expects: one vendor's own measurement found agents typically use about 4× the tokens of a chat interaction, and multi-agent setups use about 15× (Official, Anthropic's own data, research use case; source in the Practice section). Choose delegation without weighing the multiple, and both directions go wrong: small work gets parallelized, paying only fixed cost and multiple for nothing; conversely, work that's worth paying the multiple gets crammed into a single context out of fear of the cost, and overflows.

Context

Applies when:

• Any point where delegating is a choice. Deciding whether to use Read-and-Discard Isolation or parallelization is, in substance, this pattern
• Cost (tokens, credits, latency) is an actual constraint. If spend doesn't matter, there's no motive to look for a break-even point

Does not apply when — the cases where there's no need to check the price tag:

• The work doesn't fit in a single context. The ceiling can't be bought with money, so it has to be split regardless of price
• Work where everyone needs to share the same context, or where steps have heavy dependencies on each other. Official names this territory directly as "not a good fit" (source in the Practice section) — before price even enters, splitting just doesn't work here

Break-even is a tool for when there's a choice. If only one option is available, no estimate is needed.

Boundary with neighboring patterns:

• Read-and-Discard Isolation — the structure of isolating is that pattern; its price tag is this pattern
• Matching Thinking Depth to the Task — that pattern is the price tag for how much to make it think; this pattern is the price tag for who does it. They meet at per-subagent model and depth settings (Practice section)
• Session Boundary Design — when a context is about to overflow, cutting and delegating are alternatives. The design of cutting is that pattern; the price tag of delegating is this pattern

Solution

The cost of delegating grows by the multiple; the benefit comes from asymmetry. These are two different quantities, so looking at only one always leads to a wrong call. The diagram's two lines show this. The delegate line doesn't pass through the origin — fixed costs (spin-up, writing the task, integrating the result) apply regardless of how big the work is. And its slope is steep: the multiple. So for small work, delegation is structurally more expensive. There's no crossing point to the left of break-even.

Why does delegation work at all? Official's explanation cuts against intuition — multi-agent setups work mainly because they help spend enough tokens to solve the problem, and one evaluation found token usage alone explained 80% of the performance variance (Official, Anthropic's own analysis; source in the Practice section). We tend to think of delegation as getting smarter through division of labor, but this explanation is closer to "it gets better simply because more gets poured in." Delegation isn't a mechanism for adding intelligence — it's a mechanism for stacking budget.

If cost is the mechanism itself, any estimate that treats it as a mere "side effect of delegating" has the direction backward from the start. The multiple isn't waste — it's exactly what's being bought. So the criterion narrows to one question: does this work return enough to pay for the multiple? Official itself states the condition for economic viability in exactly those terms ("the value of the task is high enough to pay for the increased performance"; source in the Practice section).

The diagram's right edge sits outside this calculus entirely. A single context's ceiling can't be bought with money. Work beyond that ceiling isn't subject to break-even analysis — it has to be split regardless of price.

The same Official source names the opposite limit too — territory where all agents need to share the same context, or where dependencies run deep, is "not a good fit," and coding has less parallelizable work than research, the same people who measured the multiple write (source in the Practice section). Cite the multiple alone and drop this qualifier, and it misleads most of this catalogue's readers, who work in coding.

Finally, this catalogue doesn't give a number for the break-even point itself — because no one has measured it. What this pattern gives is a framework for the judgment: four variables — fixed cost, multiple, asymmetry, ceiling. The means to actually see your own environment's price tag live on the tool side (Practice section).

Trade-offs

Advantages

• Exceeds a single context's ceiling. Since that ceiling can't be bought with money, this is available only through delegation. Official also names "information that exceeds single context windows" as territory where multi-agent setups excel (source in the Practice section).
• Gets parallelism and independent perspectives. Work where heavy parallelization pays off is territory Official names directly (source in the Practice section); the value of standing up multiple contexts that don't share prior history is Read-and-Discard Isolation's subject.

Costs

• The multiple. Numbers like ~4× and ~15× exist — but they're Anthropic's own measurement in a research use case, and are neither Copilot's numbers nor a general law (source in the Practice section). Copilot's own Official docs also state plainly that splitting work can increase the number of LLM interactions and raise credit consumption (Official, Copilot CLI; source in the Practice section).
• Fixed cost and integration cost. For small work, delegation reliably costs more. And integration includes verifying the delegate's output — how to structure that verification is another pattern's subject (Separating Mechanical Gates from Semantic Gates).

GitHub Copilot in Practice

Copilot isn't a single product. And the central numbers behind this pattern aren't even Copilot's — they're another vendor's own measurement. This section places that measurement as a measurement, with its limits stated, alongside what Copilot's own Official docs say about cost, surface by surface.

Where the multiple comes from — Anthropic's own measurement (cited as another vendor's data)

Source: Anthropic — Multi-agent research system (retrieved 2026-07-16) Official (Anthropic's own measurement):

There is a downside: in practice, these architectures burn through tokens fast. In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats. For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance.

Agents use about 4× the tokens of chat, multi-agent about 15×, and it's economically viable only when the task's value matches the added performance — a sentence that carries the meaning behind the name "break-even."

What these numbers actually cover

The source text says "in our data" — this is Anthropic's own data, describing a research-use-case system. It is not Copilot's numbers. It is not a general law. This page uses the multiple only as a concrete instance of the structure "delegation's cost can jump by a multiple." Your own environment's multiple can only be seen by yourself, using the means described later.

The same source explains why it works, from the cost side, too Official:

Multi-agent systems work mainly because they help spend enough tokens to solve the problem. In our analysis, three factors explained 95% of the performance variance in the BrowseComp evaluation ... We found that token usage by itself explains 80% of the variance, with the number of tool calls and the model choice as the two other explanatory factors.

Token usage alone explains 80% of the performance variance, per this analysis. The core claim in Solution — cost isn't a side effect, it's the mechanism itself — comes from here.

The territory where it doesn't apply is named directly too Official:

Further, some domains that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today. For instance, most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time. We've found that multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools.

Most coding tasks involve fewer truly parallelizable tasks than research — written by the same people who measured the multiple. Most of this catalogue's readers work in coding, and this sentence can't be dropped while citing only the multiple. What suits multi-agent work is high-value tasks involving heavy parallelization, information exceeding a single context window, and interfacing with numerous complex tools.

Copilot CLI — the price tag is written in "number of interactions"

Source: Running tasks in parallel with the /fleet command (retrieved 2026-07-16) Official:

GitHub AI Credits usage: When you submit a prompt in the CLI and Copilot interacts with the selected large language model (LLM) to generate a response, this consumes GitHub AI Credits. More interactions with the LLM result in a higher consumption of GitHub AI Credits.

Each subagent can interact with the LLM independently of the main agent, so splitting work up into smaller tasks that are run by subagents may result in more LLM interactions than if the work was handled by the main agent. Using /fleet in a prompt may therefore cause more GitHub AI Credits to be consumed.

The Official docs of the vendor providing the delegation mechanism itself state plainly that splitting can increase consumption. But the framing differs — Anthropic writes in terms of the token multiple; Copilot CLI writes in terms of the number of LLM interactions. Different vendor, different surface — the multiple shouldn't be transplanted across — but the direction is the same.

VS Code — the general form of cost, and how to see your own price tag

Source: Language models (Agents concepts) (retrieved 2026-07-16) Official:

Different models consume AI credits at different rates, based on the model and the number of tokens processed. More capable models cost more per token, while lighter models extend your usage further.

The general form of cost is per-model price × tokens processed. Both Anthropic's multiple (more tokens) and the CLI's count (more interactions) reduce to this: a path where processed tokens go up.

Delegation's price tag can actually be seen (source: Subagents in Visual Studio Code, retrieved 2026-07-16) Official:

Hover over a subagent section in the chat response to see the AI credits used by that subagent. This gives you more transparency into the cost of delegated work.

Credit consumption can be checked per subagent. There are also means to check per request and per session (source: Optimize your AI usage, retrieved 2026-07-16) Official:

To view the cost for a single request, hover over the chat response to see the credit consumption for that turn.

To view the cumulative cost and token breakdown for the entire session, hover over or select the context window control in the chat input.

As stated at the end of Solution, no one gives a number for the break-even point. Your own environment's break-even point can only be drawn by seeing your own price tag through these means.

Designing delegation's unit price — a force pulling against the multiple

Source: the Optimize your AI usage page above Official:

Use custom agents with a preferred model to route specific subtasks to specialized, cost-effective models. When you invoke a custom agent as a subagent, it uses its own configured model instead of the chat session's model.

If the multiple is a force that raises cost, this is a force that lowers it — the delegate uses whatever model was configured for it, so specific subtasks can be routed to a cheaper model ahead of time. Delegation isn't just a lever for "more volume" — it's also a lever for "choosing the unit price," and the break-even estimate becomes three-dimensional once both are in the picture.

Not "low-cost by default"

An early draft note in this catalogue claimed subagents use a low-cost model by default. What could be confirmed from the primary source is only the verbatim quote above — its own configured model — and what happens by default hasn't been confirmed, so it isn't written here. It gets cheaper only if a cheap model is configured.

In Copilot CLI, this unit-price design can be written as a per-agent setting (source: CLI config dir reference, retrieved 2026-07-16) Official:

| subagents.agents | object | {} | Per-agent model configuration, keyed by agent name. Each value is an object with optional model (string), effortLevel (string), and contextTier ("default", "long_context", or "inherit") fields. Set any field to "inherit" to use the parent session's value at dispatch time. … |

Not just the model, but thinking depth (effortLevel) too can be specified per agent. This is where the price tag for who does it (this pattern) and the price tag for how much to make it think (Matching Thinking Depth to the Task) cross, in the same setting.

Source and surface, cross-referenced

Source / surface	What Official says about cost
Anthropic (own measurement, research use case)	Agent ~4×, multi-agent ~15×. Viability requires the task's value to match the added performance
Copilot CLI	Splitting can increase the number of LLM interactions and raise AI credit consumption
VS Code	Cost = per-model price × tokens processed. Consumption can be checked per subagent, per request, and per session. The delegate's model can be chosen via configuration

The three don't contradict each other — each describes, from a different angle, a path where processed tokens increase (or the unit price changes). But each statement is accurate only within its own source and surface.

Also Known As

Name	Source
The Break-Even Point of Delegation	Descriptive — this catalogue's descriptive name; no primary source uses it

The mechanism of delegating has primary names — Subagent, custom agent (both Primary; see Read-and-Discard Isolation's Also Known As section). The means of seeing consumption also has official documentation (Practice section). But the judgment of "how much delegation is worth it" has, as far as could be confirmed, no established name. The tools give the means to delegate and the means to see the price tag — they don't say how much is worth paying. A descriptive name is given to the judgment side, not the mechanism.

Related

• Read-and-Discard Isolation — the structure of whether to isolate is that pattern; how much isolating costs is this pattern. This pattern gives shape — a multiple and a fixed cost — to that pattern's cost of "crossing the boundary costs something in both directions"
• Matching Thinking Depth to the Task — that pattern is the price tag for how much to make it think; this pattern is the price tag for who does it. They meet at per-subagent model and depth settings (Practice section)
• Session Boundary Design — when a context is about to overflow, cutting and delegating are alternatives. Cutting loses context; delegating pays the multiple and the fixed cost
• Separating Mechanical Gates from Semantic Gates — what delegation's integration cost consists of is verification. How to check the delegate's output — splitting what a machine can judge from what needs human judgment — is that pattern
• If reading just one more next: Matching Thinking Depth to the Task — having seen delegation's price tag, it's next to look at thinking's price tag