Lean orchestration: five rules from the bill of a multi-agent run

On my last multi-agent development run, more than a quarter of the cost went to writing the same context into caches, again and again. The run cost about $3,450. An orchestrator dispatched hundreds of subagents to implement, test and review code, on Claude Opus 5.5 and Claude Fable. When I took the bill apart, the largest avoidable items had nothing to do with the intelligence of the models.

• 464 subagent caches expired and were rewritten, at about 200,000 tokens each: $653, 19% of the cost.
• 462 new agents each wrote a starting context of about 90,000 tokens: $277, 8%.
• Output tokens, the most expensive on the price list, made up 20%.
• The orchestrator itself cost $450, 13%, for 5,149 responses.

From that bill I drew five rules. None of them needs a better model: they govern how long an agent waits, how many agents are born, what they read, what they write back, and how large the orchestrator grows. The price war article ended on the cost of a case file processed end to end; this one opens up one of its factors, orchestration, on a real bill.

1. Where the money went

Read item by item, the bill shows that an agent run spends more on rewriting context it already had than on any single piece of reasoning.

• A cache write costs 1.25 times the input price for a five-minute cache, and a cache read costs 0.05 times on Opus 5.5 [1]. Writing a context therefore costs 25 times as much as reading it back.
• Expiries and first calls of new agents together took 27% of the cost. The run kept paying to put back into caches what it had already processed.
• Output, at 20%, is the other large item. On Fable it is billed $50 per million tokens [1].
• The orchestrator, at 13%, is the success story: 5,149 responses at an average of $0.087 each (see Figure 1).

The waste was in the timing.

2. Rule 1: no subagent tool call longer than four minutes

A subagent’s cache lives five minutes, and the clock keeps running while the subagent waits for a tool to return.

• Claude Code requests a one-hour cache for the main conversation on a Claude subscription within plan usage, and five minutes for subagents in every case [2].
• The lifetime runs from the start of the request, generation included: “if a response takes 4 minutes to stream, a follow-up request that reuses the same cached prefix must start within about 1 minute of that response completing” [3].
• The Bash tool, meanwhile, lets a command run for up to ten minutes by default [4]. The harness allows a wait twice as long as the cache it waits with.
• A test suite that blocks for six minutes in the foreground therefore makes the next request rewrite the whole context at the cache-write price.

On the run, this happened 464 times, and nearly always for the same reason.

• Each expiry forced a rewrite of about 200,000 tokens: $1.00 on Opus 5.5 at $5 per million, $2.50 on Fable at $12.50 [1]. The average, $1.41, sits between the two.
• 85% of the expiries came right after a test run or a wait on its lock, about 394 of them.
• Hence the rule: start long suites in the background, then wait in timeout 240 slices. Each slice reads the cache before it expires, for about $0.04 on Opus 5.5 and $0.05 on Fable 5.1 [1].

The arithmetic is lopsided, and more so on the most expensive model (see Figure 2).

• On Opus 5.5, one rewrite pays for 25 slices, 100 minutes of waiting with a warm cache.
• On Fable 5.1, it pays for 50 slices, 200 minutes, because cache reads there are billed at 0.025 times the input price against 0.05 on Opus 5.5 [1].
• A 12-minute suite costs $0.12 in slices on Opus 5.5, against $1.00 for a blocking wait.

The rule has two limits worth writing into the harness itself.

• Slices need a ceiling. A lock that never frees would buy slices indefinitely; after a fixed number, five for instance, the subagent should report the lock to the orchestrator instead of waiting on.
• A one-hour cache is now an option for subagents, through the subagentPromptCacheTtl setting since Claude Code 2.1.242, or an experimental cacheTtl per agent since 2.1.248 [2]. A one-hour write costs twice the input price against 1.25 times [1], a premium of about $0.60 for a subagent that writes 200,000 tokens over its life on Opus 5.5. It pays for implementers that run long suites, and wastes money on short reviewers.

Slices cost nothing extra. They stay the rule.

3. Rule 2: spawn fewer agents and reuse warm ones

