Multi Agent Cost: What a Graph of Agents Bills

TL;DR

• The invoice for one real 43-file agent run: 1.96x the tokens of a single-agent baseline for 7.74x the wall-clock speedup. The cost driver is call count, not per-call size.
• Converting tokens to dollars needs the input/cache/output split, not just the total. Same token count can land anywhere from a few dollars to eighty, depending on that split.
• Tier by node: a cheap model on boring “check and return” nodes, a strong model only on nodes that judge or write. Measured on this corpus: the tiered arm billed $9.45 against the uniform arm’s $23.28, a 59.4% cut for the identical verified result.
• Subagents inherit your session model unless you override it. A big fan-out bills entirely at your tier by default. Check /model first.

📊 Result proof Single-agent-sequential baseline: 1,717,260 tokens / 1,195.5s (43 agent calls). Same job as a parallel graph: 3,364,399 tokens / 154.5s (86 agent calls). Measured on one 43-file lint-and-fix sweep, harness-reported token totals. Source: this series’ own run trace, 2026-08-13.

Ten parts ago, in the Loop series, I admitted something and then walked away from it: I never measured what the manual run cost. Every part since has deferred the bill with the same line, “pricing the fleet is Part 11’s job.” This is Part 11. I’m going to hand you the multi agent cost of one normal run, in seconds, tokens, and dollars, then show you how to cut it by tiering the graph so cheap work runs on a cheap model.

Promise: by the end you can convert a run’s token totals to dollars at today’s prices, tier a graph by node, and estimate your own fan-out’s bill before you press go.

Prerequisites:

• You’ve read the 43-file fan-out. Its single-agent run is the baseline this invoice compares against.
• You’ve read the reduce step. Its arrange-vs-decide test is how you’ll classify each node as cheap-tier or strong-tier.

Where you are: the loop never measured what a run costs

The gap is simple: the Loop-era spec (Part 2) shipped, worked, and never once printed a token count. That felt fine at the time. It wasn’t. A fan-out that you can’t price is a fan-out you can’t defend in a budget review, and “it’s faster” is not an answer when someone asks “faster at what cost?”

Here’s the thing: the only fleet invoice anyone cites is Bun’s disputed ~$165,000 Zig-to-Rust rewrite (Simon Willison’s writeup), and even that number is contested. Nobody has published what a normal run costs. So here is a normal run’s invoice, not a headline migration.

What is the multi agent cost of one 43-file run?

For this specific job, a 43-file lint-and-fix sweep, going from one agent running sequentially to a fanned-out graph cost roughly 1.96x the tokens for roughly 7.74x the wall-clock speedup (source: this series’ run trace, 2026-08-13). The token cost climbed because the graph makes 86 agent calls where the baseline makes 43, not because any single call got bigger.

Look at the tokens-per-call row: 39,936 versus 39,121, nearly identical. The split into separate fix and verify agents doubled the call count, and the call count is the whole story. Read as a rate, the graph processed about 15x more tokens per second of wall clock. That’s the same trade stated a second way: you buy wall-clock time with parallel throughput, and the aggregate bill rises because you ran twice the calls, not because the calls got fatter.

One caution I’ll repeat everywhere: don’t compare these seconds against any other run’s seconds. Wall clock is not portable across machines. The Part 3 measurement locked its own environment for exactly this reason. Compare tokens across runs; keep each run’s seconds inside its own invoice.

How do you turn a token bill into a dollar bill?

Answer first: convert at today’s fetched price, never from memory, and convert per token category, because input, cache reads, and output are billed at rates that differ by up to 50x. At current Anthropic API list prices (fetched and re-verified 2026-08-20; re-check before you trust any figure), Claude Opus 4.8 is $5 / MTok input, $6.25 cache write (5m), $0.50 cache read, $25 output, and Claude Opus 5 prices identically. Sonnet 5 is $2 / $2.50 / $0.20 / $10. Haiku 4.5 is $1 / $1.25 / $0.10 / $5. Note the cache-write rate: it’s 12.5x the read rate, and in the measured run below it turned out to be the biggest line item on the bill.

