Agent-Fleet Token Economics Is Cache Economics: Decomposing the 60x Dollar Spread

One of the most-quoted agent-economics numbers of September 2026 is a story told by a CEO on a podcast: Matt Barrie, founder and CEO of Freelancer.com, ran a fleet of roughly 44 agents he built himself, burned about 4 billion tokens in a single day, and paid about $1,300 for it — of which roughly $900 went to Anthropic's Sonnet, the remainder to other routes — while claiming the same day on an Opus-class model without caching would have cost about $80,000¹²³.

Every number in that sentence is self-reported, single-day, and unaudited. Three billion of the four billion tokens were prompt-cache reads — agent loops re-reading their own context, not fresh work². That detail is what makes the story worth dissecting, because unlike the dollar totals, the mechanics are fully verifiable from public price sheets: the spread is arithmetic, not a discovery. This guide recomputes the whole thing against live provider pricing, decomposes the gap into its multiplicative factors, and turns the result into a capacity-planning checklist. It continues the math chain of our inference cost guide and RAG retrieval math.

Mark everything from the anchor case as reported, not verified: one operator, one day, no audit. The decomposition below stands on its own regardless of whether the day happened exactly as told.

The anchor, dissected

Work from the actual price sheet first⁴ — per 1M tokens, live at writing:

Now the reported day, restated as billable quantities:

• Total: ~4.0B tokens, ~$1,300, ~$900 of it on Sonnet²
• ~3.0B of those tokens were prompt-cache reads — a 75% looping fraction
• ~1.0B tokens were fresh: new input actually reaching the model uncached, plus generated output

Arithmetic sanity check against the sheet, all-Sonnet: 3.0B cache reads at $0.20/1M is $600. That leaves $300 of the $900 Sonnet bill for fresh input plus output. For instance ~100M fresh input tokens ($200) plus ~10M output tokens ($100) lands exactly on $300. The reported total is not just plausible — it is ordinary: a day that is three-quarters self-rereading context bills like a day that is three-quarters discounted context. The $1,300 does not describe 4 billion tokens of work; it describes roughly 1 billion tokens of work plus its own echo, billed at a tenth.

The counterfactual, honestly

The $80,000 figure is where skepticism must bite hardest, because it is a counterfactual, not an invoice. Recompute it:

All-Opus, uncached, input only:   4.0B / 1M x $5      = $20,000
All-Opus, uncached, + 1.0B out:   + 1.0B / 1M x $25   = $45,000
All-Opus, uncached, + ~2.4B out:                     ≈ $80,000

The clean price-sheet floor for "same day, Opus, no cache" is $20,000 — the input-only line. Reaching $80,000 requires assuming the day also carried roughly 2.4B output tokens at Opus's $25/1M, a much more output-heavy shape than the $900-Sonnet decomposition implies. So treat $80,000 as reported-not-verified: it is reachable arithmetic under an unstated output-token assumption, but it is not the number the price sheet alone gives you. The verifiable statement is: the same token counts, rerouted all-Opus without cache, cost at least $20,000 — already a ~15x spread over $1,300.

The spread, factorized

Divide the reported spread, 80,000 / 1,300 ≈ 61.5x, into factors that each exist as a line on a public price sheet or a property of the workload shape:

That is the anti-hype point in one table: roughly 7.7x of the spread is public arithmetic — one price-sheet ratio times one cache multiplier acting on the looping fraction. The remaining ~8x is not on any price sheet; it lives inside the counterfactual's assumed output mix. The spread is dramatic, but it is not a discovery. Anyone can reproduce the clean part in a spreadsheet in two minutes.

And the fresh-vs-cached split is the real workload description: of 4B tokens, roughly 25% — about 1B — was fresh inference. The rest was the fleet reading its own transcript back to itself at a discount.

The looping fraction is the real number

Why would 75% of an agent fleet's tokens be cache reads? Because of how agent loops are built. Every tool call in an agent's cycle sends the model the entire conversation so far — system prompt, tool definitions, prior tool results, its own prior reasoning — plus one new item. The prefix is nearly identical from call to call; only the tail grows. An agent that has run 50 steps re-sends its first 49 steps 50 times.

