AI Agents Are Burning 5x the Tokens Humans Do. The Real Bill Is Up 18%.

The chart everyone quoted half of

Andreessen Horowitz's Moses Sternstein runs a recurring feature called Charts of the Week, and the August 21, 2026 edition, titled “Winds of Thematic Change,” opened with a section on AI agents. The chart, sourced to OpenRouter and credited to chartmaker Peter Walker, made one claim that spread everywhere within days: agents are now using nearly 5x as many tokens as human users on OpenRouter's routing layer, and that agentic share has grown roughly 14x since February 2026. Coverage from eWeek, ppc.land, and half a dozen other outlets ran with the 5x as the whole story, usually under a headline about agents “outpacing” or “overtaking” humans.

The same chart carries a second data point that barely made it into any of that coverage: over 85% of the agentic token burn is cached-prompt tokens, and the a16z writeup is explicit that nearly all of the relative growth in agent token usage since February came from the cached share, not fresh generation. Two facts, one chart, one publish date. Only one of them tells you anything about what an agent-heavy workload actually costs.

What a cached token even is, and why agents produce so many

Every agent turn re-sends most of what came before it: the system prompt, the tool schemas, the running conversation history, sometimes an entire file or document loaded into context. A human typing a new question into a chat window sends a short, mostly-new prompt each time. An agent looping through “plan, call a tool, read the result, decide the next step” resends the same multi-thousand-token scaffold on nearly every one of those steps, with only the newest tool result actually new. Prompt caching exists specifically to stop a provider from re-processing that repeated portion at full price every single time; it stores the unchanged prefix and charges a fraction of the rate to reuse it. Agents are the workload that caching was built for, which is exactly why their token volume is dominated by it.

Anthropic's own API documentation shows what this looks like in a real response object, with the cache-specific fields broken out from the rest of the usage block:

{
  "usage": {
    "input_tokens": 105,
    "output_tokens": 6039,
    "cache_read_input_tokens": 7123,
    "cache_creation_input_tokens": 7345,
    "server_tool_use": { "web_search_requests": 1 }
  }
}

In that single response, cache_read_input_tokens (billed at the 90%-off rate) already outnumbers input_tokens (billed at full price) by more than 67x. That's one call, not a platform-wide average, but it's the mechanism the aggregate 85% figure is made of: multiply a pattern like that across millions of agent turns and cache reads swamp fresh input almost by construction.

Two labs, three tiers, one number: 90%

The size of the discount is what turns “mostly cached” from a technical detail into an economics story. It isn't a rough industry rule of thumb; it's published, exact, and it converges across two labs that don't coordinate pricing.

OpenAI's developer pricing page lists all three GPT-5.6 tiers at an identical one-tenth price for cached input. Anthropic's pricing documentation states the same multiplier directly: “Cache read (hit): 0.1x base input price,” alongside 1.25x for a 5-minute cache write and 2x for a 1-hour write. Anthropic's own worked example in that same document runs a one-hour agent session at $0.705 with no caching against $0.525 with 80% of input tokens served from cache, a 25.5% reduction from a smaller, differently-shaped workload than the one in this piece. Different inputs, same direction, same order of magnitude.

The math the coverage skipped

Take the two real numbers from the a16z chart, the token multiple and the cached share, and the two real numbers from the pricing pages, the cache discount, and the cost multiple falls out directly. Here's the full calculation, with every input labeled:

$ python3 -c "
token_multiple = 5.0   # agent token volume vs. human, OpenRouter data via a16z, Aug 21 2026
cache_share    = 0.85  # share of agent token burn that is cache reads (a16z / OpenRouter)
cache_price    = 0.10  # cache-read price as a fraction of base input (Anthropic + OpenAI GPT-5.6)
fresh_price    = 1.00  # remaining tokens priced at the full base input rate

blended = cache_share * cache_price + (1 - cache_share) * fresh_price
effective_multiple = token_multiple * blended
print(f'blended price factor on agent input tokens: {blended:.3f}')
print(f'effective cost multiple vs. an all-fresh-token baseline: {effective_multiple:.2f}x')
"
blended price factor on agent input tokens: 0.235
effective cost multiple vs. an all-fresh-token baseline: 1.18x

Five times the tokens lands at roughly 1.18 times the input-token spend, an 18% increase, because the marginal token an agent generates is overwhelmingly likely to be a 90%-off cache read rather than a full-price fresh one. That gap, 5x in volume against 1.18x in cost, is the entire reason “tokens burned” is a misleading proxy for “dollars spent” on an agentic workload, and it's a gap none of the initial coverage of the a16z chart did the arithmetic to surface.

Where this calculation can mislead you

Three assumptions in that formula are worth naming, because each one is a place a real workload can diverge from the estimate above.

First, cache writes aren't free. Anthropic charges 1.25x base price to write a 5-minute cache and 2x to write a 1-hour cache; this calculation folds that cost into the 15% “fresh price” bucket at 1.0x, which understates it. In a workload with short-lived caches that get written often and read only a few times before expiring, the real multiple runs higher than 1.18x. Second, this only covers input tokens. Output tokens, which are not cacheable on any provider in this piece, aren't discounted at all and aren't part of the 5x figure a16z published; a workload that's output-heavy relative to input will see less benefit from caching in its overall bill than this calculation implies. Third, the 5x figure itself is a platform-wide aggregate across all of OpenRouter's traffic, not a per-task or per-agent ratio, so it says nothing about the multiple on any single workload, including the one you're running.

The other chart in the same report: usage is nowhere near evenly spread

The same a16z issue ran a second dataset, sourced to OpenAI's own enterprise usage figures, that complicates the “agents are already everywhere” framing the 5x number invites. Top-decile enterprises output roughly 8x more tokens than typical enterprises across industries, and that top decile's own output grew more than 17x since April 2025. In the information sector specifically, the gap between top-decile and typical firms widens to nearly 12x, with the leaders producing 32.5x more tokens than they did a year earlier. In legal specifically, Codex adoption is up 108x since February 2026, a category that had close to none of this usage six months prior.

Read next to the 5x platform-wide figure, this says the average is being pulled up by a small number of organizations running agentic workloads hard, while most of the distribution hasn't moved much at all. The 18% cost-multiple math in this piece describes what happens to the bill once an organization is running an agent-heavy, cache-heavy workload at the aggregate ratios in the a16z chart. It says nothing about whether your org is one of the roughly 1-in-10 already there or one of the 9 that aren't yet.

What this means if you're the one pricing the workload

The practical takeaway isn't “agent costs are basically free because of caching.” It's that the raw token-volume number circulating this week, 5x, is the wrong number to budget against, and the right one, the effective cost multiple, is something you can only get by knowing your own cache-read share, not by reading a single headline chart. That number comes straight out of the usage object on every API response, the cache_read_input_tokens field in the example above, and it's worth pulling for your own agent traffic before assuming either the scary 5x or the reassuring 1.18x applies to you.

That's the visibility MegaBrainis built to give you by default: one API across 500+ models at zero markup, with the real per-call breakdown, cached and fresh tokens both, instead of a single aggregate bill you have to reverse-engineer. And for workloads that should keep running whether or not someone's watching the dashboard, BrainClaw, MegaBrain's always-on OpenClaw agent runtime, keeps an agent's cache-friendly context alive across turns instead of re-priming it cold on every on-demand invocation, which is exactly the pattern that turns a 5x token workload into an 18% cost one instead of a 5x one.

Sign up at getmegabrain.com to see your own cache-read share instead of estimating someone else's.