Every new agent pays full price for its first request, and a run that spawns hundreds of agents pays that price hundreds of times.

• A subagent’s first request does not read the parent’s cache, because its system prompt and tools differ, so it builds a cache of its own [2]. That starting context carries its system prompt, its tool definitions, the project’s CLAUDE.md files and the task [5].
• On the run, that first call wrote about 90,000 tokens per agent: $277 over 462 agents, 8% of the cost, about $0.60 each. At list prices, 90,000 written tokens cost $0.45 on Opus 5.5 and $1.13 on Fable [1].
• A warm agent reads the same prefix for $0.018 on Opus 5.5, 25 times less [1].
• Claude Code resumes a finished subagent when it receives a message through SendMessage, without a new invocation [5]. After less than five minutes of idleness, its cache is still warm.
• Small reviews grouped in one agent pay for one first call instead of five.
• Claude Code’s own documentation puts agent teams at about 7 times the tokens of a standard session when teammates run in plan mode, since each one keeps its own context [6].

Reuse has a cost of its own, which is why it stays within one thread of work.

• A reused agent carries the previous task with it: its assumptions, the leads it abandoned, the files it read. On the next step of the same work, that history helps. On an unrelated task, it gets in the way.
• Its context also keeps growing, and every later turn reads it again.
• Claude Code’s forks sit at the other end: they share the main session’s system prompt, tools and cache, so their first request is cheap, but they inherit the whole conversation [5]. They suit tasks that need that context, which is rarely the case for a verifier.
• The one agent never to reuse is the implementer as its own verifier, for the reasons of rule 3.

4. Rule 3: limit what enters a context

Whatever enters a context is paid again on every turn that follows, so the cheapest token is the one that never gets in.

• In agentic coding, input drives the cost. A study of eight frontier models on SWE-bench Verified found agentic tasks consuming about 1,000 times more tokens than code chat, “with input tokens rather than output tokens driving the overall cost” [7].
• The rule: read with grep -n to find the lines, then sed -n to print them, never a whole file above 300 lines, and filter test output to 60 lines.
• Most tool output is noise. Squeez, a small model trained to prune the tool output of coding agents, removes 92% of input tokens while keeping a recall of 0.86 on the relevant evidence [8].
• The same figure marks the limit: 14% of the relevant evidence is missed. The full log stays on disk, and the agent reads further with sed -n when 60 lines do not explain the failure.
• Long contexts also degrade the work itself. On four flagship models running long search tasks, the rate at which they give up well before exhausting their context rises with its length [9].

The implementer stops once its targeted tests pass, and a fresh agent does the verification.

• Models grade their own work too kindly. On LiveCodeBench, “among rubrics where generators fail, judges can be more than 50% more likely to incorrectly mark them as satisfied when the output is their own” [10].
• By the time its tests pass, the implementer’s context is full of failed attempts and command output. Running the full verification there costs more and sees less.
• A fresh verifier starts from the diff and the plan, in a context a fraction of the size.

The author is the kindest reviewer.

5. Rule 4: limit what comes out

Output is the most expensive token on the price list, and it made up a fifth of the run’s cost.

• Fable 5.1 bills output at $50 per million tokens: 2.5 times Opus 5.5 at $20, and 5 times Sonnet 5 at $10 [1].
• On Fable 5.1, one output token costs as much as 200 cached input tokens, $50 against $0.25 per million [1]. On Opus 5.5 the ratio is 100.
• A subagent’s report is paid twice: once as output, then as input on every later turn of the orchestrator, whose conversation it joins [2].
• The rule follows: reports carry the verdict, the deltas and the proofs (the command run and its result), nothing else. Reviewers receive one diff plus the plan, and answer briefly.

Brevity applies to the report, while the reasoning keeps its budget.

• Thinking tokens are billed as output: the API reports “how many of the billed output tokens were internal reasoning” [11].
• A shorter report does not make a shorter review. The effort setting decides that, and a reviewer on a risky diff needs it high.
• What goes is the prose around the verdict: a summary of the task, the plan restated, the courtesies.

