I delegated a one-line edit to a helper agent. It cost 77,000 tokens.
The edit itself was maybe 40 tokens of actual change. Everything else was the helper arriving: its system prompt, its tool schemas, the catalog of every skill it might want, the list of every other agent it could call. All loaded before it read a single file.
So I went looking for what that's supposed to cost, and every write-up on the internet had a different number.
One widely shared post put a subagent at 436,000 tokens before it reads a single file. The same author went back with a cleaner method and got 54,154. Another write-up frames it as a 7x multiplier over a normal session. On my machine, today, the same nothing costs 15,746 or 38,401 depending on one field in the dispatch.
None of those people are wrong. They're measuring different machines. Subagent cost is almost entirely a function of what you have installed: your MCP servers, your plugins, your skill catalog, the size of your rules file. The tool doesn't set that number. Your install does.
Which makes the number you read in an article, including this one, close to useless as a plan. Here's how to get yours, what the tokens go to, and four trims that are measured rather than guessed.
Measure it yourself first
One command, headless, cheapest model:
claude -p "ok" --model haiku --output-format json
Read the usage block in the response. Add input_tokens, cache_read_input_tokens and cache_creation_input_tokens. That sum is what it costs to say hello. No files read, no tools called, no work done.
On my machine right now that's 29,553 tokens. Two weeks ago it was over 40,000. Yours will be a third of that or triple it, and either one is fine. The point is to have the number.
One trap worth knowing. If you have an API key sitting in your environment, that command bills your API account instead of using your subscription. Clear it for the measurement (env -u ANTHROPIC_API_KEY) or you'll pay real money to find out how much context you're loading.
Everything below this line is a worked example on one machine, mine, on 2026-09-14. Read it for the method. Don't copy the figures.
What the tokens are actually for
The interesting number isn't the total. It's the gap between a full agent and a stripped one.
When I first measured this on 2026-09-02, every general-purpose helper paid about 61,500 input tokens before its first tool call. An advisor agent, restricted to Read, Grep and Glob with no skill catalog and no list of other agents, paid 18,700 for the same nothing.
So roughly 43,000 tokens per spawn were catalog. Descriptions of skills the agent would never invoke, schemas for tools it wasn't going to call, names of agents it wasn't going to spawn. Five helpers that session came in at 64k, 66k, 66k, 77k and 94k. The 77k was the one-line edit. The 94k was a documentation lookup.
None of that is wasted by the model's choice. It's paid at the door, every single time, whether the helper does ten minutes of work or answers in one word.
That gap is the part that transfers. Whatever your total is, some of it is base cost you don't control and some of it is catalog you do. The split is what you're hunting for.
Restricted agent types are the biggest single lever
The fastest way to find your split is to stop shrinking what every agent loads and instead give some agents a shorter list.
I defined three helper types with explicit tool lists and no access to skills or MCP: a scout for lookups, an implementer for code, an owner for large tasks. Then I ran the same trivial prompt through a lean scout and a general-purpose agent, same model, same day, both replying with one word and calling zero tools.
Lean scout: 15,746 tokens. General-purpose: 38,401. That's 22,655 tokens of pure arrival cost, paid or not paid based on one field in the dispatch.
On 2026-09-02 the same comparison was 17,300 against 61,500, a 3.5x gap. The ratio shrank because I cut the catalog, not because the lean agent got worse. Both numbers are honest and they're two weeks apart, which is the real lesson: this is a moving number that belongs in a log, not in your head.
A helper running a grep does not need a catalog of your design skills. Define the narrow types once and the saving repeats on every spawn forever.
Cutting the catalog
The next fix isn't clever prompting either. It's deleting things you don't use.
Three plugins off globally and nine unused skills moved to an archive folder took a fresh session from 73,600 tokens to 43,000. A second pass the same day cut the rules file from 19,900 characters to 15,300, the memory index from 10,400 to 6,300, and the skill description block from 12,600 to 6,000. That got the session to 40,400.
The rules and memory trimming moved a third as much as the plugin cut did, for more effort. If you only do one thing here, audit what's installed before you edit a single prompt.
Where the floor is
I kept measuring after the cuts, turning pieces off one at a time, because I wanted to know how much of the number I actually controlled.
With all MCP servers off, 36,700. With the plugin suite off, 39,800. With both off, 35,600. Which means the harness I'd built on top was adding about 15,000 tokens and the tool schemas plus system prompt underneath were about 25,000.
That 25,000 is not mine to cut. So once I was near 40,000, more trimming was going to be grinding for single-digit percentages.
Run the same teardown on your own install and you'll find your floor somewhere else. That's the number that tells you when to stop optimizing.
Then cut what the agent reads
Arrival cost is only half of it. The other half is everything the agent pulls in afterward, and that's where the bigger wins were for me.
MCP servers pay twice. The tool list sits in context every turn, and every result lands whole. Across the nine servers I run day to day, the raw tool listing is 236,818 bytes. I compile them into CLIs instead, with declick, and the same surface reads as 58,309 bytes because the agent reads one small description on demand instead of all of them up front. 4.1x on the surface. A single call's payload isn't smaller, so don't expect the ratio to hold everywhere.
Trim the result before it lands, not after. --fields username,email on a call that returns forty fields is the cheapest optimization in this whole article, and it works the same way with jq, a --limit, a --where, or a SQL SELECT that names its columns. A tool that dumps its full payload into context is a tool you're paying for on every subsequent turn, because it stays there.
Stop paying to relearn the repo. A fresh session re-reads the README, the config, yesterday's files and the tests before it does anything new. On a mid-size repo that's 20k to 60k tokens of pure re-orientation. A saved handoff bundle gets that to about 640 tokens on mine, against about 23,000 to rebuild from source.
Batch your reads. Four separate greps is four round trips, each carrying its own overhead and each result sitting in context separately. One call that answers all four is one result. Same information, a fraction of the residue.
Send long output somewhere else. This is the one case where a 38,000 token helper is obviously worth it. If the work produces 40,000 tokens of log or test output and you only need the conclusion, a helper reads it and hands back four sentences. Those four sentences are what your main session carries forward instead of the log.
So when is delegating worth it
Run the arithmetic against your own arrival cost.
My threshold: under about ten tool calls or eighty lines of edits, doing it inline is cheaper than handing it off, no matter which model is running the main loop. Delegation earns its arrival cost in three situations. The work is genuinely large, like sweeping a repo or running a suite. The pieces are independent and can run at the same time. Or the tool output is long and would otherwise sit in the main context being re-read on every later turn.
If your arrival cost is 15,000 your threshold is lower than mine. If it's 400,000 you should barely be delegating at all until you've fixed that. The rule is the same, the number is yours.
What I'd do first
Measure first. One command, thirty seconds, and you'll know whether you have a problem before you spend an afternoon on it.
Then define restricted agent types, because that's the biggest single lever and it doesn't cost you anything you were using.
Then audit what's installed. Every plugin, skill and MCP server is a line item on every spawn, forever, whether it fires once a month or never.
Then write down a threshold and follow it. Mine is ten tool calls. The number matters less than having one, because the alternative is what I was doing before, which was delegating a one-line edit and paying 77,000 tokens for the privilege.
And re-measure in a month. Mine moved 40,000 to 29,553 in two weeks without me trying. A number you measured once and memorized is just a different kind of guess.
