Subagent-Tax 0.3: A Better AI Agent Cost Model

The preamble can re-enter on every model turn

An API call isn't the same as a long-running session where context "sticks" for free. Tool schemas and other parts of the preamble can be sent again with each model call. If the subagent needs multiple turns to finish the job, those repeated inputs matter.

Say the preamble is 51,000 tokens and the subagent makes three model calls. Under a per-turn model, that's about 153,000 tokens of preamble occupancy across those calls - not 51,000. That's the correction subagent-tax 0.3 applies, using the same revised framework as mcp-tax 0.3.

The practical takeaway is simple: a long preamble can cost real tokens even if the user-visible task instructions are short. Tool definitions, schemas, and other shared context often aren't written by the user for each task, but they still take up space when included in the request.

Every spawn starts another context

The second multiplier is how many times the parent agent launches that subagent. Each Task() call creates a fresh context, so the new subagent run needs its own copy of the preamble. If your workflow spawns lots of subagents, you don't just "pay once and reuse" automatically.

That's why a small per-task underestimate can become a large aggregate underestimate. One spawn might not move the needle much. Do it dozens or hundreds of times, and it adds up fast.

A reader-reported example makes the scale concrete: 2,631 subagent runs accounted for 48.1% of all tokens in the observed workflow. That's tied to a specific real-world case, not a universal benchmark. But it's still a useful warning - subagent overhead can become a big share of total usage, so it's worth measuring instead of assuming it's negligible.

The key distinction is between turns inside one subagent and separate subagent spawns. Turns repeat the preamble across model calls. Spawns create a new context and make you pay the setup cost again. A good estimate has to account for both.

Understand the two totals

The tool keeps cumulative window tokens separate from billable tokens - because they answer different questions.

• Cumulative window tokens track how much repeated context the workflow processes across calls.
• Billable tokens estimate how many tokens contribute to charges after the assumed cache behavior is applied.

Caching might lower the billable figure, but it doesn't make the prompt material disappear from the context window. Treating cached input as if it no longer occupies context would mix up two different ideas: pricing assumptions vs. capacity calculations. Keeping two columns avoids that confusion.

In the release example, the cache hit rate is 0%, so the totals match. With a different cache assumption, billable tokens could drop while cumulative window tokens stay the same. The spawn turn is treated as cold because each fresh subagent starts with a new context; the model assumes a cache miss at spawn.

Compare the old and corrected estimates

In the example, the older spawn-only model counted 6,732,000 tokens. The corrected ledger counts 20,460,000 - a threefold difference given the stated assumptions.

That "3x" isn't something you can blindly apply to every workflow. It's specific to this example's estimated three turns per task and the old model's narrower accounting. Your results depend on call counts, preamble size, internal turns, spawn overhead, and caching. The point isn't "every estimate is exactly 3x too low." It's that ignoring per-turn re-entry can be meaningfully wrong.

Three assumptions you can tune

The report exposes three inputs that drive the estimate:

1. --turns-per-task estimates the number of turns inside each subagent. The parent transcript may not show those internal turns, so this is a heuristic, not something directly observed.
2. --spawn-overhead estimates the tokens tied to the Task payload and the result handling for each call.
3. --cache-hit-rate adjusts how the billing model treats caching. The spawn turn is still considered cold, and caching changes billable cost rather than window occupancy.

These controls matter because one default won't fit every workflow. A subagent that does a quick lookup may use fewer turns than one that plans, calls tools, and revises its output. Task payload size and returned content also vary by implementation.

The trade-off is that tuning involves judgment. If you don't know the internal turn count, changing --turns-per-task doesn't turn the result into a measured fact. Pick the value that best matches what you've observed, write it down as an assumption, and compare scenarios instead of presenting a single number as certainty.

Keep the old estimate for comparison

Subagent-tax 0.3 keeps the old spawn-only number in its JSON output as old_model_tokens. That's useful. Removing it would make it harder to see what changed; keeping it side by side helps you quantify what the earlier model missed for a given run.

A comparison is most meaningful when you hold inputs constant. If you change assumed turns, spawn overhead, and cache rate all at once, you make it harder to interpret the differences. Start by comparing old and corrected estimates using the same workflow assumptions, then run separate scenarios to see how sensitive each knob is.

A practical review workflow

If you're using this for planning, work through the report in this order:

1. Check the call counts. Confirm that the number of launches by subagent type matches what you're trying to measure.
2. Review the turn assumption. Use --turns-per-task to model a plausible number of internal turns. If you have better instrumentation, rely on observed data instead of a generic default.
3. Check the per-call overhead. Set --spawn-overhead to match the task payload and result handling in your setup.
4. Separate capacity from spend. Treat cumulative window tokens and billable tokens as different measurements, especially if caching is involved.
5. Compare against the old model. Use old_model_tokens to see what the spawn-only approach left out under the same assumptions.
6. Run a range, not one point. Try low, expected, and high turn counts. When internal behavior is uncertain, that gives you a more useful planning envelope.

This approach is usually more reliable than treating a single total as an exact invoice prediction. It helps you spot whether repeated preambles, frequent spawns, or task overhead are the real cost drivers.

When this estimate is useful

The ledger is especially useful when you're deciding between lots of narrow subagents vs. fewer broader ones. It can also help you identify agent types that spawn frequently - then you can look at prompt reduction, grouping tasks differently, or delegating more carefully.

It's less useful as a replacement for provider billing data. Real charges depend on the API, model, token categories, cache behavior, and other pricing rules. Use the report to understand the shape of your workflow and where costs likely come from, then reconcile actual spend using the provider's usage records.