Nobody reads the courtesies. Everyone pays for them.

6. Rule 5: a small orchestrator that never polls

The orchestrator reads its whole context again on every response, so its size multiplies the cost of each of its thousands of turns.

• On the run, it answered 5,149 times for $450, 13% of the cost, about $0.087 per response.
• On Opus 5.5, reading 300,000 cached tokens costs $0.06 per response; at 900,000 tokens, $0.18 [1].
• Claude Code auto-compacts million-token models at about 967,000 tokens by default [12]. I set the threshold between 300,000 and 400,000 tokens depending on the workflow, with /autocompact, which accepts any window from 100,000 tokens to 1 million, or with CLAUDE_CODE_AUTO_COMPACT_WINDOW [12].

The journal is written before compacting, because compaction loses instructions.

• A 2026 benchmark found that current compactors keep only 17% of the constraints a user sets during a session, and that most do worse than no compaction at all. An extractor running alongside the compactor brings retention above 90% [13].
• The journal plays that role: decisions taken, work done, work left, standing constraints, written to disk and read back after compaction.
• It is the same discipline as the plans and journals that took over from Git in our roadmap-driven workflow.

The orchestrator also waits without looking.

• One background waiter per long process. A command started with run_in_background keeps running while the agent works on [4], and the harness wakes the agent when it exits.
• No Monitor. The tool feeds “each output line back to Claude” [4], and each line that arrives is one more turn of the orchestrator.
• No interim peeks either. At 300,000 tokens on Opus 5.5, checking a 12-minute suite every 30 seconds costs 24 responses, $1.44, where the exit notice costs one, $0.06.

The orchestrator does not need the most expensive model either, because most of its cost is re-reading its own context, and two models released at the end of September halve that price.

• Claude Sonnet 5.5, released on 28 September 2026, costs exactly half of Opus 5.5 on every line of the price list: $2 per million input tokens, $10 for output, $0.10 for a cache read [1] [14]. At 300,000 cached tokens, the context of one response costs $0.03 instead of $0.06.
• OpenAI’s GPT-6.1 Sol, released the next day, has the same list prices up to 272,000 input tokens: $2, $0.10 cached, $10 for output [15]. Above that, “prompts with more than 272K input tokens are priced at 2x input and cache rates and 1.5x output for the full request” [16]. A Sol orchestrator should therefore be compacted below 272,000 tokens, under my usual threshold.
• Both accept the xhigh effort level [12] [16].

The effort setting travels down the tree, so it is chosen once, at the top, and lowered where it is not needed.

• In Claude Code, the effort field of a subagent “Overrides the session effort level” [5]: without it, the subagent runs at the session’s level. In a session set to xhigh, a Sonnet 5.5 subagent started without an effort setting reported xhigh, where Claude Code’s default for that model is medium [12].
• Codex writes it plainly: “If you don’t configure a subagent model or model_reasoning_effort, the subagent inherits the parent agent’s model and reasoning effort” [17]. One trap: a spawn that picks another model without an effort gets that model’s default effort.
• Hence my recommendation for long runs: Sonnet 5.5 at xhigh, or GPT-6.1 Sol at xhigh, for the session, and the whole tree works at that level by default.
• Thinking tokens are billed as output [11]. Small reviewers get a lower level through their effort field, or through the per-invocation parameter, which “requires Claude Code v2.1.292 or later” [5].

Anthropic is more cautious about the top of the tree, and its caution sets the condition under which a mid-tier orchestrator holds.

• Its own launch post says that “Opus 5.5 remains clearly stronger at complex, open-ended work requiring sustained judgment” [14].
• The saving also narrows with effort: Sonnet 5.5 “complements Opus 5.5 best when running at lower effort settings”, and at higher settings “it can perform comparably at a similar cost” [14]. At xhigh, the saving comes from reading the context.
• The orchestrator configuration Anthropic has measured puts the frontier model in charge: “the frontier model holds the loop” and dispatches subtasks to cheaper worker models [18].
• The condition is the method. On a project run in a strict UltraCoding development flow, with traceable critical review, tests on three layers and explicit release gates, the judgement sits in the process, and Sonnet can be enough. Without that discipline, the frontier model stays at the top.

