TL;DR.
On OpenRouter, AI agents now burn about five times as many tokens as humans: roughly 7.3 trillion against 1.4 trillion in August 2026, measured as a seven-day moving average of daily volume. Agent volume passed human volume on February 6 and grew 14x in six months, while human volume grew 2.8x. The chart went viral again this month when Futurum's CEO said the ratio is heading to 10x and Tom's Hardware ran it under the headline that agents are "mostly rereading what they've already seen."
That last part is the one that matters for your bill. Depending on who measures it, 70% to 85% of agent tokens are cached input: context the model has already read, sent again on the next turn.
Rereading is cheap while the cache holds. Cache reads bill at a tenth of the input price or less, so on an illustrative rate card 85% of the tokens come to only 23% of the bill. The other 15% (fresh input, cache writes and output) is 77% of the money. And every percentage point that falls out of cache adds about 2.5% to the bill. An agent at 70% cached pays 37% more than the same agent at 85%.
This post covers:
- What the OpenRouter data says, and what it doesn't
- Why agents reread, and why token share is the wrong way to read an agent bill
- What breaks the cache in practice, and what each break costs
- A Python tutorial: split your agent bill into its four meters from the
usagefields of OpenAI, Anthropic and Gemini, and find the turns where the cache broke - The order to fix things in, and where a router helps
Traffic figures are from a16z and OpenRouter. Dollar figures use an illustrative rate card and token mix, labeled where they appear. Nothing here is Nadir customer data.
The data.
| February 6, 2026 | August 2026 | Growth | |
|---|---|---|---|
| Agentic keys | ~0.5T tokens/day | 7.3T tokens/day | 14x |
| Human keys | ~0.5T tokens/day | 1.4T tokens/day | 2.8x |
| Ratio | 1x | ~5x |
February values derived from the growth multiples. Seven-day moving averages.
Three things to know before quoting it:
- It classifies keys, not requests. OpenRouter combines seven signals, among them tool-call frequency, number of turns, and the time between requests, and labels each API key agentic, mixed or human by its dominant pattern. A key that mostly runs a coding agent counts as agentic even when a person types into it.
- It is one marketplace. OpenRouter is a large slice of multi-model traffic, not the whole market. Direct enterprise contracts with OpenAI, Anthropic and Google aren't in it.
- The cached share has two numbers. a16z, publishing the chart on August 21, said more than 85% of agentic tokens were cached prompts. Peter Walker, OpenRouter's head of insights, put the average agentic request at about 70% cached. Aggregate and per-request averages weigh long sessions differently, which probably explains the gap, but neither source has reconciled them.
The 10x forecast is Daniel Newman's, posted on X on September 30 with no timeline attached. Treat it as a direction, not a data point.
Rereading is the job.
None of this is a bug. An LLM is stateless, so an agent keeps state by resending it. Every turn carries the system prompt, the tool schemas, every earlier message, and every tool result so far, followed by the one new thing that happened. On turn 30 of a coding session, the new part may be a 400-token test failure riding on top of 80,000 tokens the model has already seen 29 times.
We've measured pieces of this before. Multi-turn conversations bill early messages again on every turn, 82% of a ReAct agent's tokens are spent before it writes a word, and tool schemas alone can run to thousands of tokens per call. The OpenRouter chart is the same pattern showing up at marketplace scale: agents read far more than they write, and most of what they read, they've read before.
Prompt caching is what makes that affordable. The provider keeps the processed prefix and bills the repeat at a discount:
| Provider | Cache read price | Cache write | How it's triggered |
|---|---|---|---|
| Anthropic | 0.1x input | 1.25x input (5-minute TTL), 2x (1-hour TTL) | Explicit cache_control breakpoints |
| OpenAI | Discounted (90% off on recent models) | No premium | Automatic on long repeated prefixes |
| Google Gemini 4 Argon | 0.05x input ($0.10 vs $2) | No premium for implicit caching | Implicit, on by default from 4,096 tokens |
So a rereading agent isn't necessarily an expensive agent. It's an agent whose costs have moved somewhere else.
Tokens are not dollars.
Take one million agent tokens with the a16z mix: 85% cache reads. Give the rest a plausible split, 3% cache writes, 9% fresh input, 3% output, and price it on an illustrative $2 input, $10 output card with Anthropic-style cache pricing.
| Meter | Share of tokens | Rate | Cost | Share of bill |
|---|---|---|---|---|
| Cache reads | 85% | $0.20/M | $0.170 | 23% |
| Cache writes | 3% | $2.50/M | $0.075 | 10% |
| Fresh input | 9% | $2.00/M | $0.180 | 25% |
| Output | 3% | $10.00/M | $0.300 | 41% |
| Total | 100% | $0.725 | 100% |
Without any caching, the same tokens cost $2.24. Caching is already saving 68%.
The useful reading is the last column. If you look at the token dashboard, the agent's problem is rereading, and the fix is shorter context. If you look at the bill, rereading is the cheapest line on it, and output, a thin 3% sliver of tokens, is the biggest. Teams that cut context aggressively to fight a token number can end up rewriting the prefix, breaking the cache, and paying more. We covered that trap in compact now, pay later.
The cache is the whole bet.
The cheap 23% stays cheap only while the cache keeps hitting. Move the cached share and hold everything else fixed:
| Cached share | Cost per 1M agent tokens | vs 85% |
|---|---|---|
| 50% | $1.355 | +87% |
| 70% | $0.995 | +37% |
| 85% | $0.725 | baseline |
| 95% | $0.545 | -25% |
Each point of cached share is worth $0.018 per million tokens here, about 2.5% of the bill. The two published OpenRouter figures, 70% and 85%, sit 37% apart in cost. That is a bigger swing than most model price cuts.
What knocks tokens out of cache, roughly in order of how often we see it:
- A changing prefix. A timestamp, a request ID or a user's name near the top of the system prompt makes every request a new prefix. Anything that varies goes at the end.
- Reordered or regenerated tool lists. Tools serialized from an unordered map, or a tool set rebuilt per turn, change the prefix even when nothing meaningful changed.
- Rewriting history. Summarizing or compacting earlier turns in place invalidates everything after the first edit, and the rewritten prefix is billed again at write rates.
- Switching models mid-session. Caches are per model. A router that moves turn 12 from one model to a cheaper one throws away the warm prefix and pays to write a new one. We priced this in your router is fighting your prompt cache.
- Waiting past the TTL. Anthropic's default cache lives five minutes. A human approval step, a long test run or a slow tool call can outlast it, and the next turn writes the whole prefix again.
- Landing on a different host. Behind a marketplace or a load balancer, a request that lands on a different provider or replica doesn't see the cache the last one built. OpenRouter added sticky routing for this reason.
Most of these are invisible on a token dashboard, because the token count doesn't change when the cache breaks. Only the price does.
Tutorial: the four-meter bill.
The fix starts with measurement. Every major provider already returns the four meters in the response's usage block. Most logging pipelines collapse them into "input" and "output" and lose the one signal that matters.
Step 1: normalize the usage block.
The three providers count differently. Anthropic's input_tokens excludes cached tokens, while OpenAI's prompt_tokens and Gemini's promptTokenCount include them. Gemini bills thinking tokens as output but reports them separately.
from dataclasses import dataclass
@dataclass
class Meters:
fresh: int # uncached input, full price
cache_read: int # input served from cache
cache_write: int # input written to cache (Anthropic premium)
output: int # visible output plus reasoning tokens
def meters(provider: str, u: dict) -> Meters:
if provider == "anthropic":
return Meters(fresh=u["input_tokens"],
cache_read=u.get("cache_read_input_tokens", 0),
cache_write=u.get("cache_creation_input_tokens", 0),
output=u["output_tokens"])
if provider == "openai": # Chat Completions usage
cached = (u.get("prompt_tokens_details") or {}).get("cached_tokens", 0)
return Meters(fresh=u["prompt_tokens"] - cached, cache_read=cached,
cache_write=0, output=u["completion_tokens"])
if provider == "gemini": # usageMetadata
cached = u.get("cachedContentTokenCount", 0)
return Meters(fresh=u["promptTokenCount"] - cached, cache_read=cached,
cache_write=0,
output=u.get("candidatesTokenCount", 0) + u.get("thoughtsTokenCount", 0))
raise ValueError(provider)
OpenAI's Responses API uses input_tokens, input_tokens_details.cached_tokens and output_tokens instead; the mapping is the same.
Step 2: price each meter and see where the money is.
from collections import Counter
# USD per million tokens. Replace with your contract rates.
RATES = {"fresh": 2.00, "cache_read": 0.20, "cache_write": 2.50, "output": 10.00}
def bill(rows):
"""rows: iterable of (provider, usage_dict)."""
tokens, usd = Counter(), Counter()
for provider, u in rows:
m = meters(provider, u)
for k in RATES:
n = getattr(m, k)
tokens[k] += n
usd[k] += n * RATES[k] / 1e6
t, d = sum(tokens.values()), sum(usd.values())
for k in RATES:
print(f"{k:<12} {tokens[k] / t:6.1%} of tokens {usd[k] / d:6.1%} of spend")
print(f"cached share {tokens['cache_read'] / t:.1%} total ${d:,.2f}")
On the illustrative mix above it prints:
fresh 9.0% of tokens 24.8% of spend
cache_read 85.0% of tokens 23.4% of spend
cache_write 3.0% of tokens 10.3% of spend
output 3.0% of tokens 41.4% of spend
cached share 85.0% total $0.72
Two numbers to put on a dashboard: cached share (the rereading that's paying off), and writes divided by reads. Writes above reads for a sustained period means you are paying the write premium for prefixes that expire before anything reads them back.
Step 3: find the turns where the cache broke.
In a healthy agent session, each turn's prompt starts with the previous turn's prompt, so the cache read on turn i should be close to the whole prompt of turn i - 1. When it falls far short, something broke the prefix, and the shortfall is billed at full price.
def cache_breaks(session, min_prefix=4096, threshold=0.5):
"""session: ordered list of (provider, usage_dict) for one agent run.
Yields (turn, expected_tokens, read_tokens, extra_usd) for each likely break."""
prev_prompt = 0
for i, (provider, u) in enumerate(session):
m = meters(provider, u)
prompt = m.fresh + m.cache_read + m.cache_write
if prev_prompt >= min_prefix and m.cache_read < threshold * prev_prompt:
missed = prev_prompt - m.cache_read
# Missed tokens were billed as writes or fresh input instead of reads.
rate = RATES["cache_write"] if m.cache_write else RATES["fresh"]
yield i, prev_prompt, m.cache_read, missed * (rate - RATES["cache_read"]) / 1e6
prev_prompt = prompt
Run it over a day of sessions, then group the breaks by what changed on that turn: the model, the time since the last turn, the tool list hash, the system prompt hash. Usually one cause dominates, and it is usually boring: a timestamp, an unsorted dict, or a five-minute TTL meeting a ten-minute test suite.
min_prefix matters because providers don't cache short prompts at all. OpenAI's automatic caching starts at 1,024 tokens, and Gemini 4 Argon's implicit caching at 4,096. Set it to your provider's floor.
Fix it in this order.
Once the four meters are visible, the order of operations follows from the bill, not the token count:
- Protect the cache first. Static content at the top, variable content at the end, tools in a fixed order, history appended and never edited. On Anthropic, use the one-hour TTL for sessions with human or long-tool pauses; the 2x write pays for itself if the prefix gets read even twice more. This is free and moves the biggest lever.
- Then cut output. At 41% of the bill on 3% of the tokens, output is where the money is. Constrain formats, use diffs instead of whole files (patch or pay), and set reasoning effort per task rather than one default for everything.
- Then route the fresh work. The uncached input and the output on each turn are priced at the model's full rate. A subtask that reads a 300-token tool result and returns a yes/no doesn't need the flagship. Route the step, not the session, and switch models at session or subtask boundaries, where there's no warm cache to lose.
- Only then trim context. Shorter prefixes help, but only with a compressor that keeps the prefix byte-stable from turn to turn. Otherwise every trim is a cache write.
The order matters because the steps interact. A router that ignores the cache can lose more on writes than it saves on rates. A compressor that rewrites history can cost more than the tokens it removed. Each lever has to respect the one before it.
Where Nadir fits.
Nadir is a cost router that sits in front of the providers you already use, with an OpenAI- and Anthropic-compatible API. With model="auto", a trained classifier reads each request and sends it to the cheapest model you've configured that can handle it, against the quality floor you set on the key. In an agent, that is step 3: the fresh, full-price part of each turn going to a cheaper model when the turn doesn't need a frontier one.
It's also built not to fight step 1. The decision endpoint accepts an optional cache_state (warm model, cached tokens, TTL, expected remaining turns) and returns whether staying on the warm model is cheaper than switching, with both projected costs in the response. Context Optimize's /v1/optimize reproduces previously optimized messages byte-identically as a conversation grows, so the cache keyed on that prefix keeps hitting. And cache-hit status comes back on every request in the response metadata and the savings dashboard, next to the model served and its cost, so the four-meter split from the tutorial is something you watch rather than rebuild.
If you want to see what routing would do to your agent traffic before changing anything, Observe mode records the decision Nadir would make on each request without altering a response. Start with a free key, or price your own workload with the savings calculator.
Conclusion.
Agents on OpenRouter now use five times the tokens humans do, and 70% to 85% of those tokens are context the model has already read. That sounds like waste, and on a token dashboard it looks like waste. On the bill it's the cheapest line, as long as the cache holds: on an illustrative rate card, 85% of the tokens are 23% of the cost, and the uncached 15% is the rest. So the work isn't to stop agents rereading. It's to keep the rereading cached, to cut output where the money actually is, and to route the fresh work to the cheapest model that can do it without throwing away a warm prefix. Measure the four meters first. The rest of the list writes itself.
Sources: a16z chart of OpenRouter token data, published August 21, 2026, for the 7.3 trillion and 1.4 trillion daily token figures and the 85%+ cached share; Peter Walker, head of insights at OpenRouter, for the February 6 crossover, the 14x and 2.8x growth figures, and the roughly 70% cached share per agentic request; OpenRouter for its seven-signal key classification and sticky routing; Daniel Newman, Futurum Group, on X, September 30, 2026, for the 10x forecast; [Tom's Hardware](https://www.tomshardware.com/tech-industry/artificial-intelligence/futurum-ceo-says-agents-use-ai-5x-more-than-humans-number-will-eventually-hit-10x-but-agents-are-mostly-rereading-what-theyve-already-seen) and [XenoSpectrum](https://xenospectrum.com/en/openrouter-agent-tokens-cache-economics/) for coverage and reconciliation of the figures; [Google AI for Developers](https://ai.google.dev/gemini-api/docs/generate-content/latest-model) for Gemini 4 Argon's implicit caching threshold and discount. Found via [Token Cost Radar](https://jcodemunch.com/radar/2026-10-14), October 14, 2026. The rate card ($2/M input, $10/M output, 0.1x cache reads, 1.25x cache writes) and token mix are illustrative, and the tutorial output is computed from that illustrative mix, not from Nadir customer data.