AI Agent Token Usage Overtook Humans on OpenRouter

On February 6, 2025, the typical LLM customer changed species, and almost no one's architecture noticed. According to data OpenRouter has published, traffic from apps the platform classifies as agents began consuming more tokens that day than traffic from human-driven apps, and the gap has kept widening since: agentic consumption up roughly 14x over the reported window, human usage up about 2.8x. AI agent token usage passing human usage on a major gateway is a demand-side inversion, not a milestone to file away. If your analytics, rate limits, cost model, and documentation all assume a person at a keyboard, every one of those systems is now tuned to the minority of your traffic.

One caveat up front, because it applies to everything below. OpenRouter is a single, developer-heavy gateway, not a census of the LLM market. The crossover is strong directional evidence of machine-majority demand, not proof of it everywhere. Treat the numbers as a skewed but high-signal sample, which is exactly the kind of sample builders act on.

What the Data Shows About AI Agent Token Usage

OpenRouter is an API gateway that routes developer traffic to a wide catalog of models across providers, and it publishes usage openly on its token usage rankings page. Sitting between apps and models gives it a view most providers lack: which categories of applications are actually burning tokens. A deep dive with OpenRouter's COO walks through the numbers. The three lines worth memorizing:

• Since February 6, 2025, traffic classified as agentic has consumed more tokens than human-driven traffic on the platform.
• Over the reported window, agentic consumption grew roughly 14x against about 2.8x for human traffic.
• Roughly 70 percent of agentic token volume is served from prompt cache, meaning most of what agents send is a stable prefix they have sent before.

Two footnotes keep this honest. "Classified as agentic" reflects OpenRouter's app taxonomy, not a per-request intent detector, so the split moves with how apps are categorized. And the sample skews hard toward API-first builders, who adopt agents earlier and heavier than the consumer chat apps whose volumes never touch this gateway. The defensible read: wherever sophisticated builders buy tokens, machines already out-buy humans. As a leading indicator of how the LLM API traffic mix evolves elsewhere, that is worth more than a census two years late.

Why Falling Per-Token Prices Make Volume the Growth Engine

A crossover would be a curiosity if prices were stable. They are collapsing. a16z frames this as LLMflation, arguing that inference prices for a given level of capability have been falling by roughly an order of magnitude per year. The 2025 Stanford AI Index puts a number on one slice, reporting that the cost of GPT-3.5-level inference dropped more than 280-fold between late 2022 and late 2024. Epoch AI's public data hub tracks the other side of the ledger, with aggregate production token usage climbing steeply.

Chain those together and the market structure falls out. If revenue per token deflates by an order of magnitude per year, provider growth cannot come from price. It has to come from volume, and agents are structurally volume machines: loops that re-read context, retries that re-send it, tool schemas shipped on every call. The crossover is not an accident of one gateway. It is what demand looks like when the marginal LLM customer is a program. The roughly 70 percent cache share adds the fine print, since much of that volume is billed at a fraction of list, so token growth outruns dollar growth. Volume is still the engine, denominated in discounted tokens.

Your Analytics May Be Miscounting Your Real Users

Agents do not register as agents in most stacks. They register as API keys, service accounts, backend integrations, and generic user agents like python-requests. The dashboard says user, the CRM says customer, and the thing generating a growing share of your calls is a script your customer deployed last month.

The pattern is recognizable once you look for it. Monthly active users sit flat for two quarters while token volume triples. Sessions per user drift down while tokens per request climb. Your whale account turns out to be one shared key fronting a fleet of agent workers, which means per-seat pricing and per-user limits are both metering the wrong unit.

The fix is a caller-type dimension. Tag every key at issuance (human UI, server-to-server, declared agent framework), then report tokens by that dimension and add tokens per completed task as a first-class metric. If you cannot currently distinguish a human from a loop in your own logs, that gap is itself the finding.

Agent Rate Limits and the Burst Problem

Agent traffic is structurally different from human traffic, and limit tiers were not designed for it. Anthropic's engineering guidance on context engineering for agents is blunt that agents are token guzzlers: a multi-step loop re-reads its accumulated context on every step. Now count requests, not tokens. A human asks one question and gets one completion. An agent given the same job plans, calls a tool, reads the result, calls another tool, retries the call that returned a 429, and re-reads context each time: a dozen model calls for one finished task, often fanned out in parallel when tools are independent.

Per-minute limits calibrated against humans typing punish exactly this shape, and that burst is the agent's native rhythm rather than abuse. Anthropic's rate limits reference documents the standard response, spend-scaled tiers metered per minute, and the operational playbook follows from profiling rather than guessing:

• Measure requests per completed task and p95 burst concurrency, not just requests per minute.
• Give client code exponential backoff with full jitter so retries spread instead of stacking.
• Queue where fan-out is optional, since serializing independent tool calls often costs little latency and saves the limit.
• If agent traffic is your growth segment, negotiate tier increases before 429 storms become your customer's outage.
• Consider a separate limit pool for machine callers so bursts cannot starve human sessions, which also keeps the caller-type analytics clean.

