The numbers, first reported by The Decoder from analysis attributed to OpenRouter’s Peter Walker and subsequently repeated by CryptoBriefing and other outlets, describe one routing platform rather than the whole AI market. OpenRouter’s customer and model mix matters: it is popular with developers experimenting across providers and open-weight models, and token counts are not a universal measure of business value. But the direction is reinforced by OpenAI’s own newly published enterprise usage data: companies are shifting spend and attention from chat sessions toward systems that can take multi-step actions.
For Windows administrators, software teams, and AI platform owners, this changes the capacity-planning problem. The useful unit is no longer a prompt, a seat, or even an API call. It is a completed task, measured against its cost, runtime, permissions used, tool failures, and need for human review.
OpenRouter’s token figures are a platform signal, not an industry census
OpenRouter reportedly recorded agentic token use rising from about 510 billion tokens on February 6 to 7.3 trillion by August 10, a roughly 14-fold increase. Human-driven traffic grew 2.8 times over the same period to about 1.4 trillion tokens. On those figures, agents crossed above human token consumption on February 6 and now account for a little more than five times the human total.
That ratio should be read carefully. OpenRouter does not have a simple “human” or “agent” switch on every request; it classifies traffic using a weighted combination of signals such as tool calls, conversation turns, and timing patterns. That is a sensible way to identify automated workflows at scale, but it remains a classification method rather than a direct count of autonomous software. The underlying dataset and weighting have not been published in enough detail for outside parties to reproduce the result.
The data also says more about how applications are designed than about whether their answers are good. An agent that opens files, searches internal documentation, calls a ticketing API, tests a script, revises the result, and retries failed tool calls will necessarily consume more tokens than a user asking a chatbot for a paragraph. A 14-fold rise may represent more real work being delegated to software. It can also include inefficient loops, redundant context, excessive self-review, and badly constrained multi-agent systems.
That distinction is where many enterprise dashboards will fail. Raw token growth can be a healthy sign of adoption, or a billable symptom of an agent repeatedly doing work that should have been stopped after its first failed attempt.
OpenAI’s enterprise data points to the same behavioral shift
OpenAI’s August 12 Enterprise Signals report offers a separate view from within its enterprise customer base. It says firms in the top 10% of monthly AI usage generated 8.3 times as many output tokens per active user as firms around the middle of the distribution in June, up from a 2.6-times gap in January.
OpenAI calls those high-use organizations “frontier firms,” but the label should not be mistaken for proof that their deployments are more productive or safer. The metric is output tokens per active user, which captures intensity of use rather than return on investment. A company with heavily instrumented coding agents can generate enormous output volume while still struggling with test coverage, change approval, data access controls, or production reliability.
Still, the composition of OpenAI’s figures matters. By June, Codex generated 64% of the combined output-token total for Codex and ChatGPT among OpenAI enterprise customers. OpenAI describes Codex tokens as agentic AI usage in this comparison, while ChatGPT represents its more conversational product category. That makes the result a useful indicator that the company’s own enterprise customers are putting more model capacity into delegated work than into conventional chat.
The use is also moving outside engineering. OpenAI says weekly active enterprise Codex users grew 108-fold in legal, 41-fold in sales, 41-fold in recruiting, and 26-fold in marketing from February, compared with fivefold growth in engineering. Those enormous percentage increases are starting from unstated baselines, so they do not establish that legal departments now use Codex more than developers. They do establish that agent-style work is no longer confined to code repositories.
For IT leaders, the operational consequence is straightforward: the agent with access to a Git repository, SharePoint library, HR platform, CRM, or endpoint-management tool is no longer merely an employee productivity feature. It is a software identity that needs defined authority, traceable actions, scoped credentials, rate limits, and a way to halt execution.
Prompt caching changes the bill, but it does not prove efficiency
The most consequential detail in the OpenRouter discussion may be prompt caching. Agent systems often resend a stable block of information with every call: system instructions, source-code context, tool definitions, policy documents, task state, or previous outputs. A provider can reuse already computed context instead of processing the entire prefix from scratch, typically making repeated input cheaper and faster.
The submitted report says more than 85% of agentic tokens came from cached prompts. A chart reproduced by Charts of the Week also puts the cached share at about 86%. But The Decoder, as summarized by other outlets, described the share as closer to 70%. The reporting does not provide the underlying OpenRouter chart, date cut, or token taxonomy needed to reconcile those figures, so the exact percentage should be treated as unresolved rather than settled.
The broader finding holds regardless of whether the share is 70% or 86%: a large portion of agent traffic is repeated context. OpenAI’s pricing documentation separately confirms why that matters in real deployments. Its API prices cached input below fresh input for supported models, while output remains a separate and often more expensive category. In other words, raw token volume cannot be converted into cloud cost with one multiplication.
Caching is not a cure for uncontrolled agent spending. Cache hits help primarily when a workload repeatedly uses the same prefix in the required order and within a provider’s retention rules. Dynamic prompt construction, frequently changing tool lists, large fresh documents, retry storms, and long generated outputs can all erode the saving. Some current model offerings also charge separately to write content into a cache, which makes the number of repeat uses relevant.
The practical metric is therefore not “cache percentage” alone. It is the relationship between cached input, fresh input, generated output, tool calls, and successful task completion. A cached 100,000-token policy bundle may lower per-call cost, but it is still poor engineering if every lightweight request carries it unnecessarily.
Enterprise AI now needs workload governance, not just chatbot policy
Many organizations built their first AI controls around chat: prohibit sensitive prompts, retain logs, train employees, and approve a vendor. Agents require an additional layer because they can take actions over time and across systems. A coding agent might create a branch, edit files, run tests, open a pull request, query documentation, and invoke deployment tools. A business agent may read mailboxes, draft contracts, update CRM records, or create files in a shared tenant.
The failure modes are correspondingly different. A bad chatbot answer is visible to the person who asked. A bad agent run can fan out through an integration before a reviewer notices. Token consumption is useful as a cost and capacity signal, but it does not capture whether the agent accessed the right data, acted within approved limits, or produced a correct outcome.
Teams deploying agents should make a per-task control plane routine:
- Record the task identifier, initiating user or service identity, model, model version, tools available, and every external action.
- Set budget ceilings for tokens, tool calls, elapsed runtime, retries, and subagents, then stop the run when any ceiling is exceeded.
- Separate read access from write access, and require an explicit approval boundary before consequential actions such as changing production systems, sending external messages, or modifying authoritative records.
- Measure completion quality and rollback rates alongside token costs, because cheaper failed tasks are still failed tasks.
- Keep stable instructions and reusable context at the front of prompts where provider caching can work, but avoid attaching large universal context blocks to every request.
These controls are familiar to administrators who manage service accounts, CI/CD pipelines, or Power Platform flows. The difference is that agents vary their sequence of actions at runtime. The permission model, audit trail, and termination mechanism cannot be an afterthought.
The new bottleneck is useful work per dollar
The OpenRouter figures should not be read as proof that traditional automation platforms are being displaced or that every company should build multi-agent systems. Tools such as Zapier, Make, n8n, Microsoft Power Automate, and conventional workflow engines still offer a major advantage where the process is known, deterministic, and auditable. A fixed automation remains cheaper and easier to test than an agent repeatedly reasoning through a task that has clear rules.
Agents earn their cost when a workflow needs judgment across unstructured information, tool selection, iterative research, code changes, or exception handling. They lose that advantage when they are asked to imitate a deterministic workflow through elaborate prompts and loops. The result may look impressive in a demo while creating a variable, opaque, and expensive production dependency.
OpenAI’s report and the OpenRouter data both show that enterprises are experimenting with delegation at a far greater scale than the chatbot era suggested. The immediate challenge is not to match the largest token count. It is to identify the tasks where an agent’s extra inference produces a better outcome than a workflow, a search tool, or a human operator—and to cut off the runs where it does not.