2.1.x · macOSWhere the tokens actually go#
Two things surprised me when I looked at my consumption honestly.
First, the main conversation loop is the expensive part. Every turn re-reads the accumulated history, so a long-running session pays for its own past on every message, cached or not. Keeping that loop on a top-tier model means the priciest per-token rate multiplies against the largest token base.
Second, mechanical work is indifferent to model quality. A task like “run this experiment exactly as specified and capture the outputs” or “check these eight criteria and report PASS or FAIL” produces the same result from a mid-tier model as from a flagship. I checked, repeatedly, because the whole scheme depends on it. The delta shows up in judgment tasks: design, debugging, writing. It does not show up in checklists.
When I set this up in July 2026, the list prices told the story: the flagship tier cost ten times the cheapest tier per output token, with the mid-tier around a third. Current numbers live on Anthropic’s pricing page; the ratios are the durable part.
The mechanism: subagents carry their own model#
Claude Code lets you define custom subagents as markdown files in ~/.claude/agents/. The frontmatter takes a model field, and that is the entire trick. The main loop stays on the expensive model for orchestration and judgment; anything delegated to one of these agents runs on the model named in its file, in its own separate context window.
I defined three:
| Agent | Model tier | Job |
|---|---|---|
| bulk-worker | mid | Fully specified mechanical work: batch edits, scripted experiments, boilerplate |
| scout | mid | Read-heavy reconnaissance that returns conclusions, not file dumps |
| verifier | cheapest | Checklist verification, grading, link checking, lint triage |
The bulk-worker definition, in full, because the shape matters more than the words:
---
name: bulk-worker
description: >-
Use for well-specified mechanical work that needs no deep judgment:
applying a known edit pattern across many files, batch renames,
frontmatter updates, formatting fixes, writing boilerplate or config
from a clear spec, converting data between formats. The task must be
fully specified by the prompt; if it requires design decisions or
debugging, use the main loop or a stronger agent instead.
model: sonnet
---
You are a mechanical execution agent. You receive a fully specified task
and carry it out exactly as described.The description field does double duty. It documents the agent for me, and it is what the orchestrating model reads when deciding whether to delegate, so the “use for X, not for Y” boundary goes right there.
The second benefit took me longer to appreciate than the pricing: delegated work happens in a separate context window. When the verifier churns through a fifty-step checklist, none of that transcript lands in my main session’s history. The main loop stays lean, which compounds, because a lean history is cheaper on every subsequent turn.
What a week of this looks like#
Some real delegations from my logs, with the token counts their runs reported:
- A port-collision experiment for a blog post: the bulk-worker started two dev servers, captured the exact error output, tested the fix, and cleaned up. About 32,000 tokens on the mid tier.
- A seven-point site health check after three weeks away: the verifier ran git, curl, and GitHub CLI checks and reported PASS on each with evidence. About 25,000 tokens on the cheapest tier.
- Pre-publish checklists for new posts, eight criteria each including fetching every reference URL: roughly 25,000 tokens per post, cheapest tier.
In one heavy session that came to roughly 110,000 tokens of work that never touched the flagship model. Priced at the ratios above, the same work through the main loop would have cost several times more against my limits, and the checklist transcripts would have bloated the main history on top of it.
The gotcha that cost me a restart#
Agent definitions are read once, when a session starts. I wrote the three files, dispatched work to the verifier in the same session, and got back “Agent type ‘verifier’ not found”. Nothing was wrong with the files. New definitions simply do not exist until the next session. Create, restart, then dispatch. It is documented behavior, but the error message does not say “restart”, so it reads like a typo hunt until you know.
Where the line sits#
The allocation rule I converged on: the expensive model plans, decides, writes, and reviews; everything else gets a spec and a cheaper executor. Writing the spec is the tax. A delegation prompt has to be complete enough that a literal-minded executor cannot go wrong, which occasionally means the spec takes longer than doing the task. For one-off ten-second tasks, delegation loses. For anything repetitive, anything verifiable by checklist, or anything that would dump noise into the main context, it wins by a wide margin.
Lessons#
- Usage limits are an allocation problem before they are a volume problem. Audit which model does your mechanical work before rationing your prompts.
- A subagent’s model field is the cost lever. The description field is the routing logic. Write both like they will be read by a machine, because they will.
- Delegated transcripts stay out of the main history. The savings compound on every later turn of the expensive loop.
- Agent definitions load at session start. Create, restart, then dispatch.
- Delegation is only as good as the spec. If the task cannot be specified completely, it was never mechanical work to begin with.
References#
- Claude Code subagents documentation
- Anthropic pricing (current per-model rates)
- Agent definitions quoted from
~/.claude/agents/on this machine; token counts from the reported usage of the actual delegated runs
