What a twelve-agent sweep really bills
Twelve agents don't cost twelve times one. What a fan-out is actually billed for, why the launch order moves it by 7x, and where to read the real number.
Twelve times one is not an estimate
Everyone assumes that 12 agents costing X is just 12xX. It's not about the multiplication, it's that X is not fixed, and actually even a single identical agent doing an identical simple task can charge several times more or less depending on when it was started compared to its siblings.
The cost of a fan-out can be roughly estimated by knowing what you pay for in this regard generally across different harnesses, but the thing is that what they show you differs, so we'll outline what's what for each of them.
Cost of a single agent before any actual work
In order to find out how much an agent costs we need to make one and tell it to do sth. Let's create an agent using headless Claude Code (v2.1.221) and tell it to output "ok".
claude -p "Reply with exactly: ok" --output-format json{
"total_cost_usd": 0.12535849999999998,
"usage": {
"input_tokens": 2,
"cache_creation_input_tokens": 11708,
"cache_read_input_tokens": 15185,
"output_tokens": 4
}
}It outputs 4 tokens, uses 26,900 input tokens (so the run costs 0.125$). The 26,900 is the harness' preamble — everything the harness says before your prompt; we can't see a breakdown in the JSON but it's substantial. The docs for agent teams from Anthropic say that teammates automatically fetch CLAUDE.md, MCP servers and skills, which is the same thing — just per agent rather than once.
Same thing with Codex (0.146.0), 3,590 tokens in total for "ok", they don't separate input from output so it's hard to say which is what.
codex
ok
tokens used
3.590It's not about the work, but about the cache
If you look at the above run, you can see that there are only 2 input_tokens. That's because this property counts whatever the agent didn't find in the cache; the rest is divided into cache_creation_input_tokens (what the agent wrote to the cache) and cache_read_input_tokens (what it took from the cache), and if we were to add these two together with input_tokens we would get the actual size of the prompt.
So as long as you look at input_tokens you can get an impression that a sweep costs almost nothing, let's say. Opus 5 is charged at $5 per M input and $25 per M output, cache writes cost 1.25x base input for five-minute TTL and 2x for one-hour TTL, reads are 0.1x; this particular run used the one-hour TTL.
Let's do the math:
| Line | Tokens | Rate | Cost |
|---|---|---|---|
| Cache write (one-hour TTL) | 11,708 | $10 / M | 0.1171$ |
| Cache read | 15,185 | $0.5 / M | 0.0076$ |
| Uncached input | 2 | $5 / M | 0.00001$ |
| Output | 4 | $25 / M | 0.0001$ |
| 0.1248$ |
This is actually very close to what the harness charged us for Opus 5 in this run (0.12478$), so we can calculate anything based on the number of tokens. Simultaneously, you can see that the preamble write was 94% of the cost, and the actual answer wasn't much.
If we look at the total from the harness it's actually 0.1254$. That's because there was another model (Haiku), called as part of the run for which we paid but didn't ask for. So even if you pay for one model, there can be more.
It's not about the work, but about the launch timing
As mentioned in the previous point, the preamble is at the beginning of every prompt and caching works on prefix, so if you do everything right, a single agent will write the preamble to the cache and others will read it for 10% of the cost. But it all boils down to when these agents are called.
For concurrent requests, note that a cache entry only becomes available after the first response begins. If you need cache hits for parallel requests, wait for the first response before sending subsequent requests.
— Anthropic, caching docs.
So if you call twelve agents at once, you'll have twelve writes and zero reads as nothing will be cached yet. Let's do a comparison for example (26,900 tokens of the preamble, Opus 5 prices, one-hour TTL):
| Twelve agents, preamble only | Cost |
|---|---|
| Simultaneous launch — 12 writes | ~3.23$ |
| One agent first, then the other eleven after it starts responding — 1 write, 11 reads | ~0.42$ |
That's a 7.7x difference for the preamble line alone, given everything else is identical (same agents, tasks, work). On five-minute TTL for example the write is 1.25x so it would be 2.02$ vs 0.32$, less gap but same conclusion.
Now let's go back to our naive estimate of 12 * 0.1248 = 1.5$, which doesn't reflect either scenario. The thing is that in our run the agent happened to find a warm prefix, it was 11,708 vs 15,185, so in case of a cold start they would be 26,900. And that's what we multiply by twelve, but as you can see it's bound to the state of the cache and therefore hard to predict, could easily be much more or less.
There are actually three more scenarios when reads become writes:
Prefix matching: a single different byte in the beginning of an agent's prompt renders everything after it not cacheable
Different models: caches are per-model so a mixed model sweep doesn't share anything between them
Expiration: one-hour on a Claude subscription, five minutes when on credits, default five minutes for API key or cloud provider
The orchestrator is still accumulating cost after workers are done
For every result the agent returns there are output tokens for the agent and input tokens for the orchestrator which reads it. These results stay in the orchestrator's transcript until the end of the session, and Claude Code sends the entire chat on every request (for cached price if it's cached, so not free). So a fan-out with N agents will "swallow" N results and then carry them for the rest of the session.
So it might be actually quite expensive even with cheap workers as the orchestrator's context becomes N-long and sends this N on every next request.
Cost lines table
| What you pay for | Who pays | Scales with |
|---|---|---|
| The preamble before your prompt | all the agents | N, and N cache writes in a simultaneous launch |
| Files, tool output etc consumed | the agent | how much work you gave it |
| Tokens the agent outputs | the agent | how vague your brief was |
| Ingesting N results | the orchestrator | N |
| Sending the bigger transcript for cached prices | the orchestrator | N * remaining turns |
| Reviewing N results | you | N, and it can't be parallelised |
(The last point doesn't appear on an invoice and that's why cost estimates don't include it.)
Vendor statements
Anthropic's docs put a number on it:
Agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode, because each teammate maintains its own context window and runs as a separate Claude instance.
They also say that the usage scales with team size because of every teammate having its own context window.
In Claude Code there's a /usage breakdown which shows the behaviours accounting for 10% or more of recent usage and there's subagent-heavy sessions and 4+ sessions ran in parallel.
If a company ships a built-in category for heavy fan-out, it says sth about where costs go.
Four sanity checks
The preamble share: if you were to tell twelve agents to each read three files, they'd pay twelve preambles for thirty-six files; if you were to tell one agent to read thirty-six files it'd pay one. So if you're going to delegate work, you'll get a cleaner orchestrator's context window but won't save any tokens.
Stagger by a single response: in our run the first output was after 7.8 seconds so replacing twelve writes with one write and eleven reads is 87% less of the preamble cost.
Using lower model tier for workers: Anthropic recommends using a smaller model on subagents for inexpensive tasks; Opus vs Haiku is $5 vs $1 per M input tokens, it's a lever you can use but in addition to staggering rather than instead of it.
What people will do with results: if nobody is going to properly examine twelve results, you've just bought twelve "I haven't seen that" and one "I've seen it but didn't pay attention".
Where's your figure?
Everything written above is based on a single run and calculations from prices, so the only number that matters is what your harness reports for your run at your rates. So the last thing to do is knowing where this is in your harness and what it includes or doesn't.
In Claude Code
The command is registered as /usage, with /cost and /stats as aliases (so if either of those is in your fingers, it still works). After a fan-out it's good to check the session panel at the top — you can see eg:
Total cost: $0.55
Total duration (API): 6m 20s
Total duration (wall): 6h 33m 10s
Total code changes: 0 lines added, 0 lines removed
Usage by model:
claude-sonnet-4-6: 1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)The important part for now is the cache read and cache write — and if you see more than one line under Usage by model, it means that the fan-out used multiple models. But…
It's calculated on the machine with the prices listed on the docs page (which don't take into account promotional prices and negotiated discounts so may differ from the invoice; if you're on Pro or Max plan there's no invoice at all anyway as usage is included in the subscription so it's more about how the split looks in terms of the limits)
It gets reset to 0 after using /clear (from v2.1.211 actually, for every new session it resets to 0 so make sure to check before clearing)
Per session not per agent — there's no splitting fan-out into its dozen components so you can see the cost without knowing which agent caused it
There's also a plan breakdown which shows percentages of recent usage divided between skills, subagents, plugins and for every MCP server individually. And marks everything that does 10% or more of the recent usage — like eg subagent-heavy sessions or four or more sessions ran in parallel — you can switch between 24h and 7d using d and w keys. This is all based on the local session history so if you run fan-out from another machine it won't appear here.
The clearest way to know though is headless mode, which displays raw numbers of tokens per model used in the run like this:
claude -p "..." --output-format jsonThe result carries total_cost_usd, a usage object with the four token lines, and a modelUsage map with a separate entry and its own cost for every model the run touched. As you can see, the run we measured for this lesson billed two models, and only the map revealed that.
But be aware that cache entries TTL varies — an hour on subscription, five minutes if usage credits are in place or five minutes by default with API key / cloud provider, so eg identical 12-agents script may hit cache locally but miss on every agent in CI.
In Codex CLI
The Codex CLI is essentially two views: one showing the state of a single session, answering the question "What have we done here", another showing the state of an entire account, answering the question "How much has been used so far".
For the first view, in the 0.146.0 binary the command is described as /status, with the following text attached: "show current session configuration" and "Use /status to see the current model, approvals, and token usage", which means that you can check it after doing a sweep together with the model and approval settings that were used to run it.
For the second view, the binary says about /usage: "View recent account token usage". It's attached to the information on resetting the limit, so this one is about the entire account rather than what happened during the current session.
If you use the codex CLI in headless mode using codex exec, it also shows its own summary with the total number of tokens used at the end of the run, so no need to run anything in that case. Here's an example of such a summary:
codex
ok
tokens used
3.5903590 tokens to answer a single word, gpt-5.6-terra model, reasoning effort none — the same preamble floor as in the shared part above, just expressed in tokens instead of dollars.
Something important to know is that the Codex CLI shows the run summary in terms of tokens; it doesn't provide a figure in dollars, so you need to calculate it yourself based on your provider's current rates, and it doesn't show the breakdown between the cached and fresh input tokens (which are actually priced very differently), so based on the number of tokens alone you can't be sure if doing a staggered sweep has saved you any money.
That being said, as a workaround you can run the same brief twice — once fanned out, once not — and compare the values of "tokens used" in both runs; this is an actual number that's also cost-free to collect and the only thing the tool does that answers the question.
In Cursor
In terms of the cost of a single run of cursor-agent, it's the only tool that doesn't show anything in the agent, so there's nothing to check there after a run. The billing part is visible on the dashboard level, at the account level and retroactively.
So:
Usage metered in tokens against the allowance included in the plan; for any usage beyond it - post-paid after the fact.
If you want to keep track of it - the dashboard is the place to go; admins can view it there; there's nothing to check on the client side between the runs so if you were wondering how many tokens are used per request or per session, this is actually an idea that's been already proposed by the community but hasn't been implemented yet so don't look for it.
Regarding caching - as mentioned in the shared part of the lesson, the caching behaviour is the same, just not observable; the difference between running a sweep all at once and the same sweep staggered is a single number each, days later, that you see on the dashboard and can't assign to any specific run.
The closest thing to a per-run measurement is cursor-agent in print mode:
agent -p "..." --output-format jsonWe didn't capture that envelope for this lesson so read what your own version returns before building any accounting on it; and if you're scripting a sweep against a fresh checkout - in a directory it hasn't seen, it stops and asks you to trust the workspace first.
In Antigravity CLI
Command: /usage (or /quota). Shows a panel with a table listing the limits and the number of remaining requests and tokens for each supported model; reflects the current state fetched from the backend when you open it, not using any caches.
Different from Anthropic in that it focuses on the leftover budget rather than the spend (which is a key distinction when it comes to analysing sweeps), displaying the headroom left per model rather than reflecting what a given run cost, which means that it tells you if your fan-out has exhausted the afternoon's allowance for a particular model (which is usually what you want to know in case of a budget plan) and also makes it easy to monitor utilisation for individual models, like if you were to run a fast worker on a fast model and synthesis on a strong one to see that limits for both of these models are being reduced.
To find out which one exactly after your fan-out just open the panel and see which model's limit got reduced; you won't know the internal split for a delegated run, this is not sth the /usage command from Google is telling about (they don't even say anything about it in their docs wrt subagent or background-task usage), so treat these figures as a summary rather than an attempt to estimate costs per agent.
If you want to use agy in your scripts, print mode gives you machine-readable JSON:
agy -p "..." --output-format jsonBut remember that it's a panel and not a command, so if you try to call it with the print flag you won't display the panel — you'll be sending a text prompt to the LLM which will respond with its general knowledge about quotas so it'll look like the panel but it will contain made-up numbers; if you want to actually see the panel make sure to run it within the TUI.
In Kimi Code CLI
First make sure you're on Kimi Code CLI, which reports version 0.31.1. If you run kimi --version and get something else, it might be pointing to Python's kimi-cli package, which is a separate app. This one is a rewritten version of it and comes with a new subcommand called migrate, whose purpose is to migrate your data from the old Kimi CLI to Kimi Code — so run that first if you need to.
You can find usage info under /usage. If you look at the binary, you'll see that it's called "Show session token usage" and it says "No token usage recorded yet" when there's no activity. In this particular incarnation (0.31.1), this is how Kimi keeps track of the tokens used during a session. It's per-session and in tokens. Not to be confused with Antigravity's quota view, which is a different thing. Closest thing to it is probably the Session in Claude Code, but without the dollar amount.
In terms of /swarm - the parallelisation aspect - everything under the Shared section applies, but you can't see any of that from within the swarm itself. So it's all about following the recipe.
In order to measure it, do a three-stage process:
check /usage and note the session total
run the swarm
check /usage again
The difference is the cost of this particular fan-out, which is the most accurate figure you can get (the only one actually). Use it as a basis for your next swarm run, not based on the maximum number of sub-agents allowed. The latter doesn't say anything about the cost.
If you want to use Kimi in non-interactive mode, you can do it with kimi -p and provide it with one prompt. Available output formats are text and stream-json. There's no single-object JSON option, so to measure the cost of such run from the script level, you'll need to process the stream and sum up the totals.
Things not included in any of the above, often the biggest ones
Re-run: if a fan-out fails you pay fully for it and then pay again; the cheapest fan-out is the one with a brief precise enough not to require a re-run.
Review: twelve results means twelve things to read, your work that doesn't parallelise and can easily make a fan-out not worth it despite of low prices.
Future prices: prices, multipliers and commands we used to calculate things above are for the date and versions mentioned at the beginning of this post and all of them change. So always calculate based on what your harness actually says after runs you do instead of using any table (including this one).