Your support agent handled roughly the same number of tickets in July as it did in March. The invoice from your model provider is about double. Nobody changed the pricing, nobody added a workflow, and the developer who set it up has moved on to something else.
This is the normal failure mode, and it has nothing to do with the per-token rate. AI agent costs drift upward on their own, because almost everything that makes an agent better at its job also makes each run more expensive, and none of those changes ever appears as a line item.
Four things do most of the drifting. All four are measurable in an afternoon.
Cost per task is the number, not the monthly total
Monthly totals tell you almost nothing, because volume moves underneath them. A bill that grew 40% while tickets grew 60% is a bill that got cheaper.
So log the thing that matters: input tokens, output tokens and the resulting cost, tagged with the task the agent was doing. Every provider returns token counts in the response. Writing them to a table alongside a task ID takes an hour and pays for itself the first time somebody asks where the money is going.
Once you have that, one comparison decides everything else. Cost per completed task, against what the same task costs when a person does it. That is the arithmetic that made the agent worth building in the first place, and it's the only one that tells you when it has stopped being worth running.
The prompt grows every time someone fixes something
Your agent gets something wrong. Someone adds a sentence to the system prompt telling it not to do that again. It happens on a Tuesday, takes four minutes, and works.
Repeat that for six months. A system prompt that started at a few hundred words is now several thousand, and every single request pays for all of it, including the ninety-plus percent of requests that were never going to hit that edge case anyway. Nobody removes an instruction, because nobody is sure which one is load-bearing.
Retrieval does the same thing faster. The agent misses an answer that was in the documents, so someone raises the number of retrieved chunks from five to twenty. The miss goes away. The cost of every other request quadruples on the retrieval side, silently, and the model now has more irrelevant text to wade through, which tends to make the answers worse rather than better.
Both are worth auditing quarterly. Print the full prompt that actually gets sent for a typical request, read it, and cut what no longer earns its place.
Retries are invisible until the invoice arrives
Any agent that calls tools will hit failures. An API times out, a response comes back malformed, a schema doesn't validate. The sensible design retries.
What costs money is a retry loop with no ceiling. The agent tries, fails, tries again with the full context attached, fails again, and you pay for every attempt including the ones that produced nothing at all. A single stuck task can cost more than a hundred successful ones, and because it never completes, it never shows up in your per-task numbers.
Two fixes, both cheap:
- Put a hard attempt limit on every loop, then escalate to a person. An agent that gives up after three tries and asks for help is behaving correctly. We build every agent with that handoff path defined before the happy path.
- Log attempts per task, not just cost per task. A rising average is the earliest warning you get that something upstream has broken.
Output costs several times what input costs
On every major provider, output tokens are priced well above input tokens. On the Claude API the ratio is five to one across the current model line, and the published pricing table shows the same shape at every tier.
Which makes response length a budget decision, not a style preference. An agent that writes a friendly three-paragraph preamble before the answer is charging you five times the input rate for words the next system in the chain is going to strip out anyway.
If the output feeds another program, ask for structured data and nothing else. If it feeds a person, say so in the prompt and cap max_tokens at something you have actually measured against real answers. Verbosity is the easiest cost to remove and the one most people never look at.
You pay full price for the part that never changes
Most agent prompts are mostly static. Tool definitions, the system instructions, the reference documents, the examples. That block is identical on every request, and by default you pay full input price for it every time.
Prompt caching exists for exactly this. On the Claude API, reading a cached prefix costs a tenth of the base input price, and writing one costs 25% more than base for the five-minute cache. For a high-volume agent with a large stable prefix, that is the single biggest lever available.
The catch is where you place the cache breakpoint. Cache hits need a byte-identical prefix, so if a timestamp, a session ID or the incoming user message sits anywhere inside the cached block, the hash changes on every request. You pay for a fresh write each time and never get a read, which is worse than not caching at all. Put the breakpoint at the end of the part that genuinely never changes, then check cache_read_input_tokens in the response to confirm it's working.
What to change this week
Nothing here needs a rebuild. In rough order of return:
- Log tokens and cost per task. You cannot cap what you cannot see.
- Read the full prompt your agent actually sends. Cut the instructions that fixed a problem you no longer have.
- Put an attempt ceiling on every retry loop, with escalation to a human at the top.
- Cache the static prefix, and verify the cache is being read rather than rewritten.
- Check whether every task needs your largest model. In a workflow scoped narrowly enough to work, most requests are routine, and routing the routine ones to a smaller model usually costs less than the classification step saves.
An agent whose cost per task is flat as volume grows is doing what it was built to do. One whose cost per task climbs quietly every month is telling you something, and the something is almost never the price of the model. If you want a second pair of eyes on a live agent, that's most of what we do once the first version has been running long enough to have a bill worth reading.