Prompt Caching Economics Cut Both Sides of the Bill

The most underrated number in the crossover is that roughly 70 percent cache share. AI agent token usage is, by volume, mostly cached usage: the same system prompt, tool definitions, and conversation prefix, re-sent step after step. Providers price that reuse aggressively. OpenAI's prompt caching guide discounts cached input tokens by about 50 percent on most models, with deeper discounts on some newer ones. Anthropic's prompt caching page advertises cache reads at up to 90 percent below fresh input pricing, with cache writes carrying a premium and entries expiring in minutes by default.

The math on a 12-step loop

Assume a mid-tier model at $3 per million input tokens and an agent that runs a 12-step loop with a 40,000-token stable prefix. Uncached, the prefix alone costs 480,000 tokens at $3/M, or $1.44 per task. With a 70 percent hit rate the picture changes fast:

Same workload, same hit rate: the bill moves 35 percent on discount depth alone, and the best case cuts cost per task by roughly 63 percent versus no caching. Cached token cost now shapes effective cost per completed task as much as model choice does, and unlike price negotiation it responds to code structure. The levers: keep the prefix byte-identical across steps, move timestamps and other volatile fields to the end of the payload, hold system prompts and tool schemas stable per environment, and log cached versus fresh counts per task so hit rate sits next to cost on the same dashboard.

Providers read the same numbers as margin arithmetic: discounted cache reads are how they keep volume growing while list prices deflate. That is the growth engine from two sections ago, now expressed on your invoice.

Make Agents a First-Class Product Persona

If machines are the growth customer, you need an explicit posture toward them, and "unaware" is the most common posture today. There are three defensible positions.

Pick a posture

• Serve when agent traffic is demand: optimize retrieval, stability, and machine legibility for it.
• Tolerate when it is neutral: meter it, cap it, and spend nothing else on it.
• Block when it degrades human experience or exposes content you do not want repurposed.

Restructure docs for retrieval

For content products, the llms.txt proposal gives sites a machine-readable map of what to fetch. Then reshape the docs themselves. Take a documentation page written as flowing, interdependent prose and split it into task-oriented sections, each with its own heading, a one-paragraph summary, a code sample, and no dependency on the section above it. A retrieval system can now pull the one section it needs instead of ingesting the page whole, which cuts latency and tokens, the same currency agents spend everywhere else. The web side is converging on the same conclusion: Cloudflare's Radar measurements have separately tracked AI crawlers becoming a fast-growing slice of web traffic, another signal that machine readers are an audience you design for rather than an anomaly you filter.

Harden the API surface

For API products, agent callers reward boring reliability. Machine-readable error messages instead of HTML error pages. Idempotency keys so retries are safe, because agents retry by design. Pagination that survives being called 500 times in a burst. A structured changelog an agent can diff to catch breaking changes before its human owner notices.

Audit Your Traffic Mix in Five Steps

One week of work turns a market-level headline into your own AI agent token usage number: the share of tokens machines send you. This is the audit, with the fill-in table to copy.

1. Classify callers. Add or infer caller type for every key: human UI, server-to-server, declared agent framework. Report token share by class.
2. Measure cache hit rate. Pull cached versus fresh input counts per task from provider dashboards or response usage fields.
3. Compute effective cost per completed task. Blend cached and fresh pricing, then compare it to your per-session figure; the gap is the agent distortion.
4. Profile bursts against your limit tiers. Requests per task, p95 concurrency, and 429 rate tell you whether machine-majority API traffic is already colliding with human-calibrated limits.
5. Set and publish your agent posture. Serve, tolerate, or block, per caller class, written down where your team and your users can see it.

Worth stating what would weaken the machine-majority read. Single-gateway skew is the big one: OpenRouter's builder-heavy mix could over-index agents for years before the median workload follows. Loop-inflated demand is another, since tokens burned on retries and context re-reads overstate useful work. Taxonomy drift in how "agentic" apps are classified adds noise. And human-majority markets plainly persist, from consumer chat to plenty of B2B SaaS. Corroborating signals to watch: token mix disclosures from other gateways and providers, and cache-share figures in model provider updates.

Ship this quarter:

• Caller-type dimension live in analytics, with token share reported by class
• Cached versus fresh split shown next to cost per completed task
• Cost per task replacing cost per session in reviews
• Backoff with jitter and queueing on all machine-calling paths
• llms.txt plus retrieval-shaped docs if content is part of the product
• A documented serve, tolerate, or block posture per caller class

The February 6 crossover is a fact about one gateway. The inversion it points at may already be a fact about your traffic, and the audit above is how you find out which side of that date your stack is built for.