That is precisely the radix-prefix-cache economics our serving-engine articles describe: a KV prefix cache lets the serving engine reuse the attention keys and values of an identical prefix instead of recomputing prefill — the KV cache explained mechanism, and the tiering strategies for exactly this agentic access pattern in agentic inference KV tiering. On the provider side, prompt caching prices that reuse: cache hits at 0.1x base input on Anthropic models, 0.25x–0.5x elsewhere depending on provider, writes at 1.25x–2x⁴⁵.

The consequence is structural, not incidental:

• Without the cache discount, cost scales with loop count, not with work done. A 50-step loop bills step 1 fifty times. At full input price, a fleet's bill is dominated by its own repetition; the provider discount is what converts the bill back into something proportional to actual new tokens.
• Cache compatibility is a budget line, not a detail. Caches have TTLs (5 minutes default, extendable to 1 hour on Anthropic routing), minimum cacheable prompt sizes (1,024–4,096 tokens depending on model), and provider-specific reset behavior — Anthropic explicit caching via cache_control breakpoints, OpenAI implicit caching above 1,024 tokens, sticky provider routing needed to keep hits warm through a gateway⁵. An agent harness that shuffles providers per request, rewrites its system prompt per call, or just runs slower than the TTL pays full input price for the same work.

So when the anchor case bills $1,300 for a day that would be $20,000 uncached-input-only, that is not the fleet being clever — it is the fleet being typical. The 75% cached share is what agent workloads look like when the caching layer is doing its job.

The 85% self-optimization claim, skeptically

The anchor case also reports that a single instruction — telling the agents to review and optimize their own token usage — cut consumption by a further 85%¹³. Verify only that it was claimed, not that it worked as advertised. Two problems:

First, the literature on prompt-level cost control is a quality minefield. Brevity-directed prompting measurably shortens responses and cuts energy 25–60% on factual query work, but the same evaluations warn that output compression is unsuitable for long-form tasks⁶. Cost-optimized prompt work explicitly notes that static length-constrained prompts are brittle and degrade reasoning on hard problems — models frequently ignore token limits, and forced compression makes reasoning models skip steps⁷. An 85% consumption cut achieved by one sentence is, most plausibly, agents writing less, thinking less, or re-exploring less — any of which may be exactly right for the fleet's tasks, or exactly wrong.

Second, no evaluation accompanied the claim. There is no before/after task-completion measurement, no error-rate check, no eval at all in the public record — only the token counter, which is the one metric a cost-cutting instruction is guaranteed to improve.

The verdict framework this site applies: cost-per-completed-task is the only metric that survives contact with quality regressions. Cost-per-day optimizes the wrong denominator; a fleet that halves its bill by quietly failing a fifth of its queue looks identical on a consumption chart. If you try prompt-level cost control (you should — it is free), gate it: run a fixed eval set before and after, and treat the token reduction as unproven savings until task success rates hold.

Fleet extrapolation: what compounds, what stays flat

Barrie's stated plan is to scale the fleet 10x, then again¹. Do the arithmetic honestly, because the two axes behave differently:

• Agents scale linearly. 40 agents at $1,300/day is 400 agents at ~$13,000/day, cache hit rates held constant. Nothing compounds in agent count; each agent's bill is roughly independent.
• Context depth is where cost grows super-linearly. Per task, an agent that runs n steps with an L-token step increment re-sends a prefix averaging n·L/2 tokens over its lifetime: re-read volume grows roughly with the square of steps completed. Long-running agents get more cache-dependent the deeper they run — which means the cached fraction grows with context depth, and so does your exposure to TTL misses and cache resets. A fleet of agents that run 500 steps each is far more cache-elastic than a fleet that runs 20.
• What actually compounds: nothing in this cost model. Token price does not rise with volume; cache discounts do not decay with scale; the only super-linear term is per-task loop depth, and it is capped by your context window and your compaction policy. Fleet cost is linear in agents times quadratic-in-steps per task — the steering levers are step budgets and context compaction, not negotiation with the provider.

For scale context: OpenRouter's weekly token consumption — the routing layer the anchor fleet bills through — was reported at 126.2 trillion tokens per week, up more than 25,000% from ~0.5T in January 2025⁸. The same analysis that surfaced the chart attributes much of the growth not to more users but to reasoning thinking-tokens and unoptimized agent loops⁸ — the looping fraction, visible at planet scale. Barrie's 4B/day is 0.0032% of that weekly flow: one enthusiastic operator is noise; a million of them is the curve.