The process carries the judgement.

Figure 3 places the five rules on the shape of the run.

The price of waiting

What these five rules have in common is that they put a price on the time an agent spends waiting, reading and talking, which no model benchmark ever shows. On the next run, I track four numbers rather than one bill.

• Expiries per agent, and what came just before each one.
• First calls per task delivered.
• The share of output by role: orchestrator, implementers, reviewers.
• The orchestrator’s context size at each response.

The thresholds in the rules (four minutes, 300 lines, 60 lines, 300,000 tokens) are mine, and they will move with prices and tools. The mechanism will stay: a cache that expires on a clock, a context paid again on every turn, an output token worth a hundred cached ones.

An orchestrator’s first job is to wait well.

The figures come from my own logs of a single run, not from a benchmark; the total is implied by the shares, and the shares overlap where output tokens are concerned. Unit costs are computed on Anthropic list prices read on 27 September 2026, for Opus 5.5 and Fable 5.1 and a context of 200,000 tokens, without the few hundred tokens each slice adds. Claude Code behaviours are those documented on the same date. The section on the orchestrator’s model, added on 11 October 2026, uses prices read that day: Anthropic’s Sonnet 5.5 launch post gives $0.20 for cache reads, where the pricing page used here gives $0.10.

Sources

1. Anthropic, Pricing, Claude Developer Platform documentation, read on 27 September and 11 October 2026.
2. Anthropic, How Claude Code uses prompt caching, Claude Code documentation, read on 27 September 2026.
3. Anthropic, Prompt caching, Claude Developer Platform documentation, read on 27 September 2026.
4. Anthropic, Tools reference, Claude Code documentation, read on 27 September 2026.
5. Anthropic, Create custom subagents, Claude Code documentation, read on 27 September and 11 October 2026.
6. Anthropic, Manage costs effectively, Claude Code documentation, read on 27 September 2026.
7. Longju Bai, Zhemin Huang, Xingyao Wang, Jiao Sun, Rada Mihalcea, Erik Brynjolfsson, Alex Pentland and Jiaxin Pei, ‘How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks’, arXiv:2604.22750, 24 April 2026, revised 29 April 2026.
8. Ádám Kovács, ‘Squeez: Task-Conditioned Tool-Output Pruning for Coding Agents’, arXiv:2604.04979, 4 April 2026.
9. Shijie Xia, Yikun Wang, Zhen Huang and Pengfei Liu, ‘Diagnosing and Mitigating Context Rot in Long-horizon Search’, arXiv:2606.29718, 29 June 2026, revised 4 August 2026.
10. José Pombal, Ricardo Rei and André F. T. Martins, ‘Self-Preference Bias in Rubric-Based Evaluation of Large Language Models’, arXiv:2604.06996, 8 April 2026, revised 3 August 2026.
11. Anthropic, Extended thinking, Claude Developer Platform documentation, read on 27 September 2026.
12. Anthropic, Model configuration, Claude Code documentation, read on 27 September and 11 October 2026.
13. Zhiqi Wang, Yichi Zhang, Dongwon Lee and Yuchen Yang, ‘Lost in Compaction: Evaluating Side-Constraint Loss under Context Compaction’, arXiv:2608.11242, 31 July 2026.
14. Anthropic, Introducing Claude Sonnet 5.5, 28 September 2026.
15. OpenAI, Changelog, OpenAI API documentation, entry of 29 September 2026 releasing GPT-6.1 Sol.
16. OpenAI, GPT-6.1 Sol, OpenAI API documentation, read on 11 October 2026.
17. OpenAI, Subagents, Codex documentation, read on 11 October 2026.
18. Anthropic, Optimizing for cost and intelligence, Claude Developer Platform documentation, read on 11 October 2026.