The Real Reason Your AI Agents Cost So Much

New usage data published by a16z on August 21, 2026, drawn from traffic across the OpenRouter network, found that AI agents now consume close to five times as many tokens as human users of the same models, and that agent token consumption has multiplied roughly fourteenfold since February. Buried inside that report is the number that actually matters for anyone watching a monthly AI bill: more than 85% of agentic token burn comes from cached prompts — agents re-reading context they were already given, not generating new output. Most businesses looking at a climbing token bill assume the fix is a cheaper model or fewer requests. For the large majority of that spend, neither would help, because the cost isn't coming from thinking. It's coming from re-reading.

Why Agents Re-Read So Much More Than Chatbots Do

A person using a chatbot sends a short message and gets a short reply — the model reads a small amount of context each turn. An agent working through a multi-step task operates completely differently: at every single step, it has to re-send its full working context — the original instructions, every tool result so far, every intermediate decision, often the entire conversation history — just to decide the next action. Gartner's March 2026 analysis put the multiplier at 5 to 30 times more tokens per task than a standard chatbot exchange, and the gap is structural, not a sign anything is broken. It is simply what it costs to keep an agent stateful across a long task using an architecture that re-sends everything, every time:

• A ten-step workflow with no context management re-reads the growing transcript at every step, so the tenth step pays for reading everything the first nine steps ever produced
• A multi-agent system where sub-agents pass full context back and forth multiplies the same re-reading cost across every agent in the chain, not just the orchestrator
• A tool-heavy agent that calls a search, a database lookup, and an API in sequence re-reads all three results plus the original task on every subsequent step, even after the useful information has already been extracted from them
• Top-decile enterprises in a16z's data output eight times more tokens than typical enterprises and grew that output more than seventeenfold since April 2025 — in the information sector, the gap widens to twelve times, with leaders producing 32.5 times what they produced sixteen months earlier — meaning the businesses scaling agents fastest are also the ones with the most to gain from fixing how much of that scale is genuinely useful work versus repeated re-reading

None of this means agents are inefficient by design or that the token growth is a red flag on its own. Prompt caching exists specifically to make repeated context cheap to re-read rather than free to skip, and most major model providers now price cached tokens at a steep discount over fresh ones. The problem is that caching only helps with the cost of re-reading the same thing twice — it does nothing about whether an agent needed to be carrying that much context in the first place, and most agent architectures were built for correctness, not for minimizing what gets re-sent at every step.

Where the Actual Waste Hides

A high cache-hit rate looks efficient on a billing dashboard, and providers often present it that way. But a cache hit on 50,000 tokens of context that could have been summarized down to 2,000 is still a cache hit — it is just a cheap way to keep paying for bloat instead of an expensive one. The token-cost audits that find real savings usually turn up the same few patterns:

1. 1Full transcript re-transmission — an agent that re-sends its entire step-by-step history at every turn instead of maintaining a compressed working summary and only pulling full detail back in when a later step actually needs it
2. 2Tool results carried past their useful life — a search result or database row set that stays in context for the rest of the task after only one field from it was ever actually used
3. 3Redundant system and instruction blocks — long, static instructions re-sent on every single call within a task instead of cached once at the start of the session and referenced rather than repeated
4. 4Multi-agent handoffs with no context pruning — a sub-agent invoked mid-task that receives the entire parent context instead of the specific slice it needs to do its narrower job
5. 5No summarization checkpoint — long-running agent sessions that never compress earlier steps into a shorter running summary, so token cost per step keeps climbing linearly as the task gets longer

A Realistic Scenario

A Wizeb client, a mid-sized property management company, ran a leasing-agent AI that handled inbound rental inquiries end to end — answering questions, checking unit availability, scheduling tours, and following up — often across ten or more back-and-forth steps per prospect. Their per-conversation token cost had climbed steadily as the agent got more capable, and the assumption internally was that a longer, smarter agent simply cost more to run. A token audit found the agent was re-sending its full conversation history, the complete property database query results for every unit it had ever checked in that session, and a lengthy static instruction block, at every single step — regardless of whether that step needed any of it. We restructured the agent to maintain a compressed running summary of the conversation, cache the static instructions once per session instead of resending them, and drop full unit query results from context as soon as the relevant fields were extracted into the working summary. Per-conversation token spend dropped by more than 60%, response latency improved because less context had to be processed per step, and the agent's actual task performance was unaffected because nothing it still needed had been removed.

How to Check Your Own Agent Spend

1. 1Pull your highest-volume agent workflow's token usage broken out by cached versus fresh tokens — most model provider dashboards report this split directly
2. 2If cached tokens make up the large majority of spend, that confirms the cost is concentrated in re-reading, not generation, and the fix is architectural, not a model swap
3. 3Trace one representative agent session step by step and check whether context size grows roughly linearly with each step — if it does, the agent has no summarization or pruning checkpoint
4. 4Check whether tool results and sub-agent handoffs carry full payloads forward after only a small piece of them was actually used downstream
5. 5Estimate the cost of a compressed-context redesign against current monthly agent spend — for workflows running at real volume, the payback is usually measured in weeks, not quarters

How Wizeb Approaches This

When we build or audit an AI agent at Wizeb, context management is treated as core architecture, not a tuning pass done after costs get noticed. We instrument agents to track cached versus fresh token spend from day one, build in running-summary compression for long tasks, prune tool results and sub-agent handoffs down to what the next step actually needs, and cache static instructions instead of re-sending them every call — so token cost scales with the value an agent is producing, not with how long its transcript has gotten. If your agent spend has been climbing and the instinct has been to reach for a cheaper model, it is worth checking how much of that bill is re-reading first. Start at wizeb.com/services/token-optimization.

Three Questions Before You Downgrade Your Model

1. 1Do you know what share of your agent token spend is cached versus fresh — or only the total bill?
2. 2Does your agent's context grow linearly with every step, or does something actually compress and prune it along the way?
3. 3If a tool result or sub-agent handoff carries a full payload forward, is anything downstream still using all of it?