The 30 terawatt takeaway, recomputed

The anchor case offers one world-scale extrapolation: if all ~8 billion people burned 4B tokens a day, the world would need about 30 terawatts — roughly ten times global electricity production³. Rather than trust it, recompute from stated assumptions:

tokens:      4e9 tok/day/person x 8e9 people        = 3.2e19 tokens/day
FLOPs/token: 2 x active params, 100-300B active      = 2e11-6e11 FLOP/token
efficiency:  1-3 effective TFLOPS per wall-watt
                                             (delivered, incl. overhead)
compute per day = 3.2e19 x (2...6)e11       = 6.4e30-1.9e31 FLOP/day
power          = compute / 86400 / 1e12...3e12 = 24.7-222 TW
with 75% cache-served prefill skipped (near-zero marginal FLOPs): x 0.25
             = 6.2-56 TW

Bracketing honestly: 6–56 TW depending on model scale and silicon efficiency, versus ~3.4 TW of average world electricity generation — so "30 TW" sits inside the recomputed band and "ten times world production" is the right order of magnitude. The number is a back-of-envelope, not a measurement, and the cache-skip term alone moves it by 4x — the same elasticity, at planetary scale, that dominates the fleet's daily bill. Also note what the thought experiment hides: 4B tokens/day/person is a heavy-build day for one CEO who was actively constructing a fleet, extrapolated to everyone forever. Both the dollar spread and the terawatt figure cherry-pick their day.

Practical: capacity-planning checklist for an internal fleet

Everything above reduces to five items to check before you commit a budget to an agent fleet:

1. Model cost against cache-hit-rate, not list price. At a 0.1x cache-read discount, the cost multiplier is 1 − 0.9 × h where h is your hit rate: h=0.50 cuts input cost to 0.55x, h=0.75 to 0.325x, h=0.90 to 0.19x. Measure h from your provider's usage telemetry (cached_tokens in the usage object on OpenRouter-routed requests⁵) before you believe any fleet cost projection. A projection that assumes h=0 has already overestimated by 3x on a typical agentic shape.
2. Build the provider × cache-compatibility matrix before choosing a model. Explicit cache_control breakpoints vs implicit caching; 5-minute vs 1-hour TTL vs backend-dependent eviction; 1,024–4,096 token minimum cacheable prefixes; sticky routing loss when you manually order providers⁵. A model that is $1/1M cheaper but resets its cache on every request swap is the expensive one.
3. Budget by line item, with cache reads on top. The budgeting heuristic: on an agentic workload, cache-read spend is your largest single line item — 75% of tokens priced at a tenth is still 3x the fresh-input line at Sonnet rates ($600 of cache reads against$200 of fresh input in the worked example above). Do not let a "cached = free" intuition hide it; do not let a "4B tokens!" headline hide that only 1B were work.
4. Cap loop depth per task. Since re-read volume grows ~quadratically with steps, a step budget plus periodic context compaction is worth more than any price negotiation. Halving maximum steps cuts the re-read term roughly 4x.
5. Gate every cost optimization behind cost-per-completed-task. Prompt-level cost instructions⁶⁷, summarization compaction, cheaper-model routing in the loop — run your eval set before and after each change. The metric that survives quality regressions is dollars per finished, verified task. Cost-per-day is the metric that gets quietly gamed, by your own agents if you instruct them to game it.

Verdict, with both failure modes stated

The anchor case is real arithmetic wrapped around an unaudited day. The verifiable core: agent fleets are dominated by prefix re-reads; the provider cache discount at 0.1x is what makes the economics work; the dramatic dollar spreads decompose into public price-sheet ratios and one workload-shape number; and the honest uncached counterfactual floor is ~$20,000, not the reported $80,000 — mark the difference as counterfactual choice.

Both hype failure modes are on record in the same month: "$5/month personal agent" stories cherry-pick free-tier routing and ignore fleet-scale looping, while the $80,000-vs-$1,300 spread cherry-picks a heavy-build day and an output-heavy counterfactual. Both are true statements about their own day. Neither generalizes. What generalizes is the shape: agent fleet cost is cache elasticity — your bill is fresh_work × price + re_reads × 0.1 × price, and every serious capacity plan starts by measuring the second term, because it is the biggest number on the page.

Footnotes