What agents say to each other is billed twice

Delegation has a fixed cost that is not the work. The brief an orchestrator writes for a worker and the summary the worker writes back are both model output on one side and model input on the other, so a single handoff is billed four times before anyone has done anything with the result. The returned summary then joins the orchestrator's message history and is re-sent on every remaining turn of the run. That overhead scales with the number of workers and with how early the handoff happened — not with how hard the task was.

Three Hacker News items in the week to 2026-11-04 argue about multi-agent orchestration from different directions and disagree about whether it is worth doing. None of them disagrees that the coordination itself costs tokens.

LLM orchestration is the work plus the messages about the work

LLM orchestration is the pattern where one model call plans a task, hands parts of it to other model calls, and reassembles what comes back. Its cost is the work plus the messages that coordinate the work, and the second part is the one that has no equivalent in a single-agent loop.

A commenter in a Hacker News thread on 2026-11-02 about one vendor's internal model spend states the overhead as the dominant term:

Human in the loop is 1/5th the token usage vs fully autonomous agents. Agents swarming will 5x your usage, or worse. The communication overhead of summarizing and status reporting between workers will eat up tokens faster than doing the work will.

The two ratios there are a practitioner's estimate, not a published measurement, and the comment does not say what they were measured on. The structural claim underneath them is the part you can check against your own runs, and it is specific: the summarizing and the status reporting are themselves billed.

A handoff crosses the billing boundary twice in each direction

Follow one round trip through the price table rather than through the call graph.

The orchestrator writes the brief. Those are output tokens on the orchestrator's model, at that model's output rate. The worker reads the brief. The same bytes are now input tokens on the worker's model, at that model's input rate. The worker does the task — this is the only part of the round trip that is the task — and then writes a summary, billed as output at the worker. The orchestrator reads the summary, billed as input at the orchestrator.

Four billed quantities, one of which is the work. Coordination text is disproportionately model output — a brief and a summary are both things a model generates rather than reads — so where your provider prices output above input, check which rate the coordination is landing on. The asymmetry matters for a second reason, which is that the two ends are usually different models. A plan written by an expensive orchestrator and read by a cheap worker prices differently from a result written by a cheap worker and read by the expensive orchestrator, and only the second direction puts worker output onto the orchestrator's bill.

The summary is then re-sent for the rest of the run

The returned summary does not arrive and get consumed. It lands in the orchestrator's message history, and under a full-transcript re-send policy it goes back to the provider on every subsequent orchestrator turn. The cost of a handoff is therefore its payload multiplied by the orchestrator turns remaining after it, which makes an identical delegation at turn 3 of a 40-turn run a different line item from the same delegation at turn 38.

This is the same mechanism as a tool catalog billed on every turn, in a block that grows during the run instead of being fixed at startup. If the orchestrator's prefix caches, the re-send is charged at the cache-read rate rather than the base input rate from the second turn onward, which lowers the per-turn charge without removing it — and that only holds while nothing earlier in the transcript changes, which is exactly what a compaction does.

The summary exists in the first place because the worker's own transcript does not come back. That is usually the point: isolating a sub-agent isolates its spend and keeps the parent's context short. The summary is the compression, and the compression is a billed model call producing billed tokens that are then billed again on every turn that follows.

A human reading a status report reads it for free

The first quote's comparison is worth separating out from its arithmetic. When a person reads a worker's status report, the read costs nothing in tokens and leaves nothing behind. When an orchestrator reads it, the read is priced input and the report stays in the context window.

Removing the human from the loop does not remove the review step. It converts a free, non-recurring read into a billed, recurring one. That is a reasonable trade to make deliberately — it buys unattended operation — but it is a cost change that arrives disguised as a staffing change.

The overhead is paid at dispatch, before anyone knows it helped

The counter-position was argued in the same week. A commenter on 2026-11-02, in a thread on hitting chat usage limits, puts it bluntly:

Multi-agent is mostly dead. One big agent loop running GPT6.1 absolutely dominates any weird ideas like this now.

That is a claim about quality, and it is contested. A developer describing an overnight rewrite on 2026-11-03 reports the opposite practice, having escalated from a single agent to several running in parallel:

It worked all night long - hitting the usage limit, resetting, continuing - adding more and more mechanics and content.

Whichever side is right about output quality, the coordination tokens are spent at dispatch. The brief is written, the summary comes back, and the transcript grows whether or not the fan-out produced a better answer than one loop would have. That is the cost half of multi-agent amplification: the multiplier is charged up front and the improvement is not guaranteed.

What to record

1. Inter-agent message tokens per run, as their own line — tokens that are neither tool results nor the client-visible answer. If coordination cannot be separated from work in your figures, the question of whether delegation paid for itself is unanswerable.
2. Billed calls that produce no client-visible artefact. Planning turns, status aggregation and final synthesis are real calls with no deliverable attached to them.
3. The turn index each delegation fired on. The payload is only half the cost; the orchestrator turns remaining after it are the other half.
4. Coordination tokens per completed task at one worker versus the number you actually run, since running several copies at once also changes what each individual call costs.
5. Direction, kept separate. Brief-down is output at the parent and input at the worker; summary-up is the reverse. Collapsing them into one "coordination" total hides which end to make cheaper.

How this works in Capsera, and what it does not do

Capsera captures at the provider client, not at your call sites. capsera.init() patches the clients — Anthropic messages, OpenAI chat completions, OpenAI embeddings and Google Gemini, sync and async — so a call an orchestrator library issues on your behalf is recorded like any other, with input, output and cache token counts kept separate. That separation is what makes the two halves of a handoff legible: the summary's output tokens sit on the worker's row and its input tokens sit on the orchestrator's.

@capsera.agent(name="planner") adds who, not whether. Because the agent stack is a contextvars ContextVar rather than thread-local state, a worker invoked inside a decorated orchestrator inherits the identity and reports as itself under its parent, per thread and per asyncio task, with nothing threaded through the call signature. Budgets are checked before the provider call and scoped per agent, per team or globally, which bounds a fan-out width that nobody reviewed.

Two limits, stated plainly. Capsera stores hashes and token counts, never prompt or completion content, so it can tell you a call was large and when it happened but not that those bytes were a status report — you read that from which agent issued the call and at which turn. And Capsera runs in-process: a worker executing in a separate process or on another machine needs its own init(), and cost per run across that boundary depends on the run identifier being minted above the delegation point.

Where to go instead. If what you need is the text of the brief and the summary themselves — the content, to judge whether the coordination was any good — Langfuse is open source, free, and built to store and inspect exactly that; Capsera is not, by design. If your workers reach providers through a gateway and you want hard spend limits per key, team, organisation or model across many providers, LiteLLM is MIT-licensed, free, and enforces budgets at those scopes.