Mostly Rereading

AI agents on OpenRouter now use about 5x the tokens humans do, and 70% to 85% of those tokens are cached input the model has already read. In August 2026 that was 7.3 trillion agent tokens a day against 1.4 trillion human. On a token dashboard that looks like waste. On the bill it is the cheapest line: on an illustrative $2/$10 rate card, 85% of the tokens are 23% of the cost, and output, 3% of the tokens, is 41%. The catch is that it stays cheap only while the cache holds. Every point of cached share is worth about 2.5% of the bill, so an agent at 70% pays 37% more than one at 85%. What the data says and doesn't, what breaks the cache, a Python tutorial that splits your agent bill into four meters from OpenAI, Anthropic and Gemini usage fields and finds the turns where the cache broke, and the order to fix things in.

Published 2026-10-14 by Dor Amir on the Nadir blog.

Filed under Agents.

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:

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.

Bar chart: OpenRouter daily tokens by key type. February 6, 2026, about 0.5 trillion for agentic keys and about 0.5 trillion for human keys. August 2026, 7.3 trillion agentic and 1.4 trillion human. 70% to 85% of agent tokens were cached input.
Bar chart: OpenRouter daily tokens by key type. February 6, 2026, about 0.5 trillion for agentic keys and about 0.5 trillion for human keys. August 2026, 7.3 trillion agentic and 1.4 trillion human. 70% to 85% of agent tokens were cached input.
February 6, 2026August 2026Growth
Agentic keys~0.5T tokens/day7.3T tokens/day14x
Human keys~0.5T tokens/day1.4T tokens/day2.8x
Ratio1x~5x

February values derived from the growth multiples. Seven-day moving averages.

Three things to know before quoting it:

  1. 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.
  2. 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.
  3. 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:

ProviderCache read priceCache writeHow it's triggered
Anthropic0.1x input1.25x input (5-minute TTL), 2x (1-hour TTL)Explicit cache_control breakpoints
OpenAIDiscounted (90% off on recent models)No premiumAutomatic on long repeated prefixes
Google Gemini 4 Argon0.05x input ($0.10 vs $2)No premium for implicit cachingImplicit, 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.

Stacked bar chart: one million agent tokens. By tokens, cache reads 85%, writes 3%, fresh input 9%, output 3%. By dollars, cache reads 23%, writes 10%, fresh input 25%, output 41%. Total $0.725 with caching, $2.24 without.
Stacked bar chart: one million agent tokens. By tokens, cache reads 85%, writes 3%, fresh input 9%, output 3%. By dollars, cache reads 23%, writes 10%, fresh input 25%, output 41%. Total $0.725 with caching, $2.24 without.
MeterShare of tokensRateCostShare of bill
Cache reads85%$0.20/M$0.17023%
Cache writes3%$2.50/M$0.07510%
Fresh input9%$2.00/M$0.18025%
Output3%$10.00/M$0.30041%
Total100%$0.725100%

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:

Line chart: cost of one million agent tokens against the share served from cache. 50% cached costs $1.355, 70% costs $0.995, 85% costs $0.725, 95% costs $0.545. Each point of cached share is worth about 2.5% of the bill.
Line chart: cost of one million agent tokens against the share served from cache. 50% cached costs $1.355, 70% costs $0.995, 85% costs $0.725, 95% costs $0.545. Each point of cached share is worth about 2.5% of the bill.
Cached shareCost per 1M agent tokensvs 85%
50%$1.355+87%
70%$0.995+37%
85%$0.725baseline
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:

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.

More on agents

What Nadir is

Nadir is an LLM router. Nadir sizes every prompt and routes it to the cheapest model that still clears your quality bar. A small decision model reads each prompt against your model menu and picks the lowest-cost model it expects to handle it. When the decision model is uncertain or unavailable, the request goes to the strongest model on the menu. The routing step makes no call to your model provider.

Nadir runs two ways. The decision API returns a model, reasoning-effort, cache, context, and policy recommendation without calling a model provider, beside the gateway you already run. That is how a shadow-mode evaluation works, and its projected savings stay advisory. The OpenAI compatible managed proxy executes the route, and migration is a two-line change: point the base URL at api.getnadir.com and set model to auto. On that path an optional verifier can score a complete non-streaming answer and escalate to a stronger model when it misses the configured bar. Streaming bypasses post-generation verification. BYOK is supported on every tier.

For coding agents, Nadir Auto is a terminal launcher for Claude Code or Codex that asks Nadir for the main-session model before each turn, with your configured model as the fallback and cost ceiling. Delegation integrations for Claude Code, Codex, or Cursor instead recommend a model tier for subagent work, and the agent decides; the Claude plugin can also move a main-thread turn to Haiku when Nadir's cache check prices it cheaper, unless its switch_main_model option is off. Either way inference runs on your own provider account, so Nadir holds no provider keys on that path.

What the numbers are, and what they are not

Nadir publishes each evaluation with its scope. On checkable code, run-check-escalate solved 392 of 395 common HumanEval and MBPP problems (99.2%), graded by running the canonical tests; that applies only to tasks with runnable deterministic tests. Nadir-Tumbler posts an arena_score of 72.3 on RouterArena's public scorer, 5th of 23 routers, which measures the routing decision on RouterArena's own model pool. A reference-assisted RouterBench evaluation over 11,420 held-out triples produced a 60% lower projected cost than always-Opus with about 98% retained quality and a 1.7% catastrophic-route rate. That experiment gave the verifier the expensive-model reference answer, which production does not have, so it is a research ceiling and not the deployed path.

None of these is a production guarantee, a universal savings rate, or a forecast for any particular workload. Customer savings are reported from measured execution against a declared baseline, and customer quality only from outcome-labelled traffic. Projected savings and realized savings are separate artifacts and are never blended.

Design-partner program

Three rungs, picked by risk appetite. Rung 0 Shadow runs advisory decision calls alongside live traffic and returns a projected receipt, with nothing in the request path changed. Rung 1 Hosted is the two-line swap on a production slice and returns a realized receipt. Rung 2 On-prem is a supervised six-week proof of concept inside the partner's VPC, where no prompt, response, or usage reaches Nadir. The commitments are the same at every rung. Apply for a rung directly: Rung 0 Shadow, Rung 1 Hosted, or Rung 2 On-prem. Not sure which fits? Start at getnadir.com/contact/?reason=design-partner.

Licensing

NadirClaw is the self-hosted core, source-available under the PolyForm Noncommercial License. Source-available is the correct label; NadirClaw is not open source. Nadir Route's hosted plan has no base fee and charges a variable fee only on measured savings from requests Nadir executed.

Pages on this site

Machine-readable summaries of this site: llms.txt and llms-full.txt.