Why do I delegate code to Claude Code subagents?

My delegation system for Claude Code is a multi-agent orchestrator: Opus designs, assigns and verifies, and subagents running Sonnet or Haiku write the code, each in its own context window. I have used it since August 2026. The general method is in How I work with AI in development: my method. Here I describe the delegation system and the tokens it measures.

I started studying the problem in July, because I was burning too many tokens, and since August I have used this approach: the experiments of those weeks showed me where the tokens were going, and the study paid off. Moving to the next subscription tier seemed the wrong answer: trivial work could go to cheaper models, and the most powerful model could stay for the decisions. I also wanted the routing to happen on its own, without switching models by hand on every request.

Single agent vs multi-agent orchestrator: what changes in Claude Code?

With a single agent the main model does everything, and every file read, every attempt and every output stays in its context until the end of the session. With an orchestrator the main model splits the work, hands it to subagents with their own context and integrates the results: Anthropic calls this pattern orchestrator-workers (opens in a new tab).

A clean context matters for quality too. Anthropic calls the decline "context rot": as the number of tokens in the context grows, the model recalls the information it holds with less precision, and the loss is gradual. The chart compares the two flows on the same work.

Why does a subagent start with the right context?

When Opus delegates, Claude Code opens a fresh prompt for the subagent, and that prompt begins with the spec: goal, files to touch, constraints, verification command, shape of the report. The session history stays out. The subagent reads the files the spec points to and works on those, with a context built for the task.

This is the concept the whole system rests on. Opus writes what is needed in a spec of about 920 tokens, the median of my delegations to Sonnet, and the subagent starts from there. In a single session, instead, every new task is added on top of everything that came before.

How many tokens stay out of Opus's context window?

A turn with one delegation adds a median of 18,914 tokens to the context of Opus, review included. The same work done by Opus would add about 67,000. The first value comes from 580 turns with one delegation. The second is an estimate: a turn of Opus without delegation, a median of 5,829 tokens, plus the work of the subagent, meaning its peak context minus the roughly 13,000 tokens it starts with.

A task that comes back costs more tokens, and I count them. Among the outcomes I log after each review, 4 out of 18 are "corrected": Opus fixed the work with one more turn, a median of 5,829 tokens. Spread over all delegations, the delegated turn rises to about 20,200 tokens, and delegation saves Opus 70% of its context.

The 18,914 tokens hold everything Opus does for the delegation: it reads the files the spec needs, writes the spec, receives the report and checks the result by reading the diff and the test output. I keep the read-through review of the response on purpose, because that is where I check the work.

The subagent works with far more context than it returns. At the median, a coder-sonnet subagent worked with 85,283 tokens and returned to Opus a report of about 1,150 tokens, 74 times fewer, over 1,127 delegations with an identifiable report.

The values fall within the ones Anthropic gives for subagents (opens in a new tab): tens of thousands of tokens explored, a summary of 1,000-2,000 tokens. The tokens the subagent reads stay in the overall count. What changes is the model that reads them. A study by The Infinity (opens in a new tab) on 23,747 turns reaches the same conclusion: at equal context a token costs the same, and delegation pays off when the main context is already large.

In practice, more turns fit in the same Opus context. In the chart, auto-compact arrives after fourteen turns without delegation, and at the same point, with delegation, Opus holds about 337,000 tokens, 66% less. For me, that is the gain: for the same tokens spent by Opus, in my experience I move more work forward, and with higher quality.

A Sonnet or Haiku token costs less than an Opus token, so I look at the tokens of the different models separately and do not add them up.

How much less do I spend with Claude Code subagents?

Over the 36 measured days, spend dropped by 12 to 30%, depending on the context of the sessions, with routing tuned by type of request. The work that stays with Opus, meaning spec, review and decisions, costs the same in both cases and stays out of the count.

The 12% comes from the real cost of the 1,141 delegations to Sonnet, doubled as if Opus had done them. The rest is an estimate, because I never ran the same turns without delegation. The longer a session runs, the closer the saving gets to 30%: every token left in the context of Opus is paid for again on every call.

How much of the Opus token budget do Claude Code subagents free up?

Delegation frees up 22 to 51% of the Opus token budget: with the same budget I move 1.3 to 2 times as many turns forward. This is the figure that matters on a subscription, where usage has a limit instead of a bill.