That price spread is why the token total alone can’t give you a bill. Take the graph run’s 3,364,399 tokens on Opus 4.8:

• If every token were a cache read: about $1.68.
• If every token were fresh input: about $16.82.
• If every token were output: about $84.11.

Same run, a 50x range, decided entirely by the input/cache/output split. The session-thrift post is about shrinking that split inside one session. This post is about the unit price of the whole fleet, which is a different axis.

So the honest move is to break the per-category token counts out and price each bucket separately. In the invoice run’s trace I couldn’t do that cleanly: a naive reconstruction over-counted by 3x to 4x because cache-read accounting compounds across a multi-turn agent’s transcript, so its trustworthy number is the harness’s own aggregate. The tiered run later in this post fixed that at the source: its dollar figures come from summing each API request’s own reported usage, category by category, which is the meter’s own arithmetic. The lesson stands either way: capture the input/cache/output split at run time, or your dollar figure is a guess with error bars wider than the number itself.

How do you tier a graph by node?

Not every node needs your smartest, most expensive model. Use the arrange-vs-decide test from the reduce step: a node that only arranges work, “run the linter and return the findings,” “check this file is clean,” is boring, and it runs correctly on a cheap tier. A node that decides, “is this finding real,” “write the summary,” runs on a strong tier. Same graph, two bills.

Here’s the tiering for the 43-file job:

The Opus-to-Haiku span is 5x on price, so demoting one node from Opus to Haiku is a clean 5x cut on that node’s tokens, across input, cache reads, and output alike. (Adjacent tiers are closer: Opus to Sonnet is 2.5x, Sonnet to Haiku is 2x.) The relative saving doesn’t depend on the split at all, which is what makes tiering the reliable lever.

The catch is the default. Subagents inherit the session model unless the call overrides it. So a fan-out you thought of as “mostly cheap grunt work” silently bills every grunt node at your session tier. If you started the session on Opus, all 43 check-and-return nodes just ran on Opus. The one-line habit: check /model, or pass an explicit per-node model, before you fan out.

What does tiering actually save? (the new run)

Measured, n=1 per arm: the identical 86-call job billed $23.28 with every node on Claude Opus 5 and $9.45 tiered, with the 62 clean-file nodes on Haiku 4.5 and the 24 dirty-file nodes on Opus. That’s a 59.4% cut, an identical independently verified end state, and a tier classifier that was a 2-second code sweep.

This pair ran fresh, in one environment, for exactly this section (source: the tiered supplementary run trace, 2026-08-20). Same 43-file corpus, fingerprint verified, same fix and verify prompts in both arms, per-node model overrides the only difference. The tier assignment reused Part 8’s code classifier: one shellcheck sweep, about 2 seconds, 0 tokens, and the clean/dirty split it produced decided each node’s model. These numbers don’t mix with the invoice section above, which is a different environment and a different experiment; this comparison is internally complete.

Two wrinkles, and they’re the honest teeth of the result. The tiered arm billed more tokens (+2.9%), because the Haiku nodes took more tool round-trips, and it was slower (+12.5% wall clock). It still cost 59.4% less, because 64% of the billed tokens moved to a tier priced at exactly one fifth of Opus in every category. Tiering is a price lever. It is not a token lever, and it is not a speed lever; on this run it paid a mild tax on both to cut the bill by more than half.

One thing this pair deliberately doesn’t claim: whether the tiered graph undercuts the single-agent sequential baseline. That third arm wasn’t run in this environment, so the prediction stays unresolved rather than quietly upgraded. And the per-category split behind the dollar figures held a surprise worth its own sentence: cache writes were 72% of the uniform bill despite cache reads being 82% of the tokens, because writes bill at 12.5x the read rate. The advice from the conversion section gets sharper, not weaker: the categories that decide your bill here are the two cache ones.

For context, and cited once, not re-explained: routing already cut this same corpus from 2,419,777 to 684,636 tokens (Part 8). Tiering and routing are different levers on the same bill, and they stack.

Estimate your own bill before you run it

You don’t need the measured run to estimate your own graph. The cost model is:

cost ~= nodes x rounds x per-node-tier-rate + verifier multiplier

