Six agents at once is not six times one agent

Running six copies of an agent at once does not cost six times what one copy costs. The call count multiplies, which is the part everyone expects. What also moves is the price of each individual call, because the things concurrent copies share are exactly the things that set that price — the prompt cache, the account's throughput ceiling, and whatever window the spend is measured against. And the number of copies is almost never a line of code. It is a flag, a config value, or a second terminal window.

The multiplier is a setting nobody reviewed

Several Hacker News threads in the week to 2026-10-15 describe running agents in parallel as ordinary practice rather than an experiment. A developer announcing a session switcher described the problem it was built for:

I use quite a few coding agents (Claude Code, Codex, Cursor, ...) and often several of them concurrently, so it can be hard to keep track of which agent is waiting for me.

In a separate thread about moving off hosted providers, a commenter who had put their spend at about a euro a day was asked the obvious follow-up:

if you're only paying a euro a day... it sounds like your only running one agent at a time? Your token usage absolutely scales with parallel agents.

That is the right question, and the scaling is the floor rather than the whole answer. A per-agent cost figure is measured in one condition and then applied to another, and the parameter that changed between them never appeared in a diff. Everything else that moves cost — a model choice, a prompt, a tool catalog, a retry policy — is written down somewhere a reviewer can see it. Concurrency is typed at a shell prompt.

Concurrent copies compete for the same cache

Prefix caching is priced on reuse: a cache write costs more than sending the same tokens as plain input, and a subsequent cache read costs a fraction of it. The exact multipliers are provider- and model-specific and change, so take them from your provider's current pricing page rather than from memory. The direction is the part that matters here, because it interacts badly with arrival timing.

Run six copies of the same agent one after another and the first pays the write while the other five read a warm prefix. Start the same six together, against a cold prefix, and each one can find nothing cached and pay its own write. Same code, same prompts, same total work, two different bills — decided by whether the copies were staggered. The per-copy cost is not independent of how many other copies are running, which is what makes a figure measured at one copy a poor prediction at six. This is the timing-dependent half of prompt prefix stability: a prefix can be stable in the source and still miss, because something else got there first or nothing did.

Throughput limits push the same way from the other side. Concurrency is how an account reaches its own rate ceiling, and past that point the work queues. The spend is unchanged and the wall-clock is not, which means a cost dashboard records nothing at all about the thing that just went wrong.

Under an allowance, overspend is paid in time

When the binding ceiling is a plan allowance rather than a per-token bill, the consequence of running more copies is not a larger invoice. A Hacker News comment explaining one coding tool's plans describes the shape these take:

With your plan, you get a specific monthly amount of money you can use, with separate weekly and 5-hour limits to not spend all at once.

Read that as a cost control and the nesting is the whole mechanism. The ceiling that stops you first is the shortest one, and six copies reach it in roughly a sixth of the time one copy would. Nothing about the monthly figure moves. What you lose is the remainder of the window, and it is lost to whoever was waiting on the work rather than to the budget.

This is the other direction of the point in run quotas and concurrency caps do not bound spend. A ceiling counted in runs tells you nothing about dollars; a ceiling counted in dollars over a refilling window tells you nothing about when you stop. Both gaps come from the same place — a limit reports on the quantity it counts and stays silent about every other one.

What the scan counts, and what it does not

According to Capsera's July 2026 scan of 133 public agent repositories, the ones making direct model calls carried a median of 2 agents each and 8 at the 90th percentile. That figure is worth being precise about: it counts agents defined in a repository, not copies running at the same time. Concurrency is a second axis, it is set at runtime, and it multiplies the first. The scan does not measure it and neither does anything else in the usual toolchain — the method and its limitations are published for exactly this kind of question.

The two axes compound in the direction you would expect. Multi-agent amplification is what happens when one task becomes forty calls across six agents; running several of those tasks at once is that number again, times the copies, against one shared cache and one shared allowance. A developer describing an unsupervised swarm reported the per-copy behaviour changing with the coordination:

It works, but there is a significant amount of churn. I find when the swarms use git it's less churn and less token usage.

Per-copy token usage that moves when the copies coordinate differently is the same observation from inside the run.

Four things worth measuring

1. Input tokens per copy at N=1 and at the N you actually run. If per-copy input tokens climb with N, the concurrency is buying cache misses.
2. Cache reads and cache writes as separate dimensions, per copy. Collapsed into one input total, the effect above is invisible by construction.
3. Time to window exhaustion, not just spend per day. Under an allowance the quantity that runs out is the window, and no dollar figure reports it.
4. Where N is set and who can change it. A concurrency setting is a spend control whether or not anyone has called it one.

Where Capsera sits

capsera.init() patches the provider clients — Anthropic messages, OpenAI chat completions, OpenAI embeddings and Google Gemini, sync and async — so every copy is captured whichever client instance issued the call. Attribution is held in a ContextVar stack rather than on a shared object, so isolation holds per thread and per asyncio task: six concurrent copies of the same agent do not interleave their attribution, and a sub-agent inherits its parent's identity without anything threaded through call sites.

The honest limit is in the scopes. Budgets are per agent, per team or global, checked before the provider call so a blocking budget raises BudgetExceededError and no tokens are spent — but six concurrent copies of one agent share that agent's envelope rather than each holding their own, and a per-run cost ceiling is a category concept we write about rather than a feature that ships. A call matching no budget proceeds, and so does every call if Capsera is unreachable, because a spend tool should not be the reason your work stops.

Two places to look elsewhere. If the copies span processes or machines and you want the ceiling in the request path rather than in each one, LiteLLM is MIT-licensed, free, covers 140+ providers and enforces hard budgets per key, team, organisation and model — a gateway sees all the copies at once, which an in-process SDK can only do by being in each of them. If what you need is the content of the run that churned, Langfuse is open source, free and built for trace inspection; Capsera stores hashes and token counts and never prompt or response content. The layering is set out in gateway vs observability vs governance.