The count adds up every token Opus processes: input, output, cache writes and cache reads. Anthropic does not publish how much each of these weighs against a plan's limit, so the percentage holds for the volume of tokens, not for the exact limit.

When does Opus reach auto-compact?

Opus 5.5 has a context window of one million tokens (opens in a new tab), and Claude Code compacts it automatically (opens in a new tab) at about 967,000 tokens, summarizing the session history. Across 135 sessions on my two machines, 16 reached auto-compact even with delegation active. A fork of the session, which inherits the whole context of its parent, started at a median of about 521,000 tokens.

Which model do I use for each Claude Code subagent?

Small mechanical code goes to Haiku, code that needs repository context to Sonnet, irreversible branches to a dedicated Opus, and Opus as orchestrator keeps architecture, review and commits. Opus decides, using observable criteria: how many files the task touches, how much repository context it needs, how reversible it is. Five design choices came out of this.

1. The rule lives in one file, once. In the global CLAUDE.md a table says which task goes to

whom, and it applies in every session without repeating it.

1. One model per type of work. Small mechanical code goes to Haiku, code that needs repository

context to Sonnet, irreversible branches to a dedicated Opus. Log summaries and texts go to a local model with Ollama, at zero cost in Claude tokens. Opus keeps architecture, edits of a few lines, review and commits. When tasks are independent, Opus launches several Sonnet subagents in parallel, each with its own context.

1. Every executor knows its limits. When a task exceeds them, the agent refuses it and sends it

up a level, instead of attempting it badly.

1. The reminder arrives in the turn. CLAUDE.md stays background context, and a hook repeats the

short rule next to every code request, where it carries the same weight as the request.

1. Every delegation leaves an outcome. Without a recorded verdict the system is judged by gut

feeling. With the outcome I can see how many delegations come back integrated as they are, corrected or redone.

How did I build the delegation system in Claude Code?

I built it with native Claude Code features: agents in ~/.claude/agents/, rules in CLAUDE.md, hooks in settings.json, plus a small command for the outcomes and a log on my server, shared by the computers on the network I work from.

One row of the rules table, as Opus reads it:

| codice con **contesto del repo**,
  coerenza multi-file,
  test da far girare
| Sonnet
| `Agent(subagent_type: "coder-sonnet")`
  con specifica precisa |

The frontmatter of the small executor, with the limit that makes it stop:

---
name: coder-haiku
description: >-
  Esecutore economico per lavoro PICCOLO e MECCANICO.
  [...] in quel caso risponde FUORI LIMITE
  e va usato coder-sonnet.
model: haiku
tools: Read, Edit, Write, Bash, Grep, Glob
---

**Se il compito esce dai limiti non lo tenti**:
la prima riga della risposta è
`FUORI LIMITE, passa a coder-sonnet: <motivo>`
e ti fermi lì (niente modifiche ai file).

The hook that brings the rule into the turn, in settings.json:

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "$HOME/.local/bin/delega-hint"
          }
        ]
      }
    ]
  }
}

And the verdict that Opus records after every review:

ai-mcp esito <agent_id> \
  ok|corretto|rifatto|fuori-limite \
  [nota]

I noticed the difference on long tasks. I often switch from one project to another, with very different and deep contexts, and before this my tasks piled up haphazardly in the same session: even working with OpenSpec, I sometimes started over from scratch to get back to a clean working state. Rereading the whole context was the only alternative, and it cost exactly the context I wanted to save. Today Opus acts as a mentor: it keeps the state of the work, assigns the pieces, checks what comes back and reviews it.

How do I check the work of the subagents?

Every delegation goes through two checks: Opus's review and the project's quality tools. Opus reads the spec it wrote, the report and the diff, reruns the tests, and only then commits. On the Drupal modules I publish on drupal.org, the code goes through phpcs with the Drupal and DrupalPractice standards, phpstan, cspell and the phpunit suite before every push.

Review is cheap because it is mostly reading. In Anthropic's price list (opens in a new tab) an Opus 5.5 output token costs five times an input token and a hundred times a token read from the cache. Over the 36 measured days the subagents wrote 77% of the characters that ended up in files. In output tokens the ratio reverses: Opus produced 39.5 million, or 74.7%, and the subagents 13.4 million, because Opus's output includes reasoning, specs, reviews and tool calls.