The verifier multiplier is the fix-plus-verify doubling you saw in the invoice: a graph that verifies every node makes roughly twice the calls.

Try it now

1. Run /model to confirm which tier your session (and every inherited subagent) is on.
2. Fetch today’s prices from the Anthropic API pricing page and drop your own cheap_rate / strong_rate into the estimator below.
3. Set your files and dirty counts, run it, then wire the budget.remaining() guard into your graph loop before you fan out.

Worked example, N = 43 files, one fix pass and one verify pass, cheap tier on the clean nodes, strong tier on the dirty ones:

# Pre-flight estimate, priced at today's fetched rates.
files          = 43
dirty          = 12        # the ones that need adjudication + a real fix
clean          = files - dirty
tok_per_call   = 40_000    # from the invoice: ~39k measured

# arrange nodes -> cheap tier; decide nodes -> strong tier
cheap_rate     = 1.0 / 1_000_000   # Haiku 4.5 input, $/tok (re-fetch!)
strong_rate    = 5.0 / 1_000_000   # Opus 4.8 input, $/tok (re-fetch!)

cheap_calls    = clean * 2         # check + verify, both boring
strong_calls   = dirty * 2         # adjudicate + write, both judgment

est = (cheap_calls * tok_per_call * cheap_rate
       + strong_calls * tok_per_call * strong_rate)
print(f"~${est:,.2f}  (input only; add output + cache buckets)")

Treat that as a floor, not a bill: it prices input only. Add your output and cache-read buckets the same way, per tier, and you have a real range before you spend a token.

Then cap it. budget.remaining() is a hard ceiling that throws, not a polite suggestion. Wire it so a runaway fan-out fails loudly instead of quietly billing to the moon:

for node in graph.nodes:
    if budget.remaining() <= 0:
        raise BudgetExceeded(f"stopped at {node.id}")  # loud, not silent
    node.run()

💰 Value breakdown The single most expensive default is invisible: a fan-out that inherits an Opus session tier on nodes that a Haiku could handle. On this 43-file job, paying the strong-tier rate 86 times billed $23.28; paying it 24 times and Haiku’s rate for the other 62 billed $9.45. Same verified result, $13.83 back, and the classifier that decided each node’s tier cost 2 seconds and 0 tokens. Check /model before you fan out.

Verified outcome: you can now price a fan-out before running it and tier it so cheap work runs cheap. What can go wrong: you convert from a stale price table, you convert the aggregate token count instead of the per-category split, or you fan out on an inherited Opus session and pay strong-tier rates for grunt work. Next: you can price a run now, but can you tell which node quietly did nothing? That’s the next post.

FAQ

How much does it cost to run multiple AI agents on one task?

On one measured 43-file run, the graph used 1.96x the tokens of a single-agent baseline for a 7.74x wall-clock speedup (source: this series’ run trace, 2026-08-13). The dollar figure depends on your input/cache/output split and the price table on the day you run it, so convert per token category, not from the aggregate.

How do you reduce multi-agent token cost?

Tier by node. Run a cheap model on nodes that only arrange work and a strong model only on nodes that judge or write. The Opus-to-Haiku span is 5x per token in every category, and on this corpus the measured tiered arm billed 59.4% less than the uniform arm for the identical verified result. Cap total spend with a budget.remaining() that throws. Routing (skipping nodes the input never needed) is a separate, composable lever.

Do subagents cost more than a single agent?

They inherit the session model unless you override it, so cost scales with call count at your session tier. A fan-out that doubles the call count for a verify pass roughly doubles the token bill. Check /model before fanning out so grunt nodes don’t run on your most expensive tier.

What is model tiering for AI agents?

Assigning a cheaper model to nodes that only arrange work and a stronger model to nodes that make decisions, using the arrange-vs-decide test. Same graph, two bills.

What to read next

• The 43-file fan-out - the single-agent baseline this invoice compares against, and where the no-cross-environment-wall-clock rule comes from.
• The reduce step is free - the arrange-vs-decide test you use to classify each node as cheap-tier or strong-tier.
• Edges that decide at runtime - routing, the other lever on the bill: it removes the nodes the input never needed.