Agent costs are not chatbot costs. A chatbot answers in a few thousand tokens. An agent plans, calls tools, retries, and checks its own work, so a single task can burn a few hundred thousand tokens. And it does that on every run, all day. Inference is now the biggest line on most AI bills, and it grows with every user you add. Naturally, a whole industry has formed around cutting it. Prompt caching, model routing, context compression, gateways, semantic caching. Each arrives with a benchmark and a headline number, usually somewhere between 60 and 80 percent. If you're the developer running the agent, that list lands on your desk. You have to evaluate each technique, integrate it, wait a billing cycle to see whether it worked, and confirm that quality held up along the way. All of it with the quiet knowledge that if the savings come back at 2% instead of 60, that time is gone, and the list will have grown while you were busy. There is plenty written about whether these techniques work. Very little about the question you actually have: will it work for me?
The reason no one can answer that from a benchmark is that these techniques optimize a single request in a silo, while your costs are produced by an agent. A whole behavior, not a call. Caching assumes your requests share stable prefixes; if your agent rebuilds context every turn, the 90% becomes a rounding error. Routing assumes most of your traffic is easy; if your agent exists precisely because the tasks are hard, there's no cheap tier to route to. And none of them can see the retry loop firing four times per run. They'll happily make each of those four calls 40% cheaper without ever asking why there are four. That's the deeper trap. Inefficiencies in the design scale with your traffic. Agents amplify all of this because AI is nondeterministic, and agents are nondeterminism compounded. Dozens of model calls, tool results feeding into planning, loops whose length depends on outputs no one fully controls. Two agents built on the same framework can have wildly different cost anatomies. The vendor's number was measured on an agent shaped like their benchmark. Yours is shaped like your code.
Which means the answer was never going to be in a blog post. It's in the two things you already own: your traces and your repository. Traces tell you what your agent actually does under real traffic. How much context genuinely repeats (your true caching ceiling), what fraction of spend lands on failed runs, which steps burn a frontier model on work a small one handles fine. But traces only surface the symptom; the code tells you the intent. Is that repeated call a deliberate verification pass or an uncapped bug? Is the ever-growing history a design choice or something nobody got around to truncating? Reading trace against code is what turns "high spend detected" into a root cause with a specific fix. It's also what lets you rank the entire evolving menu of techniques by what your agent will actually pay back, before you spend a single engineering day finding out the hard way. This is the intelligence Costzera is built for. Not another technique on the leaderboard, but the step before all of them. And after, because a prediction should be held to its word: baseline the cost per run, ship the fix, measure for a week, and only call it savings if quality holds.
The techniques are real. The savings are real. But "up to 80%" was never a number. It's a distribution, and every agent lands somewhere different on it, for reasons written in your traces and your code. So before the next optimization post crosses your feed, it's worth sitting with the question it won't ask: do you actually know where your agent's money goes, or have you just been hoping you're the agent in the benchmark?