I wrote about how I declare the use of agents in my projects in What does the AI Act ask of developers who build software with AI agents?

How do I use the logs to tune delegation?

Every delegation leaves a trace in the log: who received it, with which spec, how many tokens it used and with which outcome. With those logs I tune the rules instead of changing them by gut feeling, and some choices in the system came from there.

• Haiku for small work. Short mechanical tasks all used to go to Sonnet. Since October they go to

Haiku, which has the same official one-million-token window, under a tight limit, a new file of at most 150 lines or a small mechanical refactoring. In my tests, within these limits, it rarely gets things wrong. In the measured sample it accounts for only two delegations so far, too few for a statistic, and the log will show whether the limit holds.

• The most powerful model only on request. Fable costs more than Opus per token, according

to the price list, so it runs only when I ask for it.

• The classifier in front of the prompt, removed. On real turns, prompts with its hint delegated

almost as often as those without it: the rules were already making the same decision.

How does my delegation system differ from model routers?

My system differs because it keeps four pieces together: routing rules by type of work, limits for each executor with escalation to the level above, a mandatory check done by the orchestrator that chose the executor, and a log of outcomes. In the official documents I read, the other tools cover only part of this.

Routers pick the model and leave the result out of the picture. Tools with a verification step, such as Aider, the Copilot coding agent (opens in a new tab) or Bugbot, entrust it to tests, linters or a second review pass, separate from whoever chose the executor.

Why did I build a delegation system instead of using a ready-made router?

I built my own to keep control of the result. A router decides the model and its responsibility ends there. I wanted whoever assigns the work to be the one who verifies it, with the spec in hand and the repository in view, and every verdict to stay on record. Claude Code already offers all the building blocks: subagents accept a model each, and the documentation (opens in a new tab) leaves the choice to whoever writes them, with no automatic difficulty criterion. The verification, instead, has to be built by whoever uses the tool.

I also tried Rizzo Flow (opens in a new tab), a local typed-decision engine, as a classifier in front of every prompt. In my context it was superfluous: I already do the classification upstream with the rules, and my contexts are well bounded, so there is little to guess about what kind of task it is. It also cost time: from its log, over 3,748 prompts since 2 October, the median delay was 1.97 seconds, with the 90th percentile at 3.75 seconds, 18 timeouts and about 150 minutes of waiting in total. My reminder hook takes about one hundredth of a second.

Does Opus always follow the delegation rule?

Opus follows the rule only in part: the reminder appeared in 533 turns, and in 149 of them Opus delegated, or 28%. The behavior is known beyond my case: in issue #42856 (opens in a new tab) of the Claude Code repository a user describes mandatory delegation rules overridden "for efficiency". The recorded outcome serves this purpose too: it shows the days when delegations drop.

Which transcripts do the delegation numbers come from?

The numbers come from 36 days of Claude Code transcripts on my two machines, from 17 September to 22 October 2026: 5,145 prompts written by me and 1,390 delegations, 1,141 of them to coder-sonnet. The tokens come from the usage fields that Claude Code writes in every transcript.

The sample covers one month because Claude Code deletes transcripts older than thirty days. Within the sample the result is stable: in each of the six weeks the report of a coder-sonnet stayed between 1,030 and 1,270 tokens at the median, and the ratio to the context never fell below 44 to 1. The structure of the delegations has been the same since August, and in my experience the result is the same in every month I have used this approach. I have recorded outcomes since October.

Sources

• Building effective agents (opens in a new tab), Anthropic, 19 December 2024. Accessed 22 October 2026.
• Effective context engineering for AI agents (opens in a new tab), Anthropic, 29 September 2025. Accessed 22 October 2026.
• Claude Code subagents (opens in a new tab), official documentation. Accessed 22 October 2026.
• Claude model pricing (opens in a new tab), Anthropic. Accessed 22 October 2026.
• The Subagent Tax, Measured: 23,747 Turns of Real Billing Data (opens in a new tab), The Infinity, 19 August 2026. Accessed 22 October 2026.
• Model overrides mandatory delegation triggers in CLAUDE.md (opens in a new tab), issue #42856. Accessed 22 October 2026.