Direct answer: AI agents cost more than they should because they resend the same context over and over. Every step of an agent loop replays the system prompt, the tool definitions, the repository, and the retrieved documents, hundreds of times a day. That repeated context is the largest hidden charge in most agent bills, and it never appears as its own line. Your caching ratio, not your model choice, is usually the lever that fixes it.
Engineers ask me why their agents feel expensive out of proportion to what they do, and the answer is almost always the same, though it is invisible in every bill I have looked at. An agent runs as a loop, and each turn of that loop drags the entire accumulated context along with it. Most of the money goes to how many times the model re-reads the same page before it thinks, rather than to the thinking itself.
The frame I use here is the repeated-context tax, and it is worth defining precisely because the precision is the whole point. Every token an agent sends splits into two kinds. Fresh tokens are the new material for this specific step, the latest observation or the user's newest instruction. Repeated tokens are everything the model has already seen on a prior step and is being shown again: the system prompt, the tool schemas, the code files, the RAG documents. The repeated-context tax is the share of your bill that is fresh money spent on tokens the model has already been given. In most agent workloads that share is the majority, and nobody is looking at it because it is spread evenly across thousands of ordinary-looking calls.
Why the loop multiplies the same tokens
To see why the tax gets so large, follow one agent through a task. It starts with a system prompt, a set of tool definitions, and the relevant slice of a repository. Call that the base context. On step one it reads the base context and takes an action. On step two it reads the base context again, plus the result of step one. On step three it reads the base context again, plus steps one and two. A task that takes fifteen steps has sent that base context fifteen times. If the base context is large, and for a coding agent working in a real repo it is very large, you have paid for the same repository fifteen times to complete one task.
Now multiply that by how agents are actually used. A team running Claude Code or Cursor across a working day runs thousands of tasks, each one a loop, each loop replaying its base context on every step. The same handful of system prompts and the same core files get resent tens of thousands of times a day. A napkin estimate counts the work an agent does and lands far below the bill, because the bill charges for that work multiplied by the length of every loop that carried it.
The charge that never shows up as a line
Here is what makes the repeated-context tax so durable: no invoice will ever name it. Your provider bills you for input tokens and output tokens in total. It does not, and cannot, tell you that seventy percent of your input tokens this month were context the model had already been shown earlier in the same loop. A dashboard built on provider billing data inherits that blindness exactly, because it is reading the same undifferentiated totals. So the single biggest driver of agent cost is structurally hidden from the one place everyone goes to look at cost.
The blindness in that total also explains why the usual first instinct, switching to a cheaper model, so often disappoints. Moving a coding agent to a cheaper model lowers the price per token, but it does nothing about the number of times you are resending the same repository. You have made an inflated token count slightly cheaper per unit while leaving the inflation in place. Caching addresses the cause directly, because it changes what you pay for repeated tokens rather than what you pay per token in general.
Caching ratio is the number to watch
Every major provider now supports prompt caching, and the economics are steep in your favor when you use it. A cached input token costs a small fraction of a fresh one, often around a tenth, because the provider is reusing computation it has already done. When your agent's base context is cached, that repository it resends fifteen times gets charged near full price once and at the cache rate for the other fourteen reads. The repeated-context tax does not disappear, but it collapses to a fraction of itself. The single number that tells you whether this is happening is your caching ratio: of all the repeated tokens you send, what share is being served from cache rather than recomputed cold.
The caution that goes with this is that caching is fragile in ways that do not announce themselves, so you have to measure the ratio rather than assume it. A cache entry only hits when the prefix matches exactly, so a workflow that reorders its context, injects a timestamp near the top, or shuffles tool definitions between calls can silently drop its cache hit rate to near zero while looking identical in the code. You will not feel this. The agent still works. The bill just quietly stays high because every "repeated" token is being treated as fresh. A broken cache is invisible to spend alone, which is what earns the caching ratio a place on your dashboard right next to the dollar figure.
So the reason your agents cost more than they should is that they are paying full price to reread material they already have, once per step, across every loop they run, and no line item will ever confess it. The fix runs through the caching ratio rather than the model choice: measure the repeated-context tax directly, drive the caching ratio up, and protect the cache prefix so the hits actually land. Do that and the same agents doing the same work cost a fraction of what they did, because you finally stopped buying the same context on repeat.
We built Oberhahn to measure exactly this, the repeated context your agents send and the share of it being served from cache, from the telemetry your tools already produce, so the hidden tax becomes a number you can watch fall. You can walk a live demo with sample data before connecting anything.
Frequently Asked Questions
Why are my AI agents so expensive?
Because an agent runs as a loop, and each step replays the entire accumulated context: the system prompt, tool definitions, repository files, and retrieved documents. A fifteen-step task can send the same base context fifteen times, and a busy team runs thousands of such loops a day. That repeated context, not the model's actual reasoning, is usually the largest driver of agent cost, and it is spread invisibly across ordinary-looking calls.
Why doesn't my provider bill show the repeated context cost?
Provider bills report total input and output tokens with no distinction between fresh tokens and tokens the model has already seen earlier in the same loop. The repeated-context tax is real spend, but it is folded into that undifferentiated input total. Any dashboard built only on provider billing data inherits the same blind spot, which is why the biggest cost driver is usually the hardest one to find.
Will switching to a cheaper model fix agent costs?
Only partly, and often disappointingly. A cheaper model lowers the price per token but does nothing about how many times your agent resends the same repository and prompts. You end up with an inflated token count that is slightly cheaper per unit. Raising your caching ratio addresses the cause, because it changes what you pay for the repeated tokens themselves.
What is a caching ratio and why does it matter?
Your caching ratio is the share of repeated tokens served from the provider's prompt cache instead of recomputed at full price. Cached input tokens often cost around a tenth of fresh ones, so a high ratio collapses the repeated-context tax. It matters because caching is fragile: reordering context or injecting a timestamp near the top can quietly break cache hits while the agent keeps working and the